diff --git a/source/devices/AM335X/rtos/Release_Specific.rst b/source/devices/AM335X/rtos/Release_Specific.rst
deleted file mode 100644
index d02af37cf..000000000
--- a/source/devices/AM335X/rtos/Release_Specific.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-################
-Release Specific
-################
-
-.. toctree::
-   :maxdepth: 5
-
-   Release_Specific_Release_Notes
-   Release_Specific_Supported_Platforms_and_Versions
-   Release_Specific_Migration_Guide
diff --git a/source/devices/AM335X/rtos/Release_Specific_Migration_Guide.rst b/source/devices/AM335X/rtos/Release_Specific_Migration_Guide.rst
deleted file mode 100644
index 8365fddb5..000000000
--- a/source/devices/AM335X/rtos/Release_Specific_Migration_Guide.rst
+++ /dev/null
@@ -1,867 +0,0 @@
-.. _RTOS-SDK-Migration-Guide-label:
-
-***************
-Migration Guide
-***************
-
-Overview
-========
-
-This page covers migration information for applications built on top
-of the Processor SDK RTOS.
-
-Processor SDK 06.xx Releases
-============================
-
-Processor SDK 06.03
--------------------
-
-Building PDK components from GIT repositories
-=============================================
-
-**Migration:** Change in git repository for PDK components.
-
-**Impact Scope:** Applicable for most drivers packaged in the PDK when used in development environment
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) had their own git respositories which could be cloned and used for development or picking up bugfixes which are not yet released through a processor sdk release.
-From this release onwards, most of the drivers in the PDK are moved to the new pdk.git repository(https://git.ti.com/cgit/processor-sdk/pdk) and its components (drivers) moved in to their respective locations inside the pdk_<soc>_<ver> of the Processor SDK installation.
-For example the i2c driver has been moved from https://git.ti.com/cgit/keystone-rtos/i2c-lld to https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/drv/i2c. Consequently, the latest updates on a PDK driver should be fetched from the new pdk.git repo (https://git.ti.com/cgit/processor-sdk/pdk) as the older repos are rendered obselete.
-
-Building of libraries of individual PDK components
-==================================================
-
-**Migration:** Building individual drivers' librabries/apps of PDK from PDK's top level makefile is not supported
-
-**Impact Scope:** Applicable for PDK top level makefile
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) could be built from
-the top level makefile (pdk_xx/packages/makefile) using commands like "make uart_lib/uart_apps". This is no longer supported.
-Instead, the libraries and applications could either be built using "make all" from the top level makefile or issuing "make libs/apps" from within the module's directory.
-
-
-Processor SDK 06.01
--------------------
-
-NIMU
-====
-
-**Migration:** Udma init sequence call has been moved from NIMU library to NIMU example for AM65xx
-
-**Impact Scope:** Applicable for all NIMU applications using NIMU tranport library for AM65xx
-
-**Additional Details**:
-Applications will need to implement the following function to provide UDMA drive handle which will be called by the NIMU driver at startup
-
- Udma_DrvHandle nimu_app_get_udma_handle(void)
-
-Processor SDK 06.00
--------------------
-
-PRUSS
-^^^^^
-**Migration:**
-Calls that passed ``PRUICCSS_INSTANCE_MAX`` as a parameter to PRUSS driver API
-calls will now pass ``PRUICCSS_INSTANCE_THREE`` instead.
-
-**Impact Scope:**
-Applicable for all AM65xx applications using PRUSS driver for ICSSG use case.
-
-**Additional Details:**
-The following new enumeration, ``PRUICCSS_INSTANCE_THREE``, for PRU-ICSS
-instance 3 has been added to ``PRUICSS_MaxInstances`` enumeration list as
-``PRUICCSS_INSTANCE_MAX`` is not longer valid when making PRUSS driver API
-calls.
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-MMU configuration is needed to enable NBO CFG registers access on A53 core.
-
-**Impact Scope:**
-Applicable for all AM65xx RTOS applications calling ``Board_init()`` with
-``BOARD_INIT_ICSS_ETH_PHY`` flag.
-
-**Additional Details:**
-Board library is setting ``NAVSS THREADMAP`` register to give higher priority
-for MSMC access from ICSSG which requires access to ``NBO CFG`` registers.
-
-
-Processor SDK 05.xx Releases
-============================
-
-Processor SDK 05.03
--------------------
-
-EMAC
-^^^^
-**Migration-1:**
-ICSS-G EMAC firmware binary directory location update for future extension.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Applications will need to update the include path to location of firmware header
-files for ICSSG use case:
-
-- **Prevous location:** ``ti/drv/emac/firmeare/icss_eth/src/dm``
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/bin``
-
-**Migration-2:**
-Release introduces support for additional firmware specific configuration
-files. Added for future extension to support multiple firmwares using same EMAC
-driver.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Firmware configuration has been moved to firmware specific configuration files,
-``emac_fw_config_dual_mac.h`` and ``emac_fw_config_dual_mac.c``. Previously the
-firmware configuration was specified in the test application. It is not expected
-that applicatons will need to modify these files as the are closely tied to the
-firmware.
-
-- **Previous location:** firmware specific configuration was specified in the
-  text application (``ti/drv/emac/test/EmacLoopbackTest/test_utils_k3.c``)
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/config/``
-
-Applications will need to update their makefiles to include c source file
-``emac_fw_config_dual_mac.c``.
-
-At time of ``emac_open()`` API call, applications need to udpate configuruation
-parameters to pass get firmware configuration pointer :
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V5 emac_cfg;
-   EMAC_socGetInitCfg(0, &emac_cfg);
-   emac_cfg.portCfg[port_num].getFwCfg = &emacGetDualMacFwConfig;
-   EMAC_socSetInitCfg(0, &emac_cfg);
-
-CSL
-^^^
-**Migration:**
-API changes on CSL-FL of AM65xx on ecc aggregator, vim, esm modules
-
-**Impact Scope**:
-Limited to the case if application is using the CSL-FL APIs
-
-**Additional Details**:
-The CSL-FL for ECC aggregator, ESM and VIM are modified to return API
-functionality success/failures and additional arguments are added as and when
-needed (especially during the cases where the return was the value instead of
-API success/failure). Applications that use these CSL-FL calls are impacted and
-are needed to align to new calling conventions. If applicable application
-modification required to align to updated APIs, refer doxygen API documentation
-for API details.
-
-
-DSP- TI CGT Compiler
-^^^^^^^^^^^^^^^^^^^^
-
-**Migration:**
-In DSP TI CGT compiler version 8.3.2 the rts library boot object file name is
-changed from ``boot.obj`` to ``boot.c.obj``.
-
-**Impact Scope:**
-Limited only to DSP applications that explicitly uses rts library object files
-in linker command file.
-
-**Additional Details:**
-The DSP application which is using linker command file of CSL module should
-change boot object name from boot.obj file to ``boot.c.obj``. If the user is
-using cpp version of boot object file then it should be mentioned as
-``boot.cpp.obj``. In general it can be also be used as ``boot.*.obj``. This can
-be referred from the following linker command file in the PDK package
-``<PDK>/packages/ti/csl/example/lnk_dsp.cmd``
-
-Processor SDK 05.02
--------------------
-
-SBL
-^^^
-**Migration:**
-Image integration and memory map changes.
-
-**Additional Details:**
-Release supports optimized boot times for booting MCU1_0 core from OSPI
-flash. To reduce the size of the SBL,  the system firmware image, which was
-earlier embedded in the SBL, is now a separate binary. The system firmware image
-can be found at ``<PDK>/packages/ti/drv/sciclient/soc/V0/sysfw.bin``
-
-For MMC/SD boot, if the steps followed in :ref:`Windows SD Card Creation Guide
-<windows-sd-card-creation-guide>` or :ref:`Linux SD Card
-Creation Guide <tools-create-sd-card-linux-label>` are
-used, no additional steps are need. If the SD card is being created manually,
-then the ``sysfw.bin`` file also needs to be copied into the root directory of
-the MMC SD card, along with ``tiboot3.bin`` and ``app``.
-
-For OSPI boot, the flash offsets have changed. ``sysfw.bin`` needs to be
-programmed into OSPI flash at offset ``0x40000`` (new for this release), along
-with ``sbl_ospi_img_mcu1_0_release.tiimage`` at offset ``0x0`` (no change from
-previous release) and the ``app`` at offset ``0xA0000`` (was ``0x80000``
-previous release).  For details please refer `Programming the OSPI flash
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Board_EVM_Abstration.html#uniflash>`__
-
-Applications that the SBL loads must co-exist with the SBL's memory usage.In the
-application's linker command file, care must be taken to not use the first 0x100
-bytes of MCU1_0's ATCM memory and SBL reserved memory from ``0x41C00100 to
-0x41C28000``. If the applications violate the SBL memory usage, then apps that
-were working with the last release might not work any more, as the memory
-constraints are tighter. For details, refer the `SBL Memory Utilization
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Foundational_Components.html#am655x-sbl-memory-usage>`__
-
-PDK
-^^^
-**Migration:**
-AM65xx PDK component dependency on sciclient module.
-
-**Impact Scope:**
-Applications will need to link to sciclient module library. No migration impact
-if application is already linking the library.
-
-**Additional Details**:
-All application using PDK components on AM65xx platform will need to link
-sciclient library  as components internally will be using sciclient API for PLL
-and interrupt configuration. In this release, requirement for application will
-be more mandated as more components are using common infrastructure.
-
-DMSC firmware should be loaded onto Cortex-M4 core using SBL or :ref:`CCS GEL script
-<advanced-am65x-debug-setup-with-dmsc-firmware-load>`
-before calling the Board Init API with 'BOARD_INIT_PLL' flag.
-
-Board
-^^^^^
-**Migration:**
-New APIs for EEPROM Board ID Information
-
-**Impact Scope:**
-Applications using Board ID info APIs on AM65xx platform. No migration impact
-for existing applications and boards using version 1 API.
-
-**Additional Details**:
-TI Board ID information format has been updated to new version on AM65xx. New
-board library APIs ``Board_getIDInfo_v2()`` and ``Board_writeIDInfo_v2()`` are
-added to support new Board ID information format. Old Board ID info APIs are
-still avaialble to retain the backward build compatibility but returns error
-when used on AM65xx platform.
-
-FATFS
-^^^^^
-**Migration:**
-FATFS module in this release includes multipartition support and capability of
-detecting single vs multiple partitions run time.
-
-**Impact Scope:**
-Limited to the case if user had used MS-DOS Floppy disk format for formatting
-the SD/eMMC memory. No impact if the SD/eMMC is formatted using the steps
-provided by :ref:`Windows SD Card Creation Guide
-<windows-sd-card-creation-guide>`/:ref:`Linux SD Card Creation
-Guide <tools-create-sd-card-linux-label>`.
-
-**Additional Details**:
-Partition entry information may be wrongly detected for the storage media
-formated to  MS-DOS Floppy disk format. FATFS APIs fail to access the disk in
-this case.
-
-**Workaround**:
-Format the storage media using the steps provided by :ref:`Windows SD Card Creation
-Guide <windows-sd-card-creation-guide>`/:ref:`Linux SD Card
-Creation Guide <tools-create-sd-card-linux-label>`
-in case this issue is observed.
-
-Processor SDK 05.01
--------------------
-
-Build
-^^^^^
-**Migration:**
-Applicable for applications migrating from SOCs supporting EDMA LLD to AM65x
-with updated DMA infrastructure. Additional UDMA driver support is available in
-package to support enhanced DMA infrastrcuture for AM65x Drivers for AM65x SOC
-is extended to support UDMA LLD abstracting changes needed by
-application. Limited change will be required for application using drivers
-included in Processor SDK.
-
-**Additional Details**:
-Modifications needed at application will be limited to initialization of UDMA
-driver using Udma_init() API in addition to linking  UDMA driver library. Driver
-Test code could be used as reference Additional migration details for all cases
-are covered in ``/ti/drv/udma/docs`` folder inside PDK package.
-
-DMA
-^^^
-**Migration:**
-For all drivers using DMA mode EDMA driver is updated to UDMA driver.
-
-**Additional Details:**
-Application will need to initialize UDMA driver and SCIClient interface using
-``Udma_init()`` and ``Sciclient_init()`` API. Test code could be used as
-reference.
-
-Networking
-^^^^^^^^^^
-**Migration:**
-Applicable for applications using NDK and Posix port of SysBIOS.
-
-**Additional Details:**
-Release introduces NS (Network Services Component) as independent portable
-networking API abstracting different network stacks. Detailed migration details
-is available at `NDK 2.x to 3.x Migration Guide <NDK_Migration_Guide_>`__
-
-Processor SDK 05.00
--------------------
-
-Build
-^^^^^
-**Migration:**
-``TOOLS_INSTALL_PATH`` macro value changed to ``SDK_INSTALL_PATH``. No migration
-impact if tools and SDK are installed in same location.
-
-**Additional Details:**
-``TOOLS_INSTALL_PATH`` macro value is set to ``SDK_INSTALL_PATH`` by
-default. For accessing the tools from a different path, modify
-``TOOLS_INSTALL_PATH`` in ``packages/ti/build/Rules.make`` file or can be
-overriden from the build console as shown below.
-
-Windows
-
-.. code:: console
-
-       set TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-Linux
-
-.. code:: console
-
-       TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-
-Build Setup
-^^^^^^^^^^^
-**Migration:**
-There is no migration need for components used within processor SDK. Application
-Software outside processor SDK may require a change if there is a dependency to
-internal Processor SDK environment variables. See more details below.
-
-**Additional Details:**
-Rules.make file is used instead of pdksetupenv to setup the build environment
-variables. Components inside processor SDK are updated to align with this
-change. Any applications making use of pdksetupenv from processor SDK to setup
-the build environment variables should include below line in the application
-makefile.
-
-.. code-block:: c
-
-  include $(RULES_MAKE)
-
-Processor SDK 04.xx Releases
-============================
-
-Processor SDK 04.03
--------------------
-
-OSAL
-^^^^
-**Migration:**
-No impact expected if Semaphore allocation and HwIP registration from OSAL is
-not invoked by application.
-
-**Additional Details:**
-OSAL module is fine tuned for optimized number of semaphores required internally
-within drivers. Module provides additional API to application for additional
-semaphore allocation if required.Application can configure for either default
-internal static allocation or it can select external memory block that can be
-provided to create these objects. Note that this decision to go with external
-memory block or internal memory block need to be done during init configuration
-of application (near to main) just after ``Board_init()`` is called. Below
-sample code sets SemaphoreP/HwiP to be used from external memory block:
-
-.. code-block:: c
-
-   /* Get the Hw Attrs */
-   osal_ret = Osal_getHwAttrs(&hwAttrs);
-   if (osal_ret != osal_OK)
-   {
-       return (false);
-   }
-
-   /* This API should set to use external memory block */
-   hwAttrs.extSemaphorePBlock.base = (uintptr_t) &semPMemBlock[0];
-   hwAttrs.extSemaphorePBlock.size = SEMP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.size       = HWIP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.base       = (uintptr_t) &hwiPMemBlock[0];
-   osal_ret = Osal_setHwAttrs(ctrlBitMap, &hwAttrs);
-
-
-Board
-^^^^^
-**Migration:**
-Section details applicable only to applications based on DRA7xx SoCs.
-
-**Additional Details**:
-DRA7xx board libraries have refactored pad configuration sequence by removing
-manual pinmux entries and replacing them with a full IODELAY reconfiguration
-procedure. This was done in order to simplify transition from a standalone
-application development in CCS to booting the whole device via SBL, ensuring
-that pad configuration is 100% consistent between the two application loading
-methods.
-
-The IODELAY and pin control data structures are maintained in each of evmDRA72x
-and evmDRA75x board library source directories. These structures are also
-included in the SBL compilation and used in the SBL's IODELAY
-reconfiguration. Therefore, changes can be made in one location but reused by
-both Board and SBL components just through recompilation.
-
-Note that DRA78x does not require IODELAY reconfiguration and pinmux setup is
-always contained entirely in the application. Hence, there are no corresponding
-changes to this library.
-
-All of this is done in a transparent manner, so there is **no API change** and
-will not affect existing applications. However, there are considerations with
-respect to memory placement and potential conflicts between the board library
-and SBL code. These restrictions have always existed but are now more clearly
-defined and documented. Please refer to :ref:`Board Support
-<board-board-support>` for more details.
-
-I2C
-^^^
-**Migration:**
-No migration required for existing user application.
-
-**Additional Details:**
-PRUICSS based I2C Firmware have been introduced in this release. This new
-features increases the number of I2C interface available in the SOC. I2C LLD now
-depends on PRUSS LLD for compilation of this new feature. All of this is done in
-a transparent manner, so there is **no API change** and will not affect existing
-applications. However, for using the I2C FW feature refer :ref:`I2C FW
-<PRU-ICSS-I2C-FIRMWARE-label>` for additional details.
-
-Processor SDK 04.02
--------------------
-
-GCC Toolchain Migration to 6-2017-q1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to TI-RTOS based application on ARM Cortex-A cores.
-
-**Additional Details:**
-Processor SDK RTOS components includes updates to be compatible with GCC tool
-chain. This includes updates to SysBIOS, compiler and linker options. Following
-migration changes required for applications:
-
-- Compiler options: Add nano libs to Include path
-
-  - Example:
-    ``gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/newlib-nano``
-
-- Linker Options: Replace fpu lib paths with hard lib and enable nano specs
-
-  - Example: ``"<SYS/BIOS Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu"``
-     with ``"<SYS/BIOS
-     Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard --specs=nano.specs”``
-
-**Additional References:**
-
-- PDK Project Creation Scipt:
-  ``<pdk_soc_x_x_x/packages/pdkProjectCreate.[bat/sh]>``
-
-**Note:** For baremetal applications, stack section needs to be aligned to 8
-bytes. Updated GCC toolchain is more stringent on memory alignment requirement.
-Misalignment can result in unexpected run time failures.
-
-EMAC Library
-^^^^^^^^^^^^
-**Migration:**
-Limited to C6657, OMAPL137/C6747 and OMAPL138/C6748 SoCs.
-
-**Additional Details:**
-Interrupt setup and ISR functions are implemented in the driver. Interrupt
-handling in applications need to be removed to use the latest driver
-version. Use ``EMAC_socGetInitCfg()`` and ``EMAC_socSetInitCfg()`` functions to
-change the default interrupt mapping in HW attributes if required.
-
-Example:
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V0             emac_hwattr;  /* Local instance for HW attributes */
-   EMAC_OPEN_CONFIG_INFO_T     open_cfg;
-
-   EMAC_socGetInitCfg(port_num, &emac_hwattr);  /* Get default SOC HW attributes */
-   emac_hwattr.txIntrNum = <Int Num>  /* Change default interrupt mapping Optional: if needed */
-   EMAC_socSetInitCfg(port_num, &emac_hwattr); /* Change the default HW attributes */
-   open_cfg.hwAttrs = &emac_hwattr;  /* Assign HW attributes to configuration parameters */
-   emac_open(port_num, &open_cfg);
-
-
-Processor SDK 04.01
--------------------
-
-Common CSL Library
-^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to Bare metal Application and Keystone SoCs such as K2HK/K2LE/K2G. No
-change required for other SoCs such as AM571x/AM572x/C6678/C6657.
-
-**Additional Details:**
-Default start address for the vectors modified to beginning of MSMCSRAM
-(``0x0C000000``) compared to previous release end of the MSMC. This matches to
-both secured and non secured devices Application is required to reserve
-(``0x0C000000 to 0x0C000040``) size 0x40 bytes.
-
-Bare metal Application needs to reserve this location for vectors when using CSL
-startup library. There is still option for overriding default configuration by
-defining ``vector_base`` to desired start address: Example: if the vector
-location desired is say ``0xC0E0000``, then add below line in the application's
-linker command file:
-
-.. code-block:: c
-
-   __vector_base__= 0xC0E0000;
-
-No change needed for application using default configuration matching CSL.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration required for applications using default icss_dualemac
-and icss_switch firmware.*
-
-The location of ``icss_emacFwConfig.c/.h`` has moved from
-``ti/drv/icss_emac/firmware/<SOC_TYPE>`` directory to
-``ti/drv/icss_emac/firmware/icss_dualemac/config/`` directory. If applications
-are compiled with ``icss_emacFwConfig.c``, please update your build/make
-infrastructure.
-
-Processor SDK 04.00
--------------------
-MCSDK 1.1 to Processor SDK Migration for OMAPL13x/C674x devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This release includes additional support for OMAPL13x/C674x
-architecture/SOCs. For more information on migrating aplications from
-MCSDK(OMAPL13x) to Processor SDK, see `this migration page
-<MCSDK_Migration_for_OMAPL13x_>`__.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Required. Application will need to link to firmware binaries.*
-
-ICSS EMAC driver component includes source code support for Dual-emac firmware
-with support for rebuilding. Firmware is no longer supported as header format
-*.h in order to align to PRUSS compiler.
-
-- In order to include new binary application will need to link the PRUSS
-  firmware binary as demonstrated through ``*project.txt``. **Note: firmware
-  binary to be linked will be dependent on the SOC as shown below**
-
-**Example:**
-*AM572x have support for both version so include both version of
-binaries and linker \*.cmd files.*
-
-.. code-block:: c
-
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU0.bin
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU1.bin
-
-- Default linker command file is available in PDK software which can be linked
-  by application based on cores where application is running. For A8, A9, A15
-  cores below linker command can be linked in makefile or CCS project. Refer the
-  ICSS-EMAC Unittest for additional details.
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_a8_a9_a15_<REVISION>.cmd
-
-- For c66 and m4 cores
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_c66_m4_<REVISION>.cmd
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact in case of applications using custom board
-library which is not following similar approach as default board library for
-Ethernet PHY configurations.*
-
-Updated Board library for OMAPL137 in this release includes additional Ethernet
-PHY initialization support for reference EVM during init and hence requiring
-dependency on I2C LLD. This is applicable to applications using default OMAPL137
-board library similar to other PDK/Processor SDK applications in the
-release. For all those cases linking to additional I2C LLD library will be
-required.
-
-Examples for including I2C LLD library for:
-
-- Baremetal Applications
-
-Include the I2C LLD library from below mentioned path in makefile or linker
-command file:
-
-- **ARM Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/arm9/release/ti.drv.i2c.ae9``
-- **DSP Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/c674/release/ti.drv.i2c.ae674``
-
-- SYS/BIOS RTOS Applications
-
-Include the I2C LLD library in SYS/BIOS config file using xdc load package
-module:
-
-.. code-block:: c
-
-   var devType = "omapl137"
-   var I2c     = xdc.loadPackage('ti.drv.i2c');
-   I2c.Settings.socType = devType;
-
-McASP Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact for applications initializing the structure using
-memset and default configuration: ``Mcasp_WordBitsSelect_LSB()``.*
-
-McASP driver includes additional configuration field in
-``Mcasp_ChanParams->wordBitsSelect`` to enable newly introduced mode
-Mcasp_WordBitsSelect_MSB. Configuration needs to be initialized by application.
-
-Processor SDK 03.xx Releases
-============================
-
-Processor SDK 03.03
--------------------
-
-Processor SDK 03.02
--------------------
-
-PDK I2C LLD
-^^^^^^^^^^^
-To support I2C slave mode, added ``I2C_transactionInit()`` API. Applications
-need to call ``I2C_transactionInit()`` API before calling ``I2C_transfer()``
-API.
-
-**Example:**
-
-.. code-block:: c
-
-   I2C_Transaction   transaction;
-   I2C_transactionInit(&transaction);
-   transaction.masterMode   = false;
-   transaction.writeCount = wrLen;
-   transaction.readCount  = rdLen;
-   transaction.timeout    = timeout;
-   I2C_transfer(i2c, &transaction);
-
-PDK MCASP LLD
-^^^^^^^^^^^^^
-The call back function's behavior has changed. The MCASP driver no longer
-modifies the ``cArg`` parameter of the registered call back function to indicate
-the transaction type(TX or RX). The cArg paramter will be unchanged and passed
-back to the application. Please refer to the examples, which have been updated
-to reflect this change.
-
-PDK MMCSD LLD
-^^^^^^^^^^^^^
-No update required for use of default SOC dependent library.This is applicable
-for applications which choose to include the ``soc/MMCSDDMA_soc.c``. The
-``soc/MMCSDDMA_soc.c`` file has now been removed as a part of combining the DMA
-and Non-DMA source code of the MMCSD library. Applications may include
-``soc/MMCSD_soc.c`` file instead.
-
-PDK USB LLD
-^^^^^^^^^^^
-- Cache is now supported. Buffers that are passed to low level USB bulk API's
-  need to be cache-size aligned. These include buffers passed to:
-  ``USBHMSCBlockWrite()``, ``USBHMSCBlockRead()``, ``USBHostRead()``,
-  ``USBHostWrite()``, or ``usbSetupEpReq()``, etc.
-
-- DMA is enabled by default on AM335x. Remove DMA_MODE flag in
-  ``build/makefile.mk`` to go back to FIFO mode.
-
-PDK ICSS EMAC LLD
-^^^^^^^^^^^^^^^^^
-Support has been added to all allow the icss-emac LLD to be configured with
-custom firmware memory map parameters which fall into the following 2
-categories:
-
-- *Static configuration*: Tied directly to the firmware. For example, location and
-  size of statistics, port status and conrol address offsets.
-
-- *Dynamic configuration*: Tuneable parameters based on application. For
-  example, sizes of TX/RX queues, port specific buffer/buffer descriptor
-  offsets.
-
-A complete list of these parameters can be found in
-``ti/drv/icss_emac/icss_emacDrv.h``. Refer to ``ICSS_EmacFwStaticMmap`` and
-``ICSS_EmacFwDynamicMmap`` structures.
-
-Firmare binaries which reside in ``ti/drv/icss_emac/firmware/<SOC>`` directory
-should be accompanied by a ``icss_emacFwConfig.c`` file. For existing firmware
-binaries in this release, there is an equivelent ``icss_emacFwConfig.c`` file
-already present. This file basically defines the 2 stuctures mentioned
-above. This file needs to be compiled in as part of the user application. User
-application can then use the following 2 newly introduced API's to "get" and
-"set" firmware memory map configuration parameters with the LLD and firmware.
-
-- ``icss_emacGetFwMMapInitConfig()``: Allows for retrieval of default firmware
-  memory map configuration. User application may call this if they wish to
-  update dynamic firmware memory map configuration paremeters. Static
-  configuration parameters MUST not be updated.
-
-- ``icss_emacSetFwMMapInitConfig()``: Allows for static and dynamic firmware
-  memory map configuration parameters to be configured into the the LLD and
-  firmware.
-
-Note that these API's need to be called prior to calling ``ICSS_EmacInit()``
-which is LLD's initialization function.
-
-Backward compatibility is also supported. If user application does not wish to
-update any configuration parameters, LLD will operate of default configuration
-parameters as specified in respective ``icss_emacFwConfig.c`` file which is
-being delivered as part of this release.
-
-TI-RTOS
-^^^^^^^
-The updated version of TI-RTOS (SYS/BIOS) includes a check to ensure the proper
-run-time library is linked. If you face a compilation issue, see `this note on
-RTOS FAQ <SYSBIOS_reentsupport_error_faq_>`__ for more information.
-
-Processor SDK 03.01
--------------------
-PDK CSL
-^^^^^^^
-- ``csl_a15init`` module is renamed to ``csl_init`` to support portability. The
-  impact of this change is limited to bare metal application using PDK makefile
-  infrastructure. As part of migration, the module name need to be updated.
-
-- ``csl_a15Aux.h`` is removed as it is duplicate of ``csl_a15.h``. The impact of
-  this change is limited to applications that include ``csl_a15Aux.h``. As part
-  of migration, the modification required is to include ``csl_a15.h`` instead.
-
-PDK SA LLD (K2x, C66x)
-^^^^^^^^^^^^^^^^^^^^^^
-Added a feature to select Air Cipher Engine over the default Encryption engine
-for algorithms such as AES_CTR part of ``Sa_DataModeConfigParams_t`` API. There
-is no migration impact if application is initializing the structure to zero
-using memset.
-
-Processor SDK 03.00
--------------------
-This release is a maintenance update with new features and bug fixes. The major
-number in the version changed to stay aligned with the Linux package that moved
-to 2016 LTS.
-
-Device Drivers
-^^^^^^^^^^^^^^
-- Locations of precompiled libraries have moved for the following PDK
-  components: ``CSL, PDK Examples, GPIO, GPMC, I2C, ICSS-EMAC, McASP, McSPI,
-  MMC-SD, PCIe, PRUSS, QSPI, UART, USB, VPS, PDK Utils, FATFS, BOARD, OSAL,
-  NIMU, NIMU_ICSS``. The overall change is to rename armv7 to a15/a8/a9 as
-  appropriate for the device. All cores have moved the libraries compiled with
-  optimization to ``release``, while a debug folder is available (but not
-  prebuilt) for libraries with ``-g``.
-
-  - No changes are needed for applications configured with a XDC/BIOS *.cfg with
-    dependancies specified through xdc.useModule or xdc.loadPackage because
-    updated library paths are autogenerated.
-
-  - For other applications which explicitly set libraries and/or library include
-    paths via ``-l, -I, or -L`` flags passed to the linker, the library paths
-    need to be updated. For example, for GPIO on A15, the path changes from
-    ``ti/drv/gpio/lib/am572x/armv7`` to ``ti/drv/gpio/lib/am572x/a15/release``.
-
-- The drivers GPIO, I2C, SPI and UART now use CSL-FL. Applications using these
-  drivers need to add include and library dependencies by adding xdc.useModule
-  for CSL-FL for XDC/BIOS based applications, or by adding ``-I/-l/-L`` paths to
-  the compilation/linker flags for the application. For XDC, here is a sample
-  code for adding CSL-FL:
-
-.. code-block:: javscript
-
-   /*use CSL package*/
-   var socType = "am571x";
-   var Csl     = xdc.loadPackage('ti.csl');
-
-   Csl.Settings.deviceType = socType;
-
-- The driver I2C has an API change for I2C_transfer, a new timeout field is
-  added to ``I2C_Transaction`` structure, and the return value type of this API
-  is changed from ``bool`` to ``int16_t``. In the test/example application,
-  timeout value need to be initialized before calling this API:
-
-**Example:**
-
-.. code-block:: c
-
-   int16_t status;
-
-   i2cTransaction.slaveAddress = I2C_EEPROM_ADDR;
-   i2cTransaction.writeBuf = (uint8_t *)&txBuf[0];
-   i2cTransaction.writeCount = I2C_EEPROM_TEST_LENGTH + I2C_EEPROM_ADDR_SIZE;
-   i2cTransaction.readBuf = NULL;
-   i2cTransaction.readCount = 0;
-   i2cTransaction.timeout   = I2C_TRANSACTION_TIMEOUT;
-
-   status = I2C_transfer(handle, &i2cTransaction);
-
-Processor SDK 02.xx Releases
-============================
-
-Processor SDK 02.00.02
-----------------------
-This release primarily adds support for K2G device. There is no migration impact
-to customers using devices supported in the previous release (AM3, AM4, AM5,
-C665x, C667x, K2E, K2H, K2K, K2L).
-
-Processor SDK 02.00.01
-----------------------
-This release primarily adds support for devices from the KeyStone architecture:
-C665x, C557x, K2E, K2H, K2K, and K2L. There is no migration impact to customers
-using devices supported in the previous release (AM3, AM4, AM5).
-
-For information on migrating from BIOS-MCSDK (C66x) or MCSDK (K2x) to Processor
-SDK, see `this migration page <MCSDK_Migration_Guide_>`__.
-
-Processor SDK 02.00.00
-----------------------
-**This is the initial Processor SDK RTOS release from Texas Instruments unifying
-platform software across multiple SOC's.**
-
-The strategy for forward/backwards compatibility is as follows:
-
-- `Device Drivers <Device_Drivers_>`__
-
-  - All new development efforts should use Device Drivers because:
-
-    - Device Drivers will maintain common APIs for all supported SoCs
-    - Customer applications can be easily ported to new and additional SoCs
-      hence providing scalable software platform
-    - All new features and development will occur only in the Device Drivers.
-
-- StarterWare is included for AM335x and AM437x for backwards compatibility with
-  Industrial SDK 02.01.00.01
-
-  - This will be maintenance only (bugs will be fixed, no new features)
-
-For applications that already depend on StarterWare from Industrial SDK
-02.01.00.01 on AM335x/AM437x, those APIs remain in Processor SDK in:
-
-- **AM335x SOC:** ``pdk_am335x_1_0_0/ti/starterware``
-- **AM437x SOC:** ``pdk_am437x_1_0_0/ti/starterware``
-
-.. _Linux_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#tools-create-sd-card-linux-label
-.. _Windows_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#windows-sd-card-creation-guide
-.. _NDK_Migration_Guide: http://software-dl.ti.com/targetcontent/ndk/3_40_01_01/exports/ndk_3_40_01_01/docs/ndk/NDK_2_to_3_Migration_Guide.html
-.. _Device_Drivers: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index.html#Device_Drivers
-.. _MCSDK_Migration_Guide: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk-to-processor-sdk-migration-guide
-.. _MCSDK_Migration_for_OMAPL13x: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk1-1-to-processor-sdk-linux-migration-guide-for-omapl13x-devices
-.. _SYSBIOS_reentsupport_error_faq: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/FAQ.html#Why_do_I_get_a_.22undefined_reference_to_.60ti_sysbios_rts_gnu_ReentSupport_checkIfCorrectLibrary.27.22_error_when_compiling_my_application.3F
diff --git a/source/devices/AM335X/rtos/Release_Specific_Release_Notes.rst b/source/devices/AM335X/rtos/Release_Specific_Release_Notes.rst
deleted file mode 100644
index e34bc2154..000000000
--- a/source/devices/AM335X/rtos/Release_Specific_Release_Notes.rst
+++ /dev/null
@@ -1,726 +0,0 @@
-.. _processor-sdk-rtos-release-notes:
-
-*************
-Release Notes
-*************
-
-Overview
-========
-
-The **Processor Software Development Kit (Processor-SDK)** provides the
-core foundation and building blocks that facilitate application software
-development on TI's embedded processors. This *Release Notes* focuses on
-the Real-time operating system (RTOS).
-
-|
-
-Licensing
-=========
-
-Please refer to the software manifest, which outlines the licensing
-status for all packages included in this release. The manifest can be
-found on the SDK download page or in the installed directory as
-indicated below.
-
-|
-
-Documentation
-=============
-
--  :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`:
-   Provides information on getting the software and running basic
-   examples/demonstrations bundled in the SDK.
--  :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` Provides
-   migration information for applications built on top of the Processor
-   SDK for RTOS.
--  :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>`
-   Provides information on features, functions, delivery package and,
-   compile tools for the Processor SDK RTOS release. This also provides
-   detailed information regarding software elements and software
-   infrastructure to allow developers to start creating applications.
--  **Software Manifest**: Provides license information on software
-   included in the SDK release. This document is in the release at
-   ``/processor_sdk_rtos_<SOC>_<version>/docs`` and available to view
-   from the software download page.
--  **EVM Quick Start Guide**: Provides information on hardware setup and
-   running the demonstration application that is loaded on flash. This
-   document is provided as part of the EVM kit.
-
-|
-
-Processor SDK v06.03.00
-=======================
-
-Released Apr 2020
-
-.. rubric::  What's New
-   :name: whats-new
-
-.. rubric::  New Features
-   :name: new-features
-
-- Generic Updates
-    - Sysbios update to 6.76.03.01
-    - TI ARM CGT update to 18.12.5 LTS
-
-- Descoped features
-    - Sercos3 softmaster demo on AM335x
-
-.. _release-notes-component-version:
-
-.. rubric::  Component Version
-   :name: component-version
-
-The following software components and host tools are bundled with the
-SDK installer. See the :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>` for
-more information on each item.
-
-.. note::
-   | This release has been tested with the following component and tool versions. It is recommended to use the versions listed here to avoid compatibility issues.
-
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  Component  |   Version  |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E  | K2L  | K2G  |C665x |C667x |OMAP-L137|OMAP-L138|
-+=============+============+======+======+======+======+=======+======+======+======+======+======+=========+=========+
-| CG_XML      | 2.61.0     |   X  |  X   |  X   |  X   |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-| CTOOLSLIB   | 2.2.0.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  DSPLIB     | 3.4.0.4    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  EDMA3 LLD  | 2.12.5.30  |   X  |  X   |  X   |      |       |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  FC         | 3.40.2.7   |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  FFTLIB     | 3.1.0.0    |      |      |      |      |       |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  IMGLIB     | 3.1.1.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  IPC        | 3.50.4     |      |      |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |         |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  LIBARCH    | 1.0.0.0    |      |      |      |      |   X   |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  LINALG     | 1.2.0.0    |      |      |      |      |   X   |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  MATHLIB    | 3.1.2.4    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  MPM        | 3.0.4.0    |      |      |      |      |   X   |  X   |  X   |  X   |      |      |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  NDK        | 3.61.1     |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  NS         | 2.60.1     |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  OPENCL     | 1.2.0.2    |      |      |  X   |      |       |      |      |      |      |      |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  OPENMP     | 2.6.3.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  PDK        |            |1.0.17|1.0.17|1.0.17| 1.0.7| 4.0.16|4.0.16|4.0.16|1.0.16|2.0.16|2.0.16|  1.0.11 |  1.0.11 |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  SYS/BIOS   | 6.76.3.1   |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  UIA        | 2.30.1.2   |      |      |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  XDAIS      | 7.24.0.4   |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  XDCTOOLS   | 3.55.02    |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-
-
-The following compilers are bundled with the SDK installer:
-
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|    Compiler    | Version |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E | K2L    |  K2G   |C665x|C667x|OMAP-L137|OMAP-L138|
-+================+=========+======+======+======+======+=======+=====+========+========+=====+=====+=========+=========+
-|GNU ARM Embedded|7-2018-q2|   A8 |  A9  |  A15 |      |  A15  | A15 | A15    |  A15   |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|GNU Linaro GCC  | 7.2.1   |      |      |      | A53  |       |     |        |        |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI ARM CGT      | 18.12.5 |      |      |  M4  |  R5  |       |     |A15(SBL)|        |     | ARM9|   ARM9  |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI C6000 CGT    | 8.3.2   |      |      | C66x |      | C66x  |C66x | C66x   |  C66x  |C66x |C66x |   C674x |   C674x |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI PRU CGT      | 2.3.2   | PRU  | PRU  | PRU  |  PRU |       |     |  PRU   |        |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-
-The SDK uses Code Composer Studio (CCS) as the integrated development
-environment (IDE) for all devices and EVMs:
-
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-| Component | Version  |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E | K2L | K2G |C665x|C667x|OMAP-L137|OMAP-L138|
-+===========+==========+======+======+======+======+=======+=====+=====+=====+=====+=====+=========+=========+
-|   CCS     | 9.3.0    |   X  |  X   |  X   |  X   |   X   |  X  |  X  |  X  |  X  |  X  |    X    |    X    |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-|   EMU Pack|Sitara    |   X  |  X   |  X   |  X   |       |     |     |     |     |     |         |         |
-|           |Device    |      |      |      |      |       |     |     |     |     |     |         |         |
-|           |1.4.5     |      |      |      |      |       |     |     |     |     |     |         |         |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-|    TI     |8.3.0.0   |   X  |  X   |  X   |  X   |   X   |  X  |  X  |  X  |  X  |  X  |     X   |     X   |
-| Emulators |          |      |      |      |      |       |     |     |     |     |     |         |         |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-
-If you need to install CCS, see the :ref:`CCS installation section <overview-code-composer-studio>`
-in the *Getting Started Guide* for options to select for Processor-SDK.
-
-
-
-Fixed Issues
-============
-
-.. csv-table::
-   :header: "Record ID","Board/s", "Component/s", "Summary"
-   :widths: 15, 20,20,30
-
-	PRSDK-7627,"am654x-evm, am654x-hsevm, am654x-idk",PRUSS-Firmware,ICSSG: firmware - support changing of speed/duplex on the fly from DUT
-	PRSDK-7722,am654x-idk,PDK,PN_Switch: EMAC LLD free_pkt_cb callback function returns invalid data
-	PRSDK-5935,"am654x-evm, j721e-evm",UNIFLASH,Flashing speed for OSPI with Uniflash 5.0 is very poor (about 7KB/s)
-	PRSDK-6109,"am654x-evm, am654x-hsevm, am654x-idk, j721e-evm",Boot,ROM load time of SBL increased on GP devices because SBL is not signed with ROM degeneratekey
-	PRSDK-7907,am572x-evm,Chip Support,AM572x GP EVM eth0 is not working at 10Mbps
-	PRSDK-8171,"am335x-evm, beagleboneblack",PDK,UART DMA Transmission and Receiving isn't working
-	PRSDK-8343,am654x-idk,SCIClient,Sciclient_pmDeviceReset failing on SDK 6.3
-	PRSDK-7120,"j721e-evm, k2g-evm",PDK,SPI master slave test fails in non-dma callback mode
-	PRSDK-5966,"am654x-evm, am654x-hsevm, am654x-idk",Boot,PLL settings for Maxwell are not optimal
-	PRSDK-5397,am574x-idk,Chip Support,"CSL ECC EMIF test hangs at ""OCMC FULL ECC Mode"" on ARM"
-	PRSDK-7292,"am335x-evm, am335x-ice, amic110-ice, beagleboneblack",Control Drivers,AM335x SPI: No DMA support for McSPI slave mode examples
-	PRSDK-7898,j721e-evm,"Board Support, PDK",PSDKRA release docs indicate Uniflash support exists for J721E
-	PRSDK-8136,"am654x-evm, am654x-hsevm, am654x-idk",Chip Support,AM65xx: NAVSS bit field definitions missing from CSL
-	PRSDK-7518,am572x-evm,Documentation,PRSDK docs contains incorrect info concerning AM572x GP EVM camera support
-	PRSDK-8116,"am654x-evm, am654x-idk, j721e-evm",SCIClient,[SCICLIENT] Trail bytes logic overwrites response parameters
-	PRSDK-7958,am572x-idk,Control Drivers,AM57xx: C66 repeated McSPI loopback transfer crashes
-	PRSDK-8092,"am654x-evm, am654x-idk",Chip Support,AM65xx: A53_0 CSL ePWM example build incorrect & run-time failure
-	PRSDK-7489,"am571x-idk, am572x-idk",OSAL,AM57xx: OSAL Timer on DSP requires Board_init() with UART_STDIO_INIT
-	PRSDK-8020,"am654x-evm, am654x-idk",Documentation,AM65xx:R5F Incorrect documentation concerning RTOS template app
-	PRSDK-8117,"am570x-evm, am571x-idk, am572x-evm, am572x-idk, am574x-idk",Chip Support,AM5728: CSL cache API always returns error
-	PRSDK-3727,"c6748-evm, c6748-lcdk",PDK,C6748 is missing from SOC description list in pdkProjectCreate
-	PRSDK-8114,c6657-evm,Networking,C6657 NIMU ping test failure for packet size greater than 1510 bytes
-
-Known Issues
-============
-
-This section contains the list of known issues at the time of making the
-release and any known workaround.
-
-.. csv-table::
-   :header: "Record ID","Board/s","Component/s","Summary","Workaround"
-   :widths: 15,100,20,30,20
-
-	PRSDK-769,Posix-SMP Demo DMIPS are wrong,Demonstrations,Multiple Platforms
-	PRSDK-5642,USB_DevBulk_ExampleProject: Failed to load/run app,Board Support,am335x-evm,Use JTAG to load and run the example
-	PRSDK-5186,"*Multiple platforms",Board Support,PDK Driver examples wrongly puts libgcc in to DDR invalidating IO delay configuration,"The user application could explicitly place the libgcc.a in to OCMC RAM along with BOARD_IO_DELAY_DATA/CODE sections so that there is no DDR access while calling IO Delay functions "
-	PRSDK-6653,"Diagnostics tests(Haptics,Temperature,Accelerometer,ADC,Ambient light, button, mmcsd) hangs on evmAM335x/AM437x",Diagnostics,"am335x-evm, am437x-evm"
-	PRSDK-2336,"am335x-evm, am437x-evm",Power,AM3 & AM4 PM Examples experience I2C bus lockup when communicating with PMIC,"The debug versions of the PM apps are still functional. To build them: From the top-level makefile in pdk.../packages folder run ""make BUILD_PROFILE=debug pm"" This will build the debug versions of the PM RTOS and measurement apps."
-	PRSDK-6043,TI-RTOS Kernel Example does not work with Resource Explorer in CCS 9.x,CCS,Multiple Platforms
-	PRSDK-8163,output from pinmux template file for AM335x causes ADP_Stopped exception in Board_init(),Board Support,am335x-ice,Existing pinmux files available in release will need to be updated
-	PRSDK-8300,"Diag(MEM,LED,MMCSD) test failures on am335x-ice",Diagnostics,am335x-ice
-	PRSDK-6184,BIOS 6.75 newlib-nano and header incompatibility with GCCv7.3.1 toolchain in SDK,System Integration,Multiple Platforms
-	PRSDK-335,USB host MSC fails to re-enumerate,High-Speed Drivers,"am437x-evm, k2g-evm",Re-enumeration support for the case of device unplugged and plugged back currently fails for the example. Workaround is to avoid disconnecting drive while running example
-	PRSDK-6161,ICSS_EMAC_BasicExample fails on AM437x IDK with errors in received acyclic pkt content,Networking,am437x-idk
-	PRSDK-5936,IO-Link master example does not work with Balluff inductive coupler,PDK,am437x-idk
-	PRSDK-4583,PRUSS-I2C-FW: Does not support 1Mhz mode. Incorrect STOP condition generated for HS mode,PRUSS-Firmware,am437x-idk
-	PRSDK-5938,I2C Master Slave Example: SPI TX/RX FIFO trigger level test failure (UT1),PDK,"am437x-idk, am571x-idk, am572x-idk"
-    PRSDK-2892,"am571x-idk, am572x-evm, am572x-idk",PDK,Incorrect A15 MMU configurations in default config file,"Set MMU attribute to not executable for device memory attrs0.noExecute = true; // Not executable"
-	PRSDK-5087,ICSS_EMAC_BasicExample fails on AM57xx-IDK with Packet cyclic timestamp error,Networking,"am571x-idk, am572x-idk, am574x-idk"
-	PRSDK-3876,CM_EMU_CLKSTCTRL=0x2 needed for reliable low power exit if EMU[1:0] pins are used as GPIOs,Boot,am572x-evm
-	PRSDK-5987,UART Rx/TX trigger level test fails in SMP mode for AM572x EVM (DMA),Control Drivers,am572x-evm
-	PRSDK-4667,Image Processing Demo lock up on AM572x GP EVM,"Demonstrations, Networking",am572x-evm,Issue seen using 1Gig router on ETH0. Replace with 100Mbps
-	PRSDK-1975,timer_DiagExample_evmAM572x_arm7.out doesn't work on ARM1 core,Diagnostics,am572x-evm,Example can run on ARM Core 0
-	PRSDK-6958,pm_rtos_testapp DSP/M4: shutdown test failed,Power,am572x-evm
-	PRSDK-3656,PM: shutdown test failed on DSP core for am572x-evm,Power,am572x-evm
-	PRSDK-8170,AM57xx: A15 QSPI flash block erase & DMA mode write issues,Control Drivers,am572x-idk,Use non-DMA (cpu based copy) instead of the DMA transfer
-	PRSDK-5879,Board: Board library needs to cover entire DDR region connected to EMIF1,Board Support,am654x-evm
-    PRSDK-7735,am65xx:Need to optimize time it takes to poll for packets from udma rings on R5,am654x-idk,"emac_poll_ctrl API is used to poll for rx packets, rx management responses and tx completion events. The parameters to this API are the port number, bitmap of receive packets, bitmap of management rings, and bitmap of tx completion rings to poll. The bitmaps are specified in the driver interface header file. In order to reduce the polling interval, it is recommended to call this API with only bitmap of rings that are required to be polled for an applications use call rather than polling for all the rings. Note that for release 6.3 applications and libraries for rR5F core are being compiled in thumb mode and initial testing indicates a ~20% reduction in cycle time versus release 6.1"
-	PRSDK-6382,SBL: R5F: Core 1 boot is not working with unsigned binary with ipc images,Boot,am654x-evm
-	PRSDK-4661,Maxwell: Board diagnostics LCD touchscreen test reports incorrect number of touch events,Diagnostics,"am654x-evm, am654x-hsevm, am654x-idk"
-	PRSDK-7908,R5 Board Diagnostics Apploader crashes on AM65x (PG1 & 2),PDK,"am654x-evm, am654x-hsevm, am654x-idk",Board Diagnostics can be executed from A53
-	PRSDK-7176,AM65x R5 diagnostic tests are hanging while running from diag framework,Board Support,"am654x-evm, am654x-idk"
-	PRSDK-2951,Maxwell_M4_Diag: LCD Display Diagnostic Stress Test,"Board Support, Diagnostics","am654x-evm, am654x-idk"
-	PRSDK-5074,McASP driver hangs with small buffer size,PDK,"am654x-evm, j721e-evm",Use packet size 32 samples or greater
-	PRSDK-5626,OSPI Read using UDMA fails on AM65x HS devices.,"Boot, DMA",am654x-hsevm,Non-DMA mode could be used for the read operation
-	PRSDK-5229,PCIe diagnostic test validates only one port on PCIe 2-lane card,Board Support,am654x-idk
-	PRSDK-5989,USB Host MSC test hangs in SMP mode on AM65xx IDK board,Control Drivers,am654x-idk
-	PRSDK-5751,AM65xx IDK PCIe diagnostic test failure,Diagnostics,am654x-idk
-	PRSDK-5022,am65xx: Running emac unit test on R5 core from ddrless SBL at times does not complete execution,Networking,am654x-idk
-	PRSDK-3114,K2G: RTOS ECC support broken on ARM core,Diagnostics,"k2g-evm, k2g-hsevm, k2g-ice"
-	PRSDK-2989,MMCSD LLD fails on OMAPl137 with 1024 byte block size,High-Speed Drivers,omapl137-evm
-	PRSDK-4043,OMAPL13x: USB Baremetal project binaries not built via top level make,High-Speed Drivers,"omapl137-evm, omapl138-lcdk"
-
-.. _RN-Supported-Platforms-label:
-
-Supported Platforms
-===================
-
-Devices
--------
-
-The following table lists all supported devices for a given installer.
-
-+----------------+------------+-------------------------------------------------------------------------------+
-|   Installer    |Platform/SOC|                                 Supported Devices                             |
-+================+======+=====+===============================================================================+
-|                |`AM335x`_   | `AM3351`_, `AM3352`_, `AM3354`_, `AM3356`_, `AM3357`_, `AM3358`_, `AM3359`_   |
-|`RTOS-AM335X`_  +------------+-------------------------------------------------------------------------------+
-|                |`AMIC11x`_  | `AMIC110`_                                                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-AM437X`_  |`AM437x`_   | `AM4376`_, `AM4377`_, `AM4378`_, `AM4379`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-AM57X`_   |`AM57x`_    |`AM5706`_, `AM5708`_, `AM5716`_, `AM5718`_, `AM5726`_, `AM5728`_,              |
-|                |            |`AM5746`_, `AM5748`_                                                           |
-+----------------+------------+-------------------------------------------------------------------------------+
-| `RTOS-AM65X`_  | `AM65x`_   |`AM6526`_, `AM6527`_, `AM6528`_, `AM6546`_, `AM6548`_, DRA80xM                 |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-C665X`_   |`C665x`_    | `C6652`_, `C6654`_, `C6655`_, `C6657`_                                        |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-C667X`_   |`C667x`_    | `C6671`_, `C6672`_, `C6674`_, `C6678`_                                        |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2E`_     |`K2E`_      | `66AK2E02`_, `66AK2E05`_, `AM5K2E02`_, `AM5K2E04`_                            |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2G`_     |`K2G`_      | `66AK2G02`_, `66AK2G12`_                                                      |
-+----------------+------------+-------------------------------------------------------------------------------+
-|                |`K2H`_      | `66AK2H06`_, `66AK2H12`_, `66AK2H14`_                                         |
-| `RTOS-K2HK`_   +------------+-------------------------------------------------------------------------------+
-|                |`K2K`_      | `TCI6638K2K`_                                                                 |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2L`_     |`K2L`_      | `66AK2L06`_                                                                   |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-OMAPL137`_|`OMAP-L1x`_ | `OMAP-L137`_, `C6743`_, `C6745`_, `C6747`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-OMAPL138`_|`OMAP-L1x`_ | `OMAP-L138`_, `C6742`_, `C6746`_, `C6748`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-
-
-.. _RTOS-AM335X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM335X/latest/index_FDS.html
-.. _AM335x: http://www.ti.com/am335x
-.. _AM3351: http://www.ti.com/product/am3351
-.. _AM3352: http://www.ti.com/product/am3352
-.. _AM3354: http://www.ti.com/product/am3354
-.. _AM3356: http://www.ti.com/product/am3356
-.. _AM3357: http://www.ti.com/product/am3357
-.. _AM3358: http://www.ti.com/product/am3358
-.. _AM3359: http://www.ti.com/product/am3359
-
-.. _AMIC11x: http://www.ti.com/lsds/ti/processors/sitara/industrial-ethernet/amic11x/amic11x-overview.page>`__
-.. _AMIC110: http://www.ti.com/product/amic110
-
-.. _RTOS-AM437X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM437X/latest/index_FDS.html
-.. _AM437x: http://www.ti.com/am437x
-.. _AM4376: http://www.ti.com/product/am4376
-.. _AM4377: http://www.ti.com/product/am4377
-.. _AM4378: http://www.ti.com/product/am4378
-.. _AM4379: http://www.ti.com/product/am4379
-
-.. _RTOS-AM57X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/latest/index_FDS.html
-.. _AM57x: http://www.ti.com/am57x
-.. _AM5706: http://www.ti.com/product/am5706
-.. _AM5708: http://www.ti.com/product/am5708
-.. _AM5716: http://www.ti.com/product/am5716
-.. _AM5718: http://www.ti.com/product/am5718
-.. _AM5726: http://www.ti.com/product/am5726
-.. _AM5728: http://www.ti.com/product/am5728
-.. _AM5746: http://www.ti.com/product/am5746
-.. _AM5748: http://www.ti.com/product/am5748
-
-.. _RTOS-AM65X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM65X/latest/index_FDS.html
-.. _AM65x: http://www.ti.com/am65x
-.. _AM6526: http://www.ti.com/product/am6526
-.. _AM6527: http://www.ti.com/product/am6527
-.. _AM6528: http://www.ti.com/product/am6528
-.. _AM6546: http://www.ti.com/product/am6546
-.. _AM6548: http://www.ti.com/product/am6548
-
-.. _RTOS-C665X: http://software-dl.ti.com/processor-sdk-rtos/esd/C665x/latest/index_FDS.html
-.. _C665x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp/c66x/overview.page
-.. _C6652: http://www.ti.com/product/tms320c6652
-.. _C6654: http://www.ti.com/product/tms320c6654
-.. _C6655: http://www.ti.com/product/tms320c6655
-.. _C6657: http://www.ti.com/product/tms320c6657
-
-.. _RTOS-C667X: http://software-dl.ti.com/processor-sdk-rtos/esd/C667x/latest/index_FDS.html
-.. _C667x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp/c66x/overview.page
-.. _C6671: http://www.ti.com/product/tms320c6671
-.. _C6672: http://www.ti.com/product/tms320c6672
-.. _C6674: http://www.ti.com/product/tms320c6674
-.. _C6678: http://www.ti.com/product/tms320c6678
-
-.. _RTOS-K2E: http://software-dl.ti.com/processor-sdk-rtos/esd/K2E/latest/index_FDS.html
-.. _K2E: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2E02: http://www.ti.com/product/66ak2e02
-.. _66AK2E05: http://www.ti.com/product/66ak2e05
-.. _AM5K2E02: http://www.ti.com/product/am5k2e02
-.. _AM5K2E04: http://www.ti.com/product/am5k2e04
-
-.. _RTOS-K2G: http://software-dl.ti.com/processor-sdk-rtos/esd/K2G/latest/index_FDS.html
-.. _K2G: http://www.ti.com/processors/dsp/c6000-dsp-arm/66ak2x/overview.html
-.. _66AK2G02: http://www.ti.com/product/66ak2g02
-.. _66AK2G12: http://www.ti.com/product/66ak2g12
-
-.. _RTOS-K2HK: http://software-dl.ti.com/processor-sdk-rtos/esd/K2HK/latest/index_FDS.html
-.. _K2H: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2H06: http://www.ti.com/product/66ak2h06
-.. _66AK2H12: http://www.ti.com/product/66ak2h12
-.. _66AK2H14: http://www.ti.com/product/66ak2h14
-
-.. _K2K: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _TCI6638K2K: http://www.ti.com/product/tci6638k2k
-
-.. _RTOS-K2L: http://software-dl.ti.com/processor-sdk-rtos/esd/K2L/latest/index_FDS.html
-.. _K2L: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2L06: http://www.ti.com/product/66ak2l06
-
-.. _RTOS-OMAPL137: http://www.ti.com/tool/processor-sdk-omapl137
-.. _OMAP-L1x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/omap-l1x/overview.page
-.. _OMAP-L137: http://www.ti.com/product/OMAP-L137
-.. _C6743: http://www.ti.com/product/tms320c6743
-.. _C6745: http://www.ti.com/product/tms320c6745
-.. _C6747: http://www.ti.com/product/tms320c6747
-
-.. _RTOS-OMAPL138: http://www.ti.com/tool/processor-sdk-omapl138
-.. _OMAP-L1x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/omap-l1x/overview.page
-.. _OMAP-L138: http://www.ti.com/product/OMAP-L138
-.. _C6742: http://www.ti.com/product/tms320c6742
-.. _C6746: http://www.ti.com/product/tms320c6746
-.. _C6748: http://www.ti.com/product/tms320c6748
-
-Evaluation Modules
-------------------
-
-See :ref:`Processor SDK Supported Platforms <RTOS-SDK-Supported-Platforms>`
-page for a list of supported EVMs per platform and links to more
-information.
-
-Demonstrations
---------------
-
-See :ref:`Examples and Demonstrations <index-examples-demos>`
-page for a list of demonstrations per platform and EVM.
-
-Drivers
--------
-
-The following tables show RTOS driver availability per platform and EVM.
-A shaded box implies that the feature is not applicable for that
-platform/EVM.
-
-**Sitara devices**
-
-+------------------+--------------------------------+---------------+-----------+-----------+-----------+----------+
-|     Feature      |    Platform/SOC                |  AM335x EVM   |AM437x EVM | AM57x EVM | AM65x EVM |J721E EVM |
-+==================+=======+======+=====+=====+=====+===+===+===+===+===+===+===+=====+=====+=====+=====+==========+
-|                  |AM335x |AM437x|AM57x|AM65x|J721E|GP |ICE|SK |BBB|GP |IDK|SK | GP  | IDK | GP  | IDK |  GP      |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| CSL              |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| EMAC             |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| EDMA3            |   X   |   X  |  X  |     |     | X |   |   |   | X |   |   |  X  |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| GPIO             |   X   |   X  |  X  |  X  |  X  |   | X |   | X | X |   | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| GPMC             |   X   |   X  |     |     |     |   | X |   |   | X |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| I2C              |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS-I2C f/w    |   X   |   X  |  X  |     |     |   | X |   |   |   | X |   |     |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS-eSPI f/w   |   X   |   X  |     |     |     |   |   |   |   |   |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| ICSS-EMAC        |   X   |   X  |  X  |  X  |     |   | X |   |   |   | X |   |     |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| McASP            |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| McSPI            |   X   |   X  |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |   X |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| MMC-SD           |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PCIe             |       |      |  X  |  X  |     |   |   |   |   |   |   |   |     |  X  |  X  |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PM               |   X   |      |  X  |  X  |  X  | X |   |   |   |   |   |   |  X  |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS            |   X   |   X  |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| QSPI             |       |   X  |  X  |  X  |  X  |   |   |   |   |   | X | X |     |  X  |     |     |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| OSPI             |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| UART             |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB              |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |   X |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB Device Audio |   X   |      |     |     |     | X |   |   |   |   |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB Device Bulk  |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |   X |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| VPS              |       |      |  X  |     |     |   |   |   |   |   |   |   |  X  |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| UDMA             |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| SCICLIENT        |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| SA               |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| CAL              |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| DSS              |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| FVID2            |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-
-**DSP devices - K2x, C66x**
-
-+------------------+-------------------------------+-----------------------+-----------+
-|     Feature      |         Platform/SOC          |        K2 EVM         | C66x EVM  |
-+==================+=======+===+===+===+=====+=====+===+===+===+===+=======+=====+=====+
-|                  |K2H/K2K|K2E|K2L|K2G|C665x|C667x|K2H|K2E|K2L|K2G|K2G-ICE|C665x|C667x|
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| CSL              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| AIF2             |   X   |   |   |   |     |     | X |   |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| BCP              |   X   |   | X |   |     |     | X |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| CPPI             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| DFE              |       |   | X |   |     |     |   |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| EDMA3            |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| EMAC             |       |   |   | X |  X  |     |   |   |   | X |   X   |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| FFTC             |   X   |   | X |   |     |     | X |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| GPIO             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| HYPLNK           |   X   | X |   |   |  X  |  X  | X | X |   |   |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| ICSS-EMAC        |       |   |   | X |     |     |   |   |   |   |   X   |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| I2C              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IQN2             |       |   | X |   |     |     |   |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| McASP            |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| McBSP            |       |   |   | X |  X  |     |   |   |   | X |       |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MMAP             |   X   | X |   |   |     |     | X | X |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MMC-SD           |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| NWAL             |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PA               |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PCIe             |   X   | X | X | X |  X  |  X  | X | X | X | X |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| QMSS             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| RM               |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SA               |   X   | X | X | X |     |  X  | X | X | X | X |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SPI              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SRIO             |   X   |   |   |   |  X  |  X  | X |   |   |   |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| TCP3D            |   X   |   | X |   |  X  |     | X |   | X |   |       |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| TSIP             |       | X |   |   |     |  X  |   | X |   |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| UART             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB              |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB Device Audio |       |   |   |   |     |     |   |   |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB Device Bulk  |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-
-
-**DSP devices - OMAP-L13x, C674x**
-
-+----------------+-------------------+-------------+----------------+
-|    Feature     |   Platform/SOC    |OMAP-L137 EVM| OMAP-L138 EVM  |
-+================+=========+=========+=============+=======+========+
-|                |OMAP-L137|OMAP-L138| L137/6747 SK|LCDK138|LCDK6748|
-+----------------+---------+---------+-------------+-------+--------+
-|CSL             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|EDMA3           |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|EMAC            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|GPIO            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|I2C             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|McASP           |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|MMC-SD          |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|SPI             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|UART            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB Device Audio|    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB Device Bulk |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-
-**Unsupported Features**
-
-- In general driver support is available across all cores within an SOC
-  with following exceptions
-
-+----------------+-------------------+
-|    Feature     | Not supported     |
-+================+=========+=========+
-|                |SOC      |CPU/Core |
-+----------------+---------+---------+
-|McASP           |  AM57x  |    M4   |
-+----------------+---------+---------+
-|USB             |  AM57x  |    C66x |
-+----------------+---------+---------+
-|USB             |  AM57x  |    M4   |
-+----------------+---------+---------+
-|USB             |  K2G    |    C66x |
-+----------------+---------+---------+
-|McBSP           |  K2G    |    A15  |
-+----------------+---------+---------+
-|McBSP           |OMAP-L13x|    ARM9 |
-+----------------+---------+---------+
-|All Drivers     | K2E/L/K |    A15  |
-+----------------+---------+---------+
-
-Other Features
---------------
-
-The following table shows other feature availability per platform and
-EVM:
-
-**Sitara devices**
-
-+----------------------------+--------------------------------+---------------+-----------+-----------+-----------+ -----------+
-|          Feature           |    Platform/SOC                |   AM335x EVM  |AM437x EVM | AM57x EVM | AM65x EVM |  J721E EVM |
-+============================+=======+======+=====+=====+=====+===+===+===+===+===+===+===+=====+=====+=====+=====+============+
-|                            |AM335x |AM437x|AM57x|AM65x|J721E|GP |ICE|SK |BBB|GP |IDK|SK | GP  | IDK | GP  | IDK |  GP        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Board Support              |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Boot (SBL)                 |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Diagnostics                |   X   |  X   |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| FATFS                      |   X   |  X   |  X  |  X  |  X  | X | X |   |   | X | X |   |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| NDK-NIMU(CPSW)             |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| NDK-NIMU(ICSS)             |   X   |  X   |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-|CC-LINK IE Field Basic(CPSW)|   X   |  X   |  X  |     |     | X | X | X | X | X | X | X |  X  |  X  |     |     |            |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-|CC-Link IE Field Basic(ICSS)|   X   |  X   |  X  |     |     |   | X |   |   |   | X |   |     |  X  |     |     |            |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-
-**DSP devices - K2x, C66x**
-
-+----------------------------+-------------------------------+-----------------------+-----------+
-|          Feature           |         Platform/SOC          |        K2 EVM         | C66x EVM  |
-+============================+=======+===+===+===+=====+=====+===+===+===+===+=======+=====+=====+
-|                            |K2H/K2K|K2E|K2L|K2G|C665x|C667x|K2H|K2E|K2L|K2G|K2G-ICE|C665x|C667x|
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Board Support              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Boot (IBL/SBL)             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Diagnostics                |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| FATFS                      |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Fault Management           |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IPC Transport (QMSS)       |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IPC Transport (SRIO)       |   X   |   |   |   |  X  |  X  | X |   |   |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MAD-UTIL                   |       |   |   |   |  X  |  X  |   |   |   |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Network (CPSW)             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Network (ICSS)             |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-|CC-Link IE Field Basic(ICSS)|       |   |   | X |     |     |   |   |   | X |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-|Platform Library (obsolete) |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PKTLIB                     |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| POST                       |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SERDES Diagnostics         |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Trace Framework            |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-
-
-**DSP devices - OMAP-L13x, C674x**
-
-+--------------+-------------------+-------------+----------------+
-|   Feature    |   Platform/SOC    |OMAP-L137 EVM| OMAP-L138 EVM  |
-+==============+=========+=========+=============+=======+========+
-|              |OMAP-L137|OMAP-L138| 137/6747 SK |LCDK138|LCDK6748|
-+--------------+---------+---------+-------------+-------+--------+
-|Board Support |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Boot (SBL)    |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Diagnostics   |    X    |         |      X      |       |        |
-+--------------+---------+---------+-------------+-------+--------+
-|FATFS         |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Network (CPSW)|    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-
-Installation and Usage
-======================
-
-The :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>` provides
-instructions on how to setup up your development environment, install
-the SDK and start your development.
-
-To uninstall the SDK, remove the individual component directories from
-the installed path. This is safe to do even in Windows since these
-components do not modify the Windows registry.
-
-|
-
-Technical Support and Product Updates
-=====================================
-
-For further information or to report any problems, contact:
--  `TI E2E Processor Support <https://e2e.ti.com/support/processors/>`__ for all supported platforms
-
-
-|
-
-Archived
-========
--  `Processor-SDK RTOS
-   6.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_01_00_08/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   6.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_00_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_03_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.2.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_02_00_10/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_01_00_11/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_15/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 AM65x EA Release <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_09/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   4.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/04_03_00_05/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
-
-**Note:** Release Notes prior to 4.3 are not archived. Please see the
-:ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` for information on
-migration from these releases.
-
diff --git a/source/devices/AM335X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst b/source/devices/AM335X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst
deleted file mode 100644
index 010962ca8..000000000
--- a/source/devices/AM335X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-.. _RTOS-SDK-Supported-Platforms:
-.. include:: /common/Release_Specific/_Processor_SDK_Supported_Platforms_and_Versions.rst
diff --git a/source/devices/AM335X/rtos/index.rst b/source/devices/AM335X/rtos/index.rst
deleted file mode 100644
index 0887c6cff..000000000
--- a/source/devices/AM335X/rtos/index.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-.. _rtos-index:
-
-.. include:: /rtos/Overview/_Processor_SDK_RTOS_Software_Developers_Guide.rst
-
-.. toctree::
-   :maxdepth: 5
-   :hidden:
-   :numbered:
-
-   /rtos/Overview
-   Release_Specific
-   /rtos/Board_EVM_Abstration
-   /rtos/Foundational_Components
-   /rtos/Device_Drivers
-   /rtos/PRU_ICSS
-   /rtos/Compilers
-   /rtos/Examples_and_Demonstrations
-   /rtos/How_to_Guides
-   /rtos/FAQ
-   /rtos/Documentation_Tarball
-
-|
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/devices/AM335X/rtos/version.txt b/source/devices/AM335X/rtos/version.txt
deleted file mode 100644
index 84e924eb7..000000000
--- a/source/devices/AM335X/rtos/version.txt
+++ /dev/null
@@ -1 +0,0 @@
-07_01_00
diff --git a/source/devices/AM437X/rtos/Release_Specific.rst b/source/devices/AM437X/rtos/Release_Specific.rst
deleted file mode 100644
index 92255b3ed..000000000
--- a/source/devices/AM437X/rtos/Release_Specific.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-##################
-Release Specific
-##################
-
-.. toctree::
-   :maxdepth: 5
-
-   Release_Specific_Release_Notes
-   Release_Specific_Supported_Platforms_and_Versions
-   Release_Specific_Migration_Guide
diff --git a/source/devices/AM437X/rtos/Release_Specific_Migration_Guide.rst b/source/devices/AM437X/rtos/Release_Specific_Migration_Guide.rst
deleted file mode 100644
index 3f56e1d4a..000000000
--- a/source/devices/AM437X/rtos/Release_Specific_Migration_Guide.rst
+++ /dev/null
@@ -1,867 +0,0 @@
-.. _RTOS-SDK-Migration-Guide-label:
-
-***************
-Migration Guide
-***************
-
-Overview
-========
-
-This page covers migration information for applications built on top
-of the Processor SDK RTOS.
-
-Processor SDK 06.xx Releases
-============================
-
-Processor SDK 06.03
--------------------
-
-Building PDK components from GIT repositories
-=============================================
-
-**Migration:** Change in git repository for PDK components.
-
-**Impact Scope:** Applicable for most drivers packaged in the PDK when used in development environment
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) had their own git respositories which could be cloned and used for development or picking up bugfixes which are not yet released through a processor sdk release.
-From this release onwards, most of the drivers in the PDK are moved to the new pdk.git repository(https://git.ti.com/cgit/processor-sdk/pdk) and its components (drivers) moved in to their respective locations inside the pdk_<soc>_<ver> of the Processor SDK installation.
-For example the i2c driver has been moved from https://git.ti.com/cgit/keystone-rtos/i2c-lld to https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/drv/i2c. Consequently, the latest updates on a PDK driver should be fetched from the new pdk.git repo (https://git.ti.com/cgit/processor-sdk/pdk) as the older repos are rendered obselete.
-
-Building of libraries of individual PDK components
-==================================================
-
-**Migration:** Building individual drivers' librabries/apps of PDK from PDK's top level makefile is not supported
-
-**Impact Scope:** Applicable for PDK top level makefile
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) could be built from
-the top level makefile (pdk_xx/packages/makefile) using commands like "make uart_lib/uart_apps". This is no longer supported.
-Instead, the libraries and applications could either be built using "make all" from the top level makefile or issuing "make libs/apps" from within the module's directory.
-
-
-Processor SDK 06.01
--------------------
-
-NIMU
-====
-
-**Migration:** Udma init sequence call has been moved from NIMU library to NIMU example for AM65xx
-
-**Impact Scope:** Applicable for all NIMU applications using NIMU tranport library for AM65xx
-
-**Additional Details**:
-Applications will need to implement the following function to provide UDMA drive handle which will be called by the NIMU driver at startup
-
- Udma_DrvHandle nimu_app_get_udma_handle(void)
-
-Processor SDK 06.00
--------------------
-
-PRUSS
-^^^^^
-**Migration:**
-Calls that passed ``PRUICCSS_INSTANCE_MAX`` as a parameter to PRUSS driver API
-calls will now pass ``PRUICCSS_INSTANCE_THREE`` instead.
-
-**Impact Scope:**
-Applicable for all AM65xx applications using PRUSS driver for ICSSG use case.
-
-**Additional Details:**
-The following new enumeration, ``PRUICCSS_INSTANCE_THREE``, for PRU-ICSS
-instance 3 has been added to ``PRUICSS_MaxInstances`` enumeration list as
-``PRUICCSS_INSTANCE_MAX`` is not longer valid when making PRUSS driver API
-calls.
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-MMU configuration is needed to enable NBO CFG registers access on A53 core.
-
-**Impact Scope:**
-Applicable for all AM65xx RTOS applications calling ``Board_init()`` with
-``BOARD_INIT_ICSS_ETH_PHY`` flag.
-
-**Additional Details:**
-Board library is setting ``NAVSS THREADMAP`` register to give higher priority
-for MSMC access from ICSSG which requires access to ``NBO CFG`` registers.
-
-
-Processor SDK 05.xx Releases
-============================
-
-Processor SDK 05.03
--------------------
-
-EMAC
-^^^^
-**Migration-1:**
-ICSS-G EMAC firmware binary directory location update for future extension.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Applications will need to update the include path to location of firmware header
-files for ICSSG use case:
-
-- **Prevous location:** ``ti/drv/emac/firmeare/icss_eth/src/dm``
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/bin``
-
-**Migration-2:**
-Release introduces support for additional firmware specific configuration
-files. Added for future extension to support multiple firmwares using same EMAC
-driver.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Firmware configuration has been moved to firmware specific configuration files,
-``emac_fw_config_dual_mac.h`` and ``emac_fw_config_dual_mac.c``. Previously the
-firmware configuration was specified in the test application. It is not expected
-that applicatons will need to modify these files as the are closely tied to the
-firmware.
-
-- **Previous location:** firmware specific configuration was specified in the
-  text application (``ti/drv/emac/test/EmacLoopbackTest/test_utils_k3.c``)
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/config/``
-
-Applications will need to update their makefiles to include c source file
-``emac_fw_config_dual_mac.c``.
-
-At time of ``emac_open()`` API call, applications need to udpate configuruation
-parameters to pass get firmware configuration pointer :
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V5 emac_cfg;
-   EMAC_socGetInitCfg(0, &emac_cfg);
-   emac_cfg.portCfg[port_num].getFwCfg = &emacGetDualMacFwConfig;
-   EMAC_socSetInitCfg(0, &emac_cfg);
-
-CSL
-^^^
-**Migration:**
-API changes on CSL-FL of AM65xx on ecc aggregator, vim, esm modules
-
-**Impact Scope**:
-Limited to the case if application is using the CSL-FL APIs
-
-**Additional Details**:
-The CSL-FL for ECC aggregator, ESM and VIM are modified to return API
-functionality success/failures and additional arguments are added as and when
-needed (especially during the cases where the return was the value instead of
-API success/failure). Applications that use these CSL-FL calls are impacted and
-are needed to align to new calling conventions. If applicable application
-modification required to align to updated APIs, refer doxygen API documentation
-for API details.
-
-
-DSP- TI CGT Compiler
-^^^^^^^^^^^^^^^^^^^^
-
-**Migration:**
-In DSP TI CGT compiler version 8.3.2 the rts library boot object file name is
-changed from ``boot.obj`` to ``boot.c.obj``.
-
-**Impact Scope:**
-Limited only to DSP applications that explicitly uses rts library object files
-in linker command file.
-
-**Additional Details:**
-The DSP application which is using linker command file of CSL module should
-change boot object name from boot.obj file to ``boot.c.obj``. If the user is
-using cpp version of boot object file then it should be mentioned as
-``boot.cpp.obj``. In general it can be also be used as ``boot.*.obj``. This can
-be referred from the following linker command file in the PDK package
-``<PDK>/packages/ti/csl/example/lnk_dsp.cmd``
-
-Processor SDK 05.02
--------------------
-
-SBL
-^^^
-**Migration:**
-Image integration and memory map changes.
-
-**Additional Details:**
-Release supports optimized boot times for booting MCU1_0 core from OSPI
-flash. To reduce the size of the SBL,  the system firmware image, which was
-earlier embedded in the SBL, is now a separate binary. The system firmware image
-can be found at ``<PDK>/packages/ti/drv/sciclient/soc/V0/sysfw.bin``
-
-For MMC/SD boot, if the steps followed in :ref:`Windows SD Card Creation Guide
-<windows-sd-card-creation-guide>` or :ref:`Linux SD Card
-Creation Guide <tools-create-sd-card-linux-label>` are
-used, no additional steps are need. If the SD card is being created manually,
-then the ``sysfw.bin`` file also needs to be copied into the root directory of
-the MMC SD card, along with ``tiboot3.bin`` and ``app``.
-
-For OSPI boot, the flash offsets have changed. ``sysfw.bin`` needs to be
-programmed into OSPI flash at offset ``0x40000`` (new for this release), along
-with ``sbl_ospi_img_mcu1_0_release.tiimage`` at offset ``0x0`` (no change from
-previous release) and the ``app`` at offset ``0xA0000`` (was ``0x80000``
-previous release).  For details please refer `Programming the OSPI flash
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Board_EVM_Abstration.html#uniflash>`__
-
-Applications that the SBL loads must co-exist with the SBL's memory usage.In the
-application's linker command file, care must be taken to not use the first 0x100
-bytes of MCU1_0's ATCM memory and SBL reserved memory from ``0x41C00100 to
-0x41C28000``. If the applications violate the SBL memory usage, then apps that
-were working with the last release might not work any more, as the memory
-constraints are tighter. For details, refer the `SBL Memory Utilization
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Foundational_Components.html#am655x-sbl-memory-usage>`__
-
-PDK
-^^^
-**Migration:**
-AM65xx PDK component dependency on sciclient module.
-
-**Impact Scope:**
-Applications will need to link to sciclient module library. No migration impact
-if application is already linking the library.
-
-**Additional Details**:
-All application using PDK components on AM65xx platform will need to link
-sciclient library  as components internally will be using sciclient API for PLL
-and interrupt configuration. In this release, requirement for application will
-be more mandated as more components are using common infrastructure.
-
-DMSC firmware should be loaded onto Cortex-M4 core using SBL or :ref:`CCS GEL script
-<advanced-am65x-debug-setup-with-dmsc-firmware-load>`
-before calling the Board Init API with 'BOARD_INIT_PLL' flag.
-
-Board
-^^^^^
-**Migration:**
-New APIs for EEPROM Board ID Information
-
-**Impact Scope:**
-Applications using Board ID info APIs on AM65xx platform. No migration impact
-for existing applications and boards using version 1 API.
-
-**Additional Details**:
-TI Board ID information format has been updated to new version on AM65xx. New
-board library APIs ``Board_getIDInfo_v2()`` and ``Board_writeIDInfo_v2()`` are
-added to support new Board ID information format. Old Board ID info APIs are
-still avaialble to retain the backward build compatibility but returns error
-when used on AM65xx platform.
-
-FATFS
-^^^^^
-**Migration:**
-FATFS module in this release includes multipartition support and capability of
-detecting single vs multiple partitions run time.
-
-**Impact Scope:**
-Limited to the case if user had used MS-DOS Floppy disk format for formatting
-the SD/eMMC memory. No impact if the SD/eMMC is formatted using the steps
-provided by :ref:`Windows SD Card Creation Guide
-<windows-sd-card-creation-guide>`/:ref:`Linux SD Card Creation
-Guide <tools-create-sd-card-linux-label>`.
-
-**Additional Details**:
-Partition entry information may be wrongly detected for the storage media
-formated to  MS-DOS Floppy disk format. FATFS APIs fail to access the disk in
-this case.
-
-**Workaround**:
-Format the storage media using the steps provided by :ref:`Windows SD Card Creation
-Guide <windows-sd-card-creation-guide>`/:ref:`Linux SD Card
-Creation Guide <tools-create-sd-card-linux-label>`
-in case this issue is observed.
-
-Processor SDK 05.01
--------------------
-
-Build
-^^^^^
-**Migration:**
-Applicable for applications migrating from SOCs supporting EDMA LLD to AM65x
-with updated DMA infrastructure. Additional UDMA driver support is available in
-package to support enhanced DMA infrastrcuture for AM65x Drivers for AM65x SOC
-is extended to support UDMA LLD abstracting changes needed by
-application. Limited change will be required for application using drivers
-included in Processor SDK.
-
-**Additional Details**:
-Modifications needed at application will be limited to initialization of UDMA
-driver using Udma_init() API in addition to linking  UDMA driver library. Driver
-Test code could be used as reference Additional migration details for all cases
-are covered in ``/ti/drv/udma/docs`` folder inside PDK package.
-
-DMA
-^^^
-**Migration:**
-For all drivers using DMA mode EDMA driver is updated to UDMA driver.
-
-**Additional Details:**
-Application will need to initialize UDMA driver and SCIClient interface using
-``Udma_init()`` and ``Sciclient_init()`` API. Test code could be used as
-reference.
-
-Networking
-^^^^^^^^^^
-**Migration:**
-Applicable for applications using NDK and Posix port of SysBIOS.
-
-**Additional Details:**
-Release introduces NS (Network Services Component) as independent portable
-networking API abstracting different network stacks. Detailed migration details
-is available at `NDK 2.x to 3.x Migration Guide <NDK_Migration_Guide_>`__
-
-Processor SDK 05.00
--------------------
-
-Build
-^^^^^
-**Migration:**
-``TOOLS_INSTALL_PATH`` macro value changed to ``SDK_INSTALL_PATH``. No migration
-impact if tools and SDK are installed in same location.
-
-**Additional Details:**
-``TOOLS_INSTALL_PATH`` macro value is set to ``SDK_INSTALL_PATH`` by
-default. For accessing the tools from a different path, modify
-``TOOLS_INSTALL_PATH`` in ``packages/ti/build/Rules.make`` file or can be
-overriden from the build console as shown below.
-
-Windows
-
-.. code:: console
-
-   set TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-Linux
-
-.. code:: console
-
-   TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-
-Build Setup
-^^^^^^^^^^^
-**Migration:**
-There is no migration need for components used within processor SDK. Application
-Software outside processor SDK may require a change if there is a dependency to
-internal Processor SDK environment variables. See more details below.
-
-**Additional Details:**
-Rules.make file is used instead of pdksetupenv to setup the build environment
-variables. Components inside processor SDK are updated to align with this
-change. Any applications making use of pdksetupenv from processor SDK to setup
-the build environment variables should include below line in the application
-makefile.
-
-.. code-block:: c
-
-  include $(RULES_MAKE)
-
-Processor SDK 04.xx Releases
-============================
-
-Processor SDK 04.03
--------------------
-
-OSAL
-^^^^
-**Migration:**
-No impact expected if Semaphore allocation and HwIP registration from OSAL is
-not invoked by application.
-
-**Additional Details:**
-OSAL module is fine tuned for optimized number of semaphores required internally
-within drivers. Module provides additional API to application for additional
-semaphore allocation if required.Application can configure for either default
-internal static allocation or it can select external memory block that can be
-provided to create these objects. Note that this decision to go with external
-memory block or internal memory block need to be done during init configuration
-of application (near to main) just after ``Board_init()`` is called. Below
-sample code sets SemaphoreP/HwiP to be used from external memory block:
-
-.. code-block:: c
-
-   /* Get the Hw Attrs */
-   osal_ret = Osal_getHwAttrs(&hwAttrs);
-   if (osal_ret != osal_OK)
-   {
-       return (false);
-   }
-
-   /* This API should set to use external memory block */
-   hwAttrs.extSemaphorePBlock.base = (uintptr_t) &semPMemBlock[0];
-   hwAttrs.extSemaphorePBlock.size = SEMP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.size       = HWIP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.base       = (uintptr_t) &hwiPMemBlock[0];
-   osal_ret = Osal_setHwAttrs(ctrlBitMap, &hwAttrs);
-
-
-Board
-^^^^^
-**Migration:**
-Section details applicable only to applications based on DRA7xx SoCs.
-
-**Additional Details**:
-DRA7xx board libraries have refactored pad configuration sequence by removing
-manual pinmux entries and replacing them with a full IODELAY reconfiguration
-procedure. This was done in order to simplify transition from a standalone
-application development in CCS to booting the whole device via SBL, ensuring
-that pad configuration is 100% consistent between the two application loading
-methods.
-
-The IODELAY and pin control data structures are maintained in each of evmDRA72x
-and evmDRA75x board library source directories. These structures are also
-included in the SBL compilation and used in the SBL's IODELAY
-reconfiguration. Therefore, changes can be made in one location but reused by
-both Board and SBL components just through recompilation.
-
-Note that DRA78x does not require IODELAY reconfiguration and pinmux setup is
-always contained entirely in the application. Hence, there are no corresponding
-changes to this library.
-
-All of this is done in a transparent manner, so there is **no API change** and
-will not affect existing applications. However, there are considerations with
-respect to memory placement and potential conflicts between the board library
-and SBL code. These restrictions have always existed but are now more clearly
-defined and documented. Please refer to :ref:`Board Support
-<board-board-support>` for more details.
-
-I2C
-^^^
-**Migration:**
-No migration required for existing user application.
-
-**Additional Details:**
-PRUICSS based I2C Firmware have been introduced in this release. This new
-features increases the number of I2C interface available in the SOC. I2C LLD now
-depends on PRUSS LLD for compilation of this new feature. All of this is done in
-a transparent manner, so there is **no API change** and will not affect existing
-applications. However, for using the I2C FW feature refer :ref:`I2C FW
-<PRU-ICSS-I2C-FIRMWARE-label>` for additional details.
-
-Processor SDK 04.02
--------------------
-
-GCC Toolchain Migration to 6-2017-q1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to TI-RTOS based application on ARM Cortex-A cores.
-
-**Additional Details:**
-Processor SDK RTOS components includes updates to be compatible with GCC tool
-chain. This includes updates to SysBIOS, compiler and linker options. Following
-migration changes required for applications:
-
-- Compiler options: Add nano libs to Include path
-
-  - Example:
-    ``gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/newlib-nano``
-
-- Linker Options: Replace fpu lib paths with hard lib and enable nano specs
-
-  - Example: ``"<SYS/BIOS Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu"``
-     with ``"<SYS/BIOS
-     Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard --specs=nano.specs”``
-
-**Additional References:**
-
-- PDK Project Creation Scipt:
-  ``<pdk_soc_x_x_x/packages/pdkProjectCreate.[bat/sh]>``
-
-**Note:** For baremetal applications, stack section needs to be aligned to 8
-bytes. Updated GCC toolchain is more stringent on memory alignment requirement.
-Misalignment can result in unexpected run time failures.
-
-EMAC Library
-^^^^^^^^^^^^
-**Migration:**
-Limited to C6657, OMAPL137/C6747 and OMAPL138/C6748 SoCs.
-
-**Additional Details:**
-Interrupt setup and ISR functions are implemented in the driver. Interrupt
-handling in applications need to be removed to use the latest driver
-version. Use ``EMAC_socGetInitCfg()`` and ``EMAC_socSetInitCfg()`` functions to
-change the default interrupt mapping in HW attributes if required.
-
-Example:
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V0             emac_hwattr;  /* Local instance for HW attributes */
-   EMAC_OPEN_CONFIG_INFO_T     open_cfg;
-
-   EMAC_socGetInitCfg(port_num, &emac_hwattr);  /* Get default SOC HW attributes */
-   emac_hwattr.txIntrNum = <Int Num>  /* Change default interrupt mapping Optional: if needed */
-   EMAC_socSetInitCfg(port_num, &emac_hwattr); /* Change the default HW attributes */
-   open_cfg.hwAttrs = &emac_hwattr;  /* Assign HW attributes to configuration parameters */
-   emac_open(port_num, &open_cfg);
-
-
-Processor SDK 04.01
--------------------
-
-Common CSL Library
-^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to Bare metal Application and Keystone SoCs such as K2HK/K2LE/K2G. No
-change required for other SoCs such as AM571x/AM572x/C6678/C6657.
-
-**Additional Details:**
-Default start address for the vectors modified to beginning of MSMCSRAM
-(``0x0C000000``) compared to previous release end of the MSMC. This matches to
-both secured and non secured devices Application is required to reserve
-(``0x0C000000 to 0x0C000040``) size 0x40 bytes.
-
-Bare metal Application needs to reserve this location for vectors when using CSL
-startup library. There is still option for overriding default configuration by
-defining ``vector_base`` to desired start address: Example: if the vector
-location desired is say ``0xC0E0000``, then add below line in the application's
-linker command file:
-
-.. code-block:: c
-
-   __vector_base__= 0xC0E0000;
-
-No change needed for application using default configuration matching CSL.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration required for applications using default icss_dualemac
-and icss_switch firmware.*
-
-The location of ``icss_emacFwConfig.c/.h`` has moved from
-``ti/drv/icss_emac/firmware/<SOC_TYPE>`` directory to
-``ti/drv/icss_emac/firmware/icss_dualemac/config/`` directory. If applications
-are compiled with ``icss_emacFwConfig.c``, please update your build/make
-infrastructure.
-
-Processor SDK 04.00
--------------------
-MCSDK 1.1 to Processor SDK Migration for OMAPL13x/C674x devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This release includes additional support for OMAPL13x/C674x
-architecture/SOCs. For more information on migrating aplications from
-MCSDK(OMAPL13x) to Processor SDK, see `this migration page
-<MCSDK_Migration_for_OMAPL13x_>`__.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Required. Application will need to link to firmware binaries.*
-
-ICSS EMAC driver component includes source code support for Dual-emac firmware
-with support for rebuilding. Firmware is no longer supported as header format
-*.h in order to align to PRUSS compiler.
-
-- In order to include new binary application will need to link the PRUSS
-  firmware binary as demonstrated through ``*project.txt``. **Note: firmware
-  binary to be linked will be dependent on the SOC as shown below**
-
-**Example:**
-*AM572x have support for both version so include both version of
-binaries and linker \*.cmd files.*
-
-.. code-block:: c
-
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU0.bin
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU1.bin
-
-- Default linker command file is available in PDK software which can be linked
-  by application based on cores where application is running. For A8, A9, A15
-  cores below linker command can be linked in makefile or CCS project. Refer the
-  ICSS-EMAC Unittest for additional details.
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_a8_a9_a15_<REVISION>.cmd
-
-- For c66 and m4 cores
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_c66_m4_<REVISION>.cmd
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact in case of applications using custom board
-library which is not following similar approach as default board library for
-Ethernet PHY configurations.*
-
-Updated Board library for OMAPL137 in this release includes additional Ethernet
-PHY initialization support for reference EVM during init and hence requiring
-dependency on I2C LLD. This is applicable to applications using default OMAPL137
-board library similar to other PDK/Processor SDK applications in the
-release. For all those cases linking to additional I2C LLD library will be
-required.
-
-Examples for including I2C LLD library for:
-
-- Baremetal Applications
-
-Include the I2C LLD library from below mentioned path in makefile or linker
-command file:
-
-- **ARM Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/arm9/release/ti.drv.i2c.ae9``
-- **DSP Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/c674/release/ti.drv.i2c.ae674``
-
-- SYS/BIOS RTOS Applications
-
-Include the I2C LLD library in SYS/BIOS config file using xdc load package
-module:
-
-.. code-block:: c
-
-   var devType = "omapl137"
-   var I2c     = xdc.loadPackage('ti.drv.i2c');
-   I2c.Settings.socType = devType;
-
-McASP Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact for applications initializing the structure using
-memset and default configuration: ``Mcasp_WordBitsSelect_LSB()``.*
-
-McASP driver includes additional configuration field in
-``Mcasp_ChanParams->wordBitsSelect`` to enable newly introduced mode
-Mcasp_WordBitsSelect_MSB. Configuration needs to be initialized by application.
-
-Processor SDK 03.xx Releases
-============================
-
-Processor SDK 03.03
--------------------
-
-Processor SDK 03.02
--------------------
-
-PDK I2C LLD
-^^^^^^^^^^^
-To support I2C slave mode, added ``I2C_transactionInit()`` API. Applications
-need to call ``I2C_transactionInit()`` API before calling ``I2C_transfer()``
-API.
-
-**Example:**
-
-.. code-block:: c
-
-   I2C_Transaction   transaction;
-   I2C_transactionInit(&transaction);
-   transaction.masterMode   = false;
-   transaction.writeCount = wrLen;
-   transaction.readCount  = rdLen;
-   transaction.timeout    = timeout;
-   I2C_transfer(i2c, &transaction);
-
-PDK MCASP LLD
-^^^^^^^^^^^^^
-The call back function's behavior has changed. The MCASP driver no longer
-modifies the ``cArg`` parameter of the registered call back function to indicate
-the transaction type(TX or RX). The cArg paramter will be unchanged and passed
-back to the application. Please refer to the examples, which have been updated
-to reflect this change.
-
-PDK MMCSD LLD
-^^^^^^^^^^^^^
-No update required for use of default SOC dependent library.This is applicable
-for applications which choose to include the ``soc/MMCSDDMA_soc.c``. The
-``soc/MMCSDDMA_soc.c`` file has now been removed as a part of combining the DMA
-and Non-DMA source code of the MMCSD library. Applications may include
-``soc/MMCSD_soc.c`` file instead.
-
-PDK USB LLD
-^^^^^^^^^^^
-- Cache is now supported. Buffers that are passed to low level USB bulk API's
-  need to be cache-size aligned. These include buffers passed to:
-  ``USBHMSCBlockWrite()``, ``USBHMSCBlockRead()``, ``USBHostRead()``,
-  ``USBHostWrite()``, or ``usbSetupEpReq()``, etc.
-
-- DMA is enabled by default on AM335x. Remove DMA_MODE flag in
-  ``build/makefile.mk`` to go back to FIFO mode.
-
-PDK ICSS EMAC LLD
-^^^^^^^^^^^^^^^^^
-Support has been added to all allow the icss-emac LLD to be configured with
-custom firmware memory map parameters which fall into the following 2
-categories:
-
-- *Static configuration*: Tied directly to the firmware. For example, location and
-  size of statistics, port status and conrol address offsets.
-
-- *Dynamic configuration*: Tuneable parameters based on application. For
-  example, sizes of TX/RX queues, port specific buffer/buffer descriptor
-  offsets.
-
-A complete list of these parameters can be found in
-``ti/drv/icss_emac/icss_emacDrv.h``. Refer to ``ICSS_EmacFwStaticMmap`` and
-``ICSS_EmacFwDynamicMmap`` structures.
-
-Firmare binaries which reside in ``ti/drv/icss_emac/firmware/<SOC>`` directory
-should be accompanied by a ``icss_emacFwConfig.c`` file. For existing firmware
-binaries in this release, there is an equivelent ``icss_emacFwConfig.c`` file
-already present. This file basically defines the 2 stuctures mentioned
-above. This file needs to be compiled in as part of the user application. User
-application can then use the following 2 newly introduced API's to "get" and
-"set" firmware memory map configuration parameters with the LLD and firmware.
-
-- ``icss_emacGetFwMMapInitConfig()``: Allows for retrieval of default firmware
-  memory map configuration. User application may call this if they wish to
-  update dynamic firmware memory map configuration paremeters. Static
-  configuration parameters MUST not be updated.
-
-- ``icss_emacSetFwMMapInitConfig()``: Allows for static and dynamic firmware
-  memory map configuration parameters to be configured into the the LLD and
-  firmware.
-
-Note that these API's need to be called prior to calling ``ICSS_EmacInit()``
-which is LLD's initialization function.
-
-Backward compatibility is also supported. If user application does not wish to
-update any configuration parameters, LLD will operate of default configuration
-parameters as specified in respective ``icss_emacFwConfig.c`` file which is
-being delivered as part of this release.
-
-TI-RTOS
-^^^^^^^
-The updated version of TI-RTOS (SYS/BIOS) includes a check to ensure the proper
-run-time library is linked. If you face a compilation issue, see `this note on
-RTOS FAQ <SYSBIOS_reentsupport_error_faq_>`__ for more information.
-
-Processor SDK 03.01
--------------------
-PDK CSL
-^^^^^^^
-- ``csl_a15init`` module is renamed to ``csl_init`` to support portability. The
-  impact of this change is limited to bare metal application using PDK makefile
-  infrastructure. As part of migration, the module name need to be updated.
-
-- ``csl_a15Aux.h`` is removed as it is duplicate of ``csl_a15.h``. The impact of
-  this change is limited to applications that include ``csl_a15Aux.h``. As part
-  of migration, the modification required is to include ``csl_a15.h`` instead.
-
-PDK SA LLD (K2x, C66x)
-^^^^^^^^^^^^^^^^^^^^^^
-Added a feature to select Air Cipher Engine over the default Encryption engine
-for algorithms such as AES_CTR part of ``Sa_DataModeConfigParams_t`` API. There
-is no migration impact if application is initializing the structure to zero
-using memset.
-
-Processor SDK 03.00
--------------------
-This release is a maintenance update with new features and bug fixes. The major
-number in the version changed to stay aligned with the Linux package that moved
-to 2016 LTS.
-
-Device Drivers
-^^^^^^^^^^^^^^
-- Locations of precompiled libraries have moved for the following PDK
-  components: ``CSL, PDK Examples, GPIO, GPMC, I2C, ICSS-EMAC, McASP, McSPI,
-  MMC-SD, PCIe, PRUSS, QSPI, UART, USB, VPS, PDK Utils, FATFS, BOARD, OSAL,
-  NIMU, NIMU_ICSS``. The overall change is to rename armv7 to a15/a8/a9 as
-  appropriate for the device. All cores have moved the libraries compiled with
-  optimization to ``release``, while a debug folder is available (but not
-  prebuilt) for libraries with ``-g``.
-
-  - No changes are needed for applications configured with a XDC/BIOS *.cfg with
-    dependancies specified through xdc.useModule or xdc.loadPackage because
-    updated library paths are autogenerated.
-
-  - For other applications which explicitly set libraries and/or library include
-    paths via ``-l, -I, or -L`` flags passed to the linker, the library paths
-    need to be updated. For example, for GPIO on A15, the path changes from
-    ``ti/drv/gpio/lib/am572x/armv7`` to ``ti/drv/gpio/lib/am572x/a15/release``.
-
-- The drivers GPIO, I2C, SPI and UART now use CSL-FL. Applications using these
-  drivers need to add include and library dependencies by adding xdc.useModule
-  for CSL-FL for XDC/BIOS based applications, or by adding ``-I/-l/-L`` paths to
-  the compilation/linker flags for the application. For XDC, here is a sample
-  code for adding CSL-FL:
-
-.. code-block:: javscript
-
-   /*use CSL package*/
-   var socType = "am571x";
-   var Csl     = xdc.loadPackage('ti.csl');
-
-   Csl.Settings.deviceType = socType;
-
-- The driver I2C has an API change for I2C_transfer, a new timeout field is
-  added to ``I2C_Transaction`` structure, and the return value type of this API
-  is changed from ``bool`` to ``int16_t``. In the test/example application,
-  timeout value need to be initialized before calling this API:
-
-**Example:**
-
-.. code-block:: c
-
-   int16_t status;
-
-   i2cTransaction.slaveAddress = I2C_EEPROM_ADDR;
-   i2cTransaction.writeBuf = (uint8_t *)&txBuf[0];
-   i2cTransaction.writeCount = I2C_EEPROM_TEST_LENGTH + I2C_EEPROM_ADDR_SIZE;
-   i2cTransaction.readBuf = NULL;
-   i2cTransaction.readCount = 0;
-   i2cTransaction.timeout   = I2C_TRANSACTION_TIMEOUT;
-
-   status = I2C_transfer(handle, &i2cTransaction);
-
-Processor SDK 02.xx Releases
-============================
-
-Processor SDK 02.00.02
-----------------------
-This release primarily adds support for K2G device. There is no migration impact
-to customers using devices supported in the previous release (AM3, AM4, AM5,
-C665x, C667x, K2E, K2H, K2K, K2L).
-
-Processor SDK 02.00.01
-----------------------
-This release primarily adds support for devices from the KeyStone architecture:
-C665x, C557x, K2E, K2H, K2K, and K2L. There is no migration impact to customers
-using devices supported in the previous release (AM3, AM4, AM5).
-
-For information on migrating from BIOS-MCSDK (C66x) or MCSDK (K2x) to Processor
-SDK, see `this migration page <MCSDK_Migration_Guide_>`__.
-
-Processor SDK 02.00.00
-----------------------
-**This is the initial Processor SDK RTOS release from Texas Instruments unifying
-platform software across multiple SOC's.**
-
-The strategy for forward/backwards compatibility is as follows:
-
-- `Device Drivers <Device_Drivers_>`__
-
-  - All new development efforts should use Device Drivers because:
-
-    - Device Drivers will maintain common APIs for all supported SoCs
-    - Customer applications can be easily ported to new and additional SoCs
-      hence providing scalable software platform
-    - All new features and development will occur only in the Device Drivers.
-
-- StarterWare is included for AM335x and AM437x for backwards compatibility with
-  Industrial SDK 02.01.00.01
-
-  - This will be maintenance only (bugs will be fixed, no new features)
-
-For applications that already depend on StarterWare from Industrial SDK
-02.01.00.01 on AM335x/AM437x, those APIs remain in Processor SDK in:
-
-- **AM335x SOC:** ``pdk_am335x_1_0_0/ti/starterware``
-- **AM437x SOC:** ``pdk_am437x_1_0_0/ti/starterware``
-
-.. _Linux_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#tools-create-sd-card-linux-label
-.. _Windows_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#windows-sd-card-creation-guide
-.. _NDK_Migration_Guide: http://software-dl.ti.com/targetcontent/ndk/3_40_01_01/exports/ndk_3_40_01_01/docs/ndk/NDK_2_to_3_Migration_Guide.html
-.. _Device_Drivers: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index.html#Device_Drivers
-.. _MCSDK_Migration_Guide: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk-to-processor-sdk-migration-guide
-.. _MCSDK_Migration_for_OMAPL13x: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk1-1-to-processor-sdk-linux-migration-guide-for-omapl13x-devices
-.. _SYSBIOS_reentsupport_error_faq: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/FAQ.html#Why_do_I_get_a_.22undefined_reference_to_.60ti_sysbios_rts_gnu_ReentSupport_checkIfCorrectLibrary.27.22_error_when_compiling_my_application.3F
diff --git a/source/devices/AM437X/rtos/Release_Specific_Release_Notes.rst b/source/devices/AM437X/rtos/Release_Specific_Release_Notes.rst
deleted file mode 100644
index 7af998114..000000000
--- a/source/devices/AM437X/rtos/Release_Specific_Release_Notes.rst
+++ /dev/null
@@ -1,726 +0,0 @@
-.. _processor-sdk-rtos-release-notes:
-
-*************
-Release Notes
-*************
-
-Overview
-========
-
-The **Processor Software Development Kit (Processor-SDK)** provides the
-core foundation and building blocks that facilitate application software
-development on TI's embedded processors. This *Release Notes* focuses on
-the Real-time operating system (RTOS).
-
-|
-
-Licensing
-=========
-
-Please refer to the software manifest, which outlines the licensing
-status for all packages included in this release. The manifest can be
-found on the SDK download page or in the installed directory as
-indicated below.
-
-|
-
-Documentation
-=============
-
--  :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`:
-   Provides information on getting the software and running basic
-   examples/demonstrations bundled in the SDK.
--  :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` Provides
-   migration information for applications built on top of the Processor
-   SDK for RTOS.
--  :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>`
-   Provides information on features, functions, delivery package and,
-   compile tools for the Processor SDK RTOS release. This also provides
-   detailed information regarding software elements and software
-   infrastructure to allow developers to start creating applications.
--  **Software Manifest**: Provides license information on software
-   included in the SDK release. This document is in the release at
-   ``/processor_sdk_rtos_<SOC>_<version>/docs`` and available to view
-   from the software download page.
--  **EVM Quick Start Guide**: Provides information on hardware setup and
-   running the demonstration application that is loaded on flash. This
-   document is provided as part of the EVM kit.
-
-|
-
-Processor SDK v06.03.00
-=======================
-
-Released Apr 2020
-
-.. rubric::  What's New
-   :name: whats-new
-
-.. rubric::  New Features
-   :name: new-features
-
-- Generic Updates
-    - Sysbios update to 6.76.03.01
-    - TI ARM CGT update to 18.12.5 LTS
-
-- Descoped features
-    - Sercos3 softmaster demo on AM335x
-
-.. _release-notes-component-version:
-
-.. rubric::  Component Version
-   :name: component-version
-
-The following software components and host tools are bundled with the
-SDK installer. See the :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>` for
-more information on each item.
-
-.. note::
-   | This release has been tested with the following component and tool versions. It is recommended to use the versions listed here to avoid compatibility issues.
-
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  Component  |   Version  |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E  | K2L  | K2G  |C665x |C667x |OMAP-L137|OMAP-L138|
-+=============+============+======+======+======+======+=======+======+======+======+======+======+=========+=========+
-| CG_XML      | 2.61.0     |   X  |  X   |  X   |  X   |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-| CTOOLSLIB   | 2.2.0.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  DSPLIB     | 3.4.0.4    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  EDMA3 LLD  | 2.12.5.30  |   X  |  X   |  X   |      |       |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  FC         | 3.40.2.7   |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  FFTLIB     | 3.1.0.0    |      |      |      |      |       |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  IMGLIB     | 3.1.1.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  IPC        | 3.50.4     |      |      |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |         |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  LIBARCH    | 1.0.0.0    |      |      |      |      |   X   |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  LINALG     | 1.2.0.0    |      |      |      |      |   X   |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  MATHLIB    | 3.1.2.4    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  MPM        | 3.0.4.0    |      |      |      |      |   X   |  X   |  X   |  X   |      |      |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  NDK        | 3.61.1     |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  NS         | 2.60.1     |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  OPENCL     | 1.2.0.2    |      |      |  X   |      |       |      |      |      |      |      |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  OPENMP     | 2.6.3.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  PDK        |            |1.0.17|1.0.17|1.0.17| 1.0.7| 4.0.16|4.0.16|4.0.16|1.0.16|2.0.16|2.0.16|  1.0.11 |  1.0.11 |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  SYS/BIOS   | 6.76.3.1   |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  UIA        | 2.30.1.2   |      |      |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  XDAIS      | 7.24.0.4   |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  XDCTOOLS   | 3.55.02    |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-
-
-The following compilers are bundled with the SDK installer:
-
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|    Compiler    | Version |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E | K2L    |  K2G   |C665x|C667x|OMAP-L137|OMAP-L138|
-+================+=========+======+======+======+======+=======+=====+========+========+=====+=====+=========+=========+
-|GNU ARM Embedded|7-2018-q2|   A8 |  A9  |  A15 |      |  A15  | A15 | A15    |  A15   |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|GNU Linaro GCC  | 7.2.1   |      |      |      | A53  |       |     |        |        |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI ARM CGT      | 18.12.5 |      |      |  M4  |  R5  |       |     |A15(SBL)|        |     | ARM9|   ARM9  |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI C6000 CGT    | 8.3.2   |      |      | C66x |      | C66x  |C66x | C66x   |  C66x  |C66x |C66x |   C674x |   C674x |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI PRU CGT      | 2.3.2   | PRU  | PRU  | PRU  |  PRU |       |     |  PRU   |        |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-
-The SDK uses Code Composer Studio (CCS) as the integrated development
-environment (IDE) for all devices and EVMs:
-
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-| Component | Version  |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E | K2L | K2G |C665x|C667x|OMAP-L137|OMAP-L138|
-+===========+==========+======+======+======+======+=======+=====+=====+=====+=====+=====+=========+=========+
-|   CCS     | 9.3.0    |   X  |  X   |  X   |  X   |   X   |  X  |  X  |  X  |  X  |  X  |    X    |    X    |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-|   EMU Pack|Sitara    |   X  |  X   |  X   |  X   |       |     |     |     |     |     |         |         |
-|           |Device    |      |      |      |      |       |     |     |     |     |     |         |         |
-|           |1.4.5     |      |      |      |      |       |     |     |     |     |     |         |         |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-|    TI     |8.3.0.0   |   X  |  X   |  X   |  X   |   X   |  X  |  X  |  X  |  X  |  X  |     X   |     X   |
-| Emulators |          |      |      |      |      |       |     |     |     |     |     |         |         |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-
-If you need to install CCS, see the :ref:`CCS installation section <overview-code-composer-studio>`
-in the *Getting Started Guide* for options to select for Processor-SDK.
-
-
-
-Fixed Issues
-============
-
-.. csv-table::
-   :header: "Record ID","Board/s", "Component/s", "Summary"
-   :widths: 15, 20,20,30
-
-	PRSDK-7627,"am654x-evm, am654x-hsevm, am654x-idk",PRUSS-Firmware,ICSSG: firmware - support changing of speed/duplex on the fly from DUT
-	PRSDK-7722,am654x-idk,PDK,PN_Switch: EMAC LLD free_pkt_cb callback function returns invalid data
-	PRSDK-5935,"am654x-evm, j721e-evm",UNIFLASH,Flashing speed for OSPI with Uniflash 5.0 is very poor (about 7KB/s)
-	PRSDK-6109,"am654x-evm, am654x-hsevm, am654x-idk, j721e-evm",Boot,ROM load time of SBL increased on GP devices because SBL is not signed with ROM degeneratekey
-	PRSDK-7907,am572x-evm,Chip Support,AM572x GP EVM eth0 is not working at 10Mbps
-	PRSDK-8171,"am335x-evm, beagleboneblack",PDK,UART DMA Transmission and Receiving isn't working
-	PRSDK-8343,am654x-idk,SCIClient,Sciclient_pmDeviceReset failing on SDK 6.3
-	PRSDK-7120,"j721e-evm, k2g-evm",PDK,SPI master slave test fails in non-dma callback mode
-	PRSDK-5966,"am654x-evm, am654x-hsevm, am654x-idk",Boot,PLL settings for Maxwell are not optimal
-	PRSDK-5397,am574x-idk,Chip Support,"CSL ECC EMIF test hangs at ""OCMC FULL ECC Mode"" on ARM"
-	PRSDK-7292,"am335x-evm, am335x-ice, amic110-ice, beagleboneblack",Control Drivers,AM335x SPI: No DMA support for McSPI slave mode examples
-	PRSDK-7898,j721e-evm,"Board Support, PDK",PSDKRA release docs indicate Uniflash support exists for J721E
-	PRSDK-8136,"am654x-evm, am654x-hsevm, am654x-idk",Chip Support,AM65xx: NAVSS bit field definitions missing from CSL
-	PRSDK-7518,am572x-evm,Documentation,PRSDK docs contains incorrect info concerning AM572x GP EVM camera support
-	PRSDK-8116,"am654x-evm, am654x-idk, j721e-evm",SCIClient,[SCICLIENT] Trail bytes logic overwrites response parameters
-	PRSDK-7958,am572x-idk,Control Drivers,AM57xx: C66 repeated McSPI loopback transfer crashes
-	PRSDK-8092,"am654x-evm, am654x-idk",Chip Support,AM65xx: A53_0 CSL ePWM example build incorrect & run-time failure
-	PRSDK-7489,"am571x-idk, am572x-idk",OSAL,AM57xx: OSAL Timer on DSP requires Board_init() with UART_STDIO_INIT
-	PRSDK-8020,"am654x-evm, am654x-idk",Documentation,AM65xx:R5F Incorrect documentation concerning RTOS template app
-	PRSDK-8117,"am570x-evm, am571x-idk, am572x-evm, am572x-idk, am574x-idk",Chip Support,AM5728: CSL cache API always returns error
-	PRSDK-3727,"c6748-evm, c6748-lcdk",PDK,C6748 is missing from SOC description list in pdkProjectCreate
-	PRSDK-8114,c6657-evm,Networking,C6657 NIMU ping test failure for packet size greater than 1510 bytes
-
-Known Issues
-============
-
-This section contains the list of known issues at the time of making the
-release and any known workaround.
-
-.. csv-table::
-   :header: "Record ID","Board/s","Component/s","Summary","Workaround"
-   :widths: 15,100,20,30,20
-
-	PRSDK-769,Posix-SMP Demo DMIPS are wrong,Demonstrations,Multiple Platforms
-	PRSDK-5642,USB_DevBulk_ExampleProject: Failed to load/run app,Board Support,am335x-evm,Use JTAG to load and run the example
-	PRSDK-5186,"*Multiple platforms",Board Support,PDK Driver examples wrongly puts libgcc in to DDR invalidating IO delay configuration,"The user application could explicitly place the libgcc.a in to OCMC RAM along with BOARD_IO_DELAY_DATA/CODE sections so that there is no DDR access while calling IO Delay functions "
-	PRSDK-6653,"Diagnostics tests(Haptics,Temperature,Accelerometer,ADC,Ambient light, button, mmcsd) hangs on evmAM335x/AM437x",Diagnostics,"am335x-evm, am437x-evm"
-	PRSDK-2336,"am335x-evm, am437x-evm",Power,AM3 & AM4 PM Examples experience I2C bus lockup when communicating with PMIC,"The debug versions of the PM apps are still functional. To build them: From the top-level makefile in pdk.../packages folder run ""make BUILD_PROFILE=debug pm"" This will build the debug versions of the PM RTOS and measurement apps."
-	PRSDK-6043,TI-RTOS Kernel Example does not work with Resource Explorer in CCS 9.x,CCS,Multiple Platforms
-	PRSDK-8163,output from pinmux template file for AM335x causes ADP_Stopped exception in Board_init(),Board Support,am335x-ice,Existing pinmux files available in release will need to be updated
-	PRSDK-8300,"Diag(MEM,LED,MMCSD) test failures on am335x-ice",Diagnostics,am335x-ice
-	PRSDK-6184,BIOS 6.75 newlib-nano and header incompatibility with GCCv7.3.1 toolchain in SDK,System Integration,Multiple Platforms
-	PRSDK-335,USB host MSC fails to re-enumerate,High-Speed Drivers,"am437x-evm, k2g-evm",Re-enumeration support for the case of device unplugged and plugged back currently fails for the example. Workaround is to avoid disconnecting drive while running example
-	PRSDK-6161,ICSS_EMAC_BasicExample fails on AM437x IDK with errors in received acyclic pkt content,Networking,am437x-idk
-	PRSDK-5936,IO-Link master example does not work with Balluff inductive coupler,PDK,am437x-idk
-	PRSDK-4583,PRUSS-I2C-FW: Does not support 1Mhz mode. Incorrect STOP condition generated for HS mode,PRUSS-Firmware,am437x-idk
-	PRSDK-5938,I2C Master Slave Example: SPI TX/RX FIFO trigger level test failure (UT1),PDK,"am437x-idk, am571x-idk, am572x-idk"
-    PRSDK-2892,"am571x-idk, am572x-evm, am572x-idk",PDK,Incorrect A15 MMU configurations in default config file,"Set MMU attribute to not executable for device memory attrs0.noExecute = true; // Not executable"
-	PRSDK-5087,ICSS_EMAC_BasicExample fails on AM57xx-IDK with Packet cyclic timestamp error,Networking,"am571x-idk, am572x-idk, am574x-idk"
-	PRSDK-3876,CM_EMU_CLKSTCTRL=0x2 needed for reliable low power exit if EMU[1:0] pins are used as GPIOs,Boot,am572x-evm
-	PRSDK-5987,UART Rx/TX trigger level test fails in SMP mode for AM572x EVM (DMA),Control Drivers,am572x-evm
-	PRSDK-4667,Image Processing Demo lock up on AM572x GP EVM,"Demonstrations, Networking",am572x-evm,Issue seen using 1Gig router on ETH0. Replace with 100Mbps
-	PRSDK-1975,timer_DiagExample_evmAM572x_arm7.out doesn't work on ARM1 core,Diagnostics,am572x-evm,Example can run on ARM Core 0
-	PRSDK-6958,pm_rtos_testapp DSP/M4: shutdown test failed,Power,am572x-evm
-	PRSDK-3656,PM: shutdown test failed on DSP core for am572x-evm,Power,am572x-evm
-	PRSDK-8170,AM57xx: A15 QSPI flash block erase & DMA mode write issues,Control Drivers,am572x-idk,Use non-DMA (cpu based copy) instead of the DMA transfer
-	PRSDK-5879,Board: Board library needs to cover entire DDR region connected to EMIF1,Board Support,am654x-evm
-    PRSDK-7735,am65xx:Need to optimize time it takes to poll for packets from udma rings on R5,am654x-idk,"emac_poll_ctrl API is used to poll for rx packets, rx management responses and tx completion events. The parameters to this API are the port number, bitmap of receive packets, bitmap of management rings, and bitmap of tx completion rings to poll. The bitmaps are specified in the driver interface header file. In order to reduce the polling interval, it is recommended to call this API with only bitmap of rings that are required to be polled for an applications use call rather than polling for all the rings. Note that for release 6.3 applications and libraries for rR5F core are being compiled in thumb mode and initial testing indicates a ~20% reduction in cycle time versus release 6.1"
-	PRSDK-6382,SBL: R5F: Core 1 boot is not working with unsigned binary with ipc images,Boot,am654x-evm
-	PRSDK-4661,Maxwell: Board diagnostics LCD touchscreen test reports incorrect number of touch events,Diagnostics,"am654x-evm, am654x-hsevm, am654x-idk"
-	PRSDK-7908,R5 Board Diagnostics Apploader crashes on AM65x (PG1 & 2),PDK,"am654x-evm, am654x-hsevm, am654x-idk",Board Diagnostics can be executed from A53
-	PRSDK-7176,AM65x R5 diagnostic tests are hanging while running from diag framework,Board Support,"am654x-evm, am654x-idk"
-	PRSDK-2951,Maxwell_M4_Diag: LCD Display Diagnostic Stress Test,"Board Support, Diagnostics","am654x-evm, am654x-idk"
-	PRSDK-5074,McASP driver hangs with small buffer size,PDK,"am654x-evm, j721e-evm",Use packet size 32 samples or greater
-	PRSDK-5626,OSPI Read using UDMA fails on AM65x HS devices.,"Boot, DMA",am654x-hsevm,Non-DMA mode could be used for the read operation
-	PRSDK-5229,PCIe diagnostic test validates only one port on PCIe 2-lane card,Board Support,am654x-idk
-	PRSDK-5989,USB Host MSC test hangs in SMP mode on AM65xx IDK board,Control Drivers,am654x-idk
-	PRSDK-5751,AM65xx IDK PCIe diagnostic test failure,Diagnostics,am654x-idk
-	PRSDK-5022,am65xx: Running emac unit test on R5 core from ddrless SBL at times does not complete execution,Networking,am654x-idk
-	PRSDK-3114,K2G: RTOS ECC support broken on ARM core,Diagnostics,"k2g-evm, k2g-hsevm, k2g-ice"
-	PRSDK-2989,MMCSD LLD fails on OMAPl137 with 1024 byte block size,High-Speed Drivers,omapl137-evm
-	PRSDK-4043,OMAPL13x: USB Baremetal project binaries not built via top level make,High-Speed Drivers,"omapl137-evm, omapl138-lcdk"
-
-.. _RN-Supported-Platforms-label:
-
-Supported Platforms
-===================
-
-Devices
--------
-
-The following table lists all supported devices for a given installer.
-
-+----------------+------------+-------------------------------------------------------------------------------+
-|   Installer    |Platform/SOC|                                 Supported Devices                             |
-+================+======+=====+===============================================================================+
-|                |`AM335x`_   | `AM3351`_, `AM3352`_, `AM3354`_, `AM3356`_, `AM3357`_, `AM3358`_, `AM3359`_   |
-|`RTOS-AM335X`_  +------------+-------------------------------------------------------------------------------+
-|                |`AMIC11x`_  | `AMIC110`_                                                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-AM437X`_  |`AM437x`_   | `AM4376`_, `AM4377`_, `AM4378`_, `AM4379`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-AM57X`_   |`AM57x`_    |`AM5706`_, `AM5708`_, `AM5716`_, `AM5718`_, `AM5726`_, `AM5728`_,              |
-|                |            |`AM5746`_, `AM5748`_                                                           |
-+----------------+------------+-------------------------------------------------------------------------------+
-| `RTOS-AM65X`_  | `AM65x`_   |`AM6526`_, `AM6527`_, `AM6528`_, `AM6546`_, `AM6548`_, DRA80xM                 |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-C665X`_   |`C665x`_    | `C6652`_, `C6654`_, `C6655`_, `C6657`_                                        |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-C667X`_   |`C667x`_    | `C6671`_, `C6672`_, `C6674`_, `C6678`_                                        |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2E`_     |`K2E`_      | `66AK2E02`_, `66AK2E05`_, `AM5K2E02`_, `AM5K2E04`_                            |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2G`_     |`K2G`_      | `66AK2G02`_, `66AK2G12`_                                                      |
-+----------------+------------+-------------------------------------------------------------------------------+
-|                |`K2H`_      | `66AK2H06`_, `66AK2H12`_, `66AK2H14`_                                         |
-| `RTOS-K2HK`_   +------------+-------------------------------------------------------------------------------+
-|                |`K2K`_      | `TCI6638K2K`_                                                                 |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2L`_     |`K2L`_      | `66AK2L06`_                                                                   |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-OMAPL137`_|`OMAP-L1x`_ | `OMAP-L137`_, `C6743`_, `C6745`_, `C6747`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-OMAPL138`_|`OMAP-L1x`_ | `OMAP-L138`_, `C6742`_, `C6746`_, `C6748`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-
-
-.. _RTOS-AM335X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM335X/latest/index_FDS.html
-.. _AM335x: http://www.ti.com/am335x
-.. _AM3351: http://www.ti.com/product/am3351
-.. _AM3352: http://www.ti.com/product/am3352
-.. _AM3354: http://www.ti.com/product/am3354
-.. _AM3356: http://www.ti.com/product/am3356
-.. _AM3357: http://www.ti.com/product/am3357
-.. _AM3358: http://www.ti.com/product/am3358
-.. _AM3359: http://www.ti.com/product/am3359
-
-.. _AMIC11x: http://www.ti.com/lsds/ti/processors/sitara/industrial-ethernet/amic11x/amic11x-overview.page>`__
-.. _AMIC110: http://www.ti.com/product/amic110
-
-.. _RTOS-AM437X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM437X/latest/index_FDS.html
-.. _AM437x: http://www.ti.com/am437x
-.. _AM4376: http://www.ti.com/product/am4376
-.. _AM4377: http://www.ti.com/product/am4377
-.. _AM4378: http://www.ti.com/product/am4378
-.. _AM4379: http://www.ti.com/product/am4379
-
-.. _RTOS-AM57X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/latest/index_FDS.html
-.. _AM57x: http://www.ti.com/am57x
-.. _AM5706: http://www.ti.com/product/am5706
-.. _AM5708: http://www.ti.com/product/am5708
-.. _AM5716: http://www.ti.com/product/am5716
-.. _AM5718: http://www.ti.com/product/am5718
-.. _AM5726: http://www.ti.com/product/am5726
-.. _AM5728: http://www.ti.com/product/am5728
-.. _AM5746: http://www.ti.com/product/am5746
-.. _AM5748: http://www.ti.com/product/am5748
-
-.. _RTOS-AM65X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM65X/latest/index_FDS.html
-.. _AM65x: http://www.ti.com/am65x
-.. _AM6526: http://www.ti.com/product/am6526
-.. _AM6527: http://www.ti.com/product/am6527
-.. _AM6528: http://www.ti.com/product/am6528
-.. _AM6546: http://www.ti.com/product/am6546
-.. _AM6548: http://www.ti.com/product/am6548
-
-.. _RTOS-C665X: http://software-dl.ti.com/processor-sdk-rtos/esd/C665x/latest/index_FDS.html
-.. _C665x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp/c66x/overview.page
-.. _C6652: http://www.ti.com/product/tms320c6652
-.. _C6654: http://www.ti.com/product/tms320c6654
-.. _C6655: http://www.ti.com/product/tms320c6655
-.. _C6657: http://www.ti.com/product/tms320c6657
-
-.. _RTOS-C667X: http://software-dl.ti.com/processor-sdk-rtos/esd/C667x/latest/index_FDS.html
-.. _C667x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp/c66x/overview.page
-.. _C6671: http://www.ti.com/product/tms320c6671
-.. _C6672: http://www.ti.com/product/tms320c6672
-.. _C6674: http://www.ti.com/product/tms320c6674
-.. _C6678: http://www.ti.com/product/tms320c6678
-
-.. _RTOS-K2E: http://software-dl.ti.com/processor-sdk-rtos/esd/K2E/latest/index_FDS.html
-.. _K2E: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2E02: http://www.ti.com/product/66ak2e02
-.. _66AK2E05: http://www.ti.com/product/66ak2e05
-.. _AM5K2E02: http://www.ti.com/product/am5k2e02
-.. _AM5K2E04: http://www.ti.com/product/am5k2e04
-
-.. _RTOS-K2G: http://software-dl.ti.com/processor-sdk-rtos/esd/K2G/latest/index_FDS.html
-.. _K2G: http://www.ti.com/processors/dsp/c6000-dsp-arm/66ak2x/overview.html
-.. _66AK2G02: http://www.ti.com/product/66ak2g02
-.. _66AK2G12: http://www.ti.com/product/66ak2g12
-
-.. _RTOS-K2HK: http://software-dl.ti.com/processor-sdk-rtos/esd/K2HK/latest/index_FDS.html
-.. _K2H: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2H06: http://www.ti.com/product/66ak2h06
-.. _66AK2H12: http://www.ti.com/product/66ak2h12
-.. _66AK2H14: http://www.ti.com/product/66ak2h14
-
-.. _K2K: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _TCI6638K2K: http://www.ti.com/product/tci6638k2k
-
-.. _RTOS-K2L: http://software-dl.ti.com/processor-sdk-rtos/esd/K2L/latest/index_FDS.html
-.. _K2L: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2L06: http://www.ti.com/product/66ak2l06
-
-.. _RTOS-OMAPL137: http://www.ti.com/tool/processor-sdk-omapl137
-.. _OMAP-L1x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/omap-l1x/overview.page
-.. _OMAP-L137: http://www.ti.com/product/OMAP-L137
-.. _C6743: http://www.ti.com/product/tms320c6743
-.. _C6745: http://www.ti.com/product/tms320c6745
-.. _C6747: http://www.ti.com/product/tms320c6747
-
-.. _RTOS-OMAPL138: http://www.ti.com/tool/processor-sdk-omapl138
-.. _OMAP-L1x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/omap-l1x/overview.page
-.. _OMAP-L138: http://www.ti.com/product/OMAP-L138
-.. _C6742: http://www.ti.com/product/tms320c6742
-.. _C6746: http://www.ti.com/product/tms320c6746
-.. _C6748: http://www.ti.com/product/tms320c6748
-
-Evaluation Modules
-------------------
-
-See :ref:`Processor SDK Supported Platforms <RTOS-SDK-Supported-Platforms>`
-page for a list of supported EVMs per platform and links to more
-information.
-
-Demonstrations
---------------
-
-See :ref:`Examples and Demonstrations <index-examples-demos>`
-page for a list of demonstrations per platform and EVM.
-
-Drivers
--------
-
-The following tables show RTOS driver availability per platform and EVM.
-A shaded box implies that the feature is not applicable for that
-platform/EVM.
-
-**Sitara devices**
-
-+------------------+--------------------------------+---------------+-----------+-----------+-----------+----------+
-|     Feature      |    Platform/SOC                |  AM335x EVM   |AM437x EVM | AM57x EVM | AM65x EVM |J721E EVM |
-+==================+=======+======+=====+=====+=====+===+===+===+===+===+===+===+=====+=====+=====+=====+==========+
-|                  |AM335x |AM437x|AM57x|AM65x|J721E|GP |ICE|SK |BBB|GP |IDK|SK | GP  | IDK | GP  | IDK |  GP      |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| CSL              |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| EMAC             |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| EDMA3            |   X   |   X  |  X  |     |     | X |   |   |   | X |   |   |  X  |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| GPIO             |   X   |   X  |  X  |  X  |  X  |   | X |   | X | X |   | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| GPMC             |   X   |   X  |     |     |     |   | X |   |   | X |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| I2C              |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS-I2C f/w    |   X   |   X  |  X  |     |     |   | X |   |   |   | X |   |     |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS-eSPI f/w   |   X   |   X  |     |     |     |   |   |   |   |   |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| ICSS-EMAC        |   X   |   X  |  X  |  X  |     |   | X |   |   |   | X |   |     |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| McASP            |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| McSPI            |   X   |   X  |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |   X |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| MMC-SD           |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PCIe             |       |      |  X  |  X  |     |   |   |   |   |   |   |   |     |  X  |  X  |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PM               |   X   |      |  X  |  X  |  X  | X |   |   |   |   |   |   |  X  |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS            |   X   |   X  |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| QSPI             |       |   X  |  X  |  X  |  X  |   |   |   |   |   | X | X |     |  X  |     |     |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| OSPI             |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| UART             |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB              |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |   X |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB Device Audio |   X   |      |     |     |     | X |   |   |   |   |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB Device Bulk  |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |   X |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| VPS              |       |      |  X  |     |     |   |   |   |   |   |   |   |  X  |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| UDMA             |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| SCICLIENT        |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| SA               |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| CAL              |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| DSS              |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| FVID2            |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-
-**DSP devices - K2x, C66x**
-
-+------------------+-------------------------------+-----------------------+-----------+
-|     Feature      |         Platform/SOC          |        K2 EVM         | C66x EVM  |
-+==================+=======+===+===+===+=====+=====+===+===+===+===+=======+=====+=====+
-|                  |K2H/K2K|K2E|K2L|K2G|C665x|C667x|K2H|K2E|K2L|K2G|K2G-ICE|C665x|C667x|
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| CSL              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| AIF2             |   X   |   |   |   |     |     | X |   |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| BCP              |   X   |   | X |   |     |     | X |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| CPPI             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| DFE              |       |   | X |   |     |     |   |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| EDMA3            |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| EMAC             |       |   |   | X |  X  |     |   |   |   | X |   X   |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| FFTC             |   X   |   | X |   |     |     | X |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| GPIO             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| HYPLNK           |   X   | X |   |   |  X  |  X  | X | X |   |   |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| ICSS-EMAC        |       |   |   | X |     |     |   |   |   |   |   X   |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| I2C              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IQN2             |       |   | X |   |     |     |   |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| McASP            |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| McBSP            |       |   |   | X |  X  |     |   |   |   | X |       |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MMAP             |   X   | X |   |   |     |     | X | X |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MMC-SD           |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| NWAL             |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PA               |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PCIe             |   X   | X | X | X |  X  |  X  | X | X | X | X |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| QMSS             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| RM               |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SA               |   X   | X | X | X |     |  X  | X | X | X | X |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SPI              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SRIO             |   X   |   |   |   |  X  |  X  | X |   |   |   |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| TCP3D            |   X   |   | X |   |  X  |     | X |   | X |   |       |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| TSIP             |       | X |   |   |     |  X  |   | X |   |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| UART             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB              |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB Device Audio |       |   |   |   |     |     |   |   |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB Device Bulk  |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-
-
-**DSP devices - OMAP-L13x, C674x**
-
-+----------------+-------------------+-------------+----------------+
-|    Feature     |   Platform/SOC    |OMAP-L137 EVM| OMAP-L138 EVM  |
-+================+=========+=========+=============+=======+========+
-|                |OMAP-L137|OMAP-L138| L137/6747 SK|LCDK138|LCDK6748|
-+----------------+---------+---------+-------------+-------+--------+
-|CSL             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|EDMA3           |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|EMAC            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|GPIO            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|I2C             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|McASP           |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|MMC-SD          |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|SPI             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|UART            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB Device Audio|    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB Device Bulk |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-
-**Unsupported Features**
-
-- In general driver support is available across all cores within an SOC
-  with following exceptions
-
-+----------------+-------------------+
-|    Feature     | Not supported     |
-+================+=========+=========+
-|                |SOC      |CPU/Core |
-+----------------+---------+---------+
-|McASP           |  AM57x  |    M4   |
-+----------------+---------+---------+
-|USB             |  AM57x  |    C66x |
-+----------------+---------+---------+
-|USB             |  AM57x  |    M4   |
-+----------------+---------+---------+
-|USB             |  K2G    |    C66x |
-+----------------+---------+---------+
-|McBSP           |  K2G    |    A15  |
-+----------------+---------+---------+
-|McBSP           |OMAP-L13x|    ARM9 |
-+----------------+---------+---------+
-|All Drivers     | K2E/L/K |    A15  |
-+----------------+---------+---------+
-
-Other Features
-----------------
-
-The following table shows other feature availability per platform and
-EVM:
-
-**Sitara devices**
-
-+----------------------------+--------------------------------+---------------+-----------+-----------+-----------+ -----------+
-|          Feature           |    Platform/SOC                |   AM335x EVM  |AM437x EVM | AM57x EVM | AM65x EVM |  J721E EVM |
-+============================+=======+======+=====+=====+=====+===+===+===+===+===+===+===+=====+=====+=====+=====+============+
-|                            |AM335x |AM437x|AM57x|AM65x|J721E|GP |ICE|SK |BBB|GP |IDK|SK | GP  | IDK | GP  | IDK |  GP        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Board Support              |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Boot (SBL)                 |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Diagnostics                |   X   |  X   |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| FATFS                      |   X   |  X   |  X  |  X  |  X  | X | X |   |   | X | X |   |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| NDK-NIMU(CPSW)             |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| NDK-NIMU(ICSS)             |   X   |  X   |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-|CC-LINK IE Field Basic(CPSW)|   X   |  X   |  X  |     |     | X | X | X | X | X | X | X |  X  |  X  |     |     |            |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-|CC-Link IE Field Basic(ICSS)|   X   |  X   |  X  |     |     |   | X |   |   |   | X |   |     |  X  |     |     |            |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-
-**DSP devices - K2x, C66x**
-
-+----------------------------+-------------------------------+-----------------------+-----------+
-|          Feature           |         Platform/SOC          |        K2 EVM         | C66x EVM  |
-+============================+=======+===+===+===+=====+=====+===+===+===+===+=======+=====+=====+
-|                            |K2H/K2K|K2E|K2L|K2G|C665x|C667x|K2H|K2E|K2L|K2G|K2G-ICE|C665x|C667x|
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Board Support              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Boot (IBL/SBL)             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Diagnostics                |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| FATFS                      |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Fault Management           |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IPC Transport (QMSS)       |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IPC Transport (SRIO)       |   X   |   |   |   |  X  |  X  | X |   |   |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MAD-UTIL                   |       |   |   |   |  X  |  X  |   |   |   |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Network (CPSW)             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Network (ICSS)             |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-|CC-Link IE Field Basic(ICSS)|       |   |   | X |     |     |   |   |   | X |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-|Platform Library (obsolete) |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PKTLIB                     |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| POST                       |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SERDES Diagnostics         |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Trace Framework            |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-
-
-**DSP devices - OMAP-L13x, C674x**
-
-+--------------+-------------------+-------------+----------------+
-|   Feature    |   Platform/SOC    |OMAP-L137 EVM| OMAP-L138 EVM  |
-+==============+=========+=========+=============+=======+========+
-|              |OMAP-L137|OMAP-L138| 137/6747 SK |LCDK138|LCDK6748|
-+--------------+---------+---------+-------------+-------+--------+
-|Board Support |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Boot (SBL)    |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Diagnostics   |    X    |         |      X      |       |        |
-+--------------+---------+---------+-------------+-------+--------+
-|FATFS         |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Network (CPSW)|    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-
-Installation and Usage
-========================
-
-The :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>` provides
-instructions on how to setup up your development environment, install
-the SDK and start your development.
-
-To uninstall the SDK, remove the individual component directories from
-the installed path. This is safe to do even in Windows since these
-components do not modify the Windows registry.
-
-|
-
-Technical Support and Product Updates
-=====================================
-
-For further information or to report any problems, contact:
--  `TI E2E Processor Support <https://e2e.ti.com/support/processors/>`__ for all supported platforms
-
-
-|
-
-Archived
-========
--  `Processor-SDK RTOS
-   6.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_01_00_08/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   6.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_00_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_03_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.2.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_02_00_10/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_01_00_11/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_15/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 AM65x EA Release <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_09/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   4.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/04_03_00_05/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
-
-**Note:** Release Notes prior to 4.3 are not archived. Please see the
-:ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` for information on
-migration from these releases.
-
diff --git a/source/devices/AM437X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst b/source/devices/AM437X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst
deleted file mode 100644
index 010962ca8..000000000
--- a/source/devices/AM437X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-.. _RTOS-SDK-Supported-Platforms:
-.. include:: /common/Release_Specific/_Processor_SDK_Supported_Platforms_and_Versions.rst
diff --git a/source/devices/AM437X/rtos/index.rst b/source/devices/AM437X/rtos/index.rst
deleted file mode 100644
index 0887c6cff..000000000
--- a/source/devices/AM437X/rtos/index.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-.. _rtos-index:
-
-.. include:: /rtos/Overview/_Processor_SDK_RTOS_Software_Developers_Guide.rst
-
-.. toctree::
-   :maxdepth: 5
-   :hidden:
-   :numbered:
-
-   /rtos/Overview
-   Release_Specific
-   /rtos/Board_EVM_Abstration
-   /rtos/Foundational_Components
-   /rtos/Device_Drivers
-   /rtos/PRU_ICSS
-   /rtos/Compilers
-   /rtos/Examples_and_Demonstrations
-   /rtos/How_to_Guides
-   /rtos/FAQ
-   /rtos/Documentation_Tarball
-
-|
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/devices/AM437X/rtos/version.txt b/source/devices/AM437X/rtos/version.txt
deleted file mode 100644
index 84e924eb7..000000000
--- a/source/devices/AM437X/rtos/version.txt
+++ /dev/null
@@ -1 +0,0 @@
-07_01_00
diff --git a/source/devices/AM57X/rtos/Release_Specific.rst b/source/devices/AM57X/rtos/Release_Specific.rst
deleted file mode 100644
index 92255b3ed..000000000
--- a/source/devices/AM57X/rtos/Release_Specific.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-##################
-Release Specific
-##################
-
-.. toctree::
-   :maxdepth: 5
-
-   Release_Specific_Release_Notes
-   Release_Specific_Supported_Platforms_and_Versions
-   Release_Specific_Migration_Guide
diff --git a/source/devices/AM57X/rtos/Release_Specific_Migration_Guide.rst b/source/devices/AM57X/rtos/Release_Specific_Migration_Guide.rst
deleted file mode 100644
index 37c61d1c3..000000000
--- a/source/devices/AM57X/rtos/Release_Specific_Migration_Guide.rst
+++ /dev/null
@@ -1,973 +0,0 @@
-.. _RTOS-SDK-Migration-Guide-label:
-
-****************
-Migration Guide
-****************
-
-Overview
-========
-
-This page covers migration information for applications built on top
-of the Processor SDK RTOS.
-
-Processor SDK 08.xx Releases
-============================
-
-Processor SDK 08.01
--------------------
-
-SDK Naming
-===========
-
-**Migration:**
-Some of the components in the SDK has undergone naming changes in this release for using
-more inclusive terminology. While there is no change in the top-level folder or module name for
-any of the SDK components, there are changes to API, data structure, example file/folder names
-in multiple components as per the industry standard guidelines for moving towards more
-inclusive terminology.
-
-This change will have impact on some of the APIs and data structures used by applications
-and needs change in application software to move to the latest SDK release.
-Please refer 'Additional Details' section below for the details of the naming changes which
-helps application software migration to this SDK release.
-
-**Impact Scope:** Applicable for the applications using APIs, data structure and macros with
-naming change listed in Additional Details section.
-
-**Additional Details**:
-Below table provides list of APIs, data structures and macros that are exposed to the applications
-and their names are changed in this release.
-
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|  Component | Impact                      |    Old Name                 |  New Name                           |
-+============+=============================+=============================+=====================================+
-|            | I2C_Transaction             |                             |                                     |
-|            | structure member            |  slaveAddress               |  targetAddress                      |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | I2C_Transaction             |                             |                                     |
-|            | structure member            |  masterMode                 |  controllerMode                     |
-+  I2C       +-----------------------------+-----------------------------+-------------------------------------+
-|            | I2C_HwAttrs                 |                             |                                     |
-|            | structure member            |  ownSlaveAddr               |  ownTargetAddr                      |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | MACRO                       |  I2C_SLAVE_XFER_MODE        |  I2C_TARGET_XFER_MODE               |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | MACRO                       |  I2C_SLAVE_RESTART_MODE     |  I2C_TARGET_RESTART_MODE            |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|  EMAC      | EMAC_PORT_CB_V1_tag         |                             |                                     |
-|            | structure member            |  master_core_flag           |  controller_core_flag               |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|  MCASP     | Mcasp_AudioDevData          |                             |                                     |
-|            | structure member            |  isMaster                   |  isHost                             |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|  PCIE      | pciePlconfAxiSlvErrRespReg  |                             |                                     |
-|            | structure member            |  slaveErrMap                |  peripheralErrMap                   |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|  PRUSS     | API                         |  prussAppSorteRestartMaster |  prussAppSorteRestartController     |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  SBL_SlaveCoreBoot          |  SBL_TargetCoreBoot                 |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | FILE                        |  sbl_slave_core_boot.c      |  sbl_target_core_boot.c             |
-+   SBL      +-----------------------------+-----------------------------+-------------------------------------+
-|            | FILE                        |  sbl_slave_core_boot.h      |  sbl_target_core_boot.h             |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | FILE                        |  sbl_slave_boot.c           |  sbl_target_boot.c                  |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  McSPIMasterModeEnable      |  McSPIControllerModeEnable          |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  McSPIMasterModeConfig      |  McSPIControllerModeConfig          |
-+  CSL       +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  McSPISetSlaveChipSel       |  McSPISetPeripheralChipSel          |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  McSPISlaveModeEnable       |  McSPIPeripheralModeEnable          |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterEnable            |  I2CControllerEnable                |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterDisable           |  I2CControllerDisable               |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterInitExpClk        |  I2CControllerInitExpClk            |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterTargetAddrSet     |  I2CControllerTargetAddrSet         |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterEnableFreeRun     |  I2CControllerEnableFreeRun         |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterIntClearEx        |  I2CControllerIntClearEx            |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterControl           |  I2CControllerControl               |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterStart             |  I2CControllerStart                 |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterBusBusy           |  I2CControllerBusBusy               |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterDataPut           |  I2CControllerDataPut               |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  I2CMasterIntRawStatusEx    |  I2CControllerIntRawStatusEx        |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | CSL_emifDdrPhyParam         |  ctrlSlaveRatio             |  ctrlPeripheralRatio                |
-|            | structure member            |                             |                                     |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  TimeSync_enableMaster      |  TimeSync_enableController          |
-+            +-----------------------------+-----------------------------+-------------------------------------+
-|            | API                         |  TimeSync_disableMaster     |  TimeSync_disableController         |
-+ TIME_SYNC  +-----------------------------+-----------------------------+-------------------------------------+
-|            | TimeSync_Config_t           |  masterParams               |  controllerParams                   |
-|            |                             +-----------------------------+-------------------------------------+
-|            | Structure                   |  isMaster                   |  isController                       |
-+------------+-----------------------------+-----------------------------+-------------------------------------+
-
-
-Processor SDK 06.xx Releases
-============================
-
-Processor SDK 06.03
--------------------
-
-Building PDK components from GIT repositories
-=============================================
-
-**Migration:** Change in git repository for PDK components.
-
-**Impact Scope:** Applicable for most drivers packaged in the PDK when used in development environment
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) had their own git respositories which could be cloned and used for development or picking up bugfixes which are not yet released through a processor sdk release.
-From this release onwards, most of the drivers in the PDK are moved to the new pdk.git repository(https://git.ti.com/cgit/processor-sdk/pdk) and its components (drivers) moved in to their respective locations inside the pdk_<soc>_<ver> of the Processor SDK installation.
-For example the i2c driver has been moved from https://git.ti.com/cgit/keystone-rtos/i2c-lld to https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/drv/i2c. Consequently, the latest updates on a PDK driver should be fetched from the new pdk.git repo (https://git.ti.com/cgit/processor-sdk/pdk) as the older repos are rendered obselete.
-
-Building of libraries of individual PDK components
-==================================================
-
-**Migration:** Building individual drivers' librabries/apps of PDK from PDK's top level makefile is not supported
-
-**Impact Scope:** Applicable for PDK top level makefile
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) could be built from
-the top level makefile (pdk_xx/packages/makefile) using commands like "make uart_lib/uart_apps". This is no longer supported.
-Instead, the libraries and applications could either be built using "make all" from the top level makefile or issuing "make libs/apps" from within the module's directory.
-
-
-Processor SDK 06.01
--------------------
-
-NIMU
-====
-
-**Migration:** Udma init sequence call has been moved from NIMU library to NIMU example for AM65xx
-
-**Impact Scope:** Applicable for all NIMU applications using NIMU tranport library for AM65xx
-
-**Additional Details**:
-Applications will need to implement the following function to provide UDMA drive handle which will be called by the NIMU driver at startup
-
- Udma_DrvHandle nimu_app_get_udma_handle(void)
-
-Processor SDK 06.00
--------------------
-
-PRUSS
-^^^^^
-**Migration:**
-Calls that passed ``PRUICCSS_INSTANCE_MAX`` as a parameter to PRUSS driver API
-calls will now pass ``PRUICCSS_INSTANCE_THREE`` instead.
-
-**Impact Scope:**
-Applicable for all AM65xx applications using PRUSS driver for ICSSG use case.
-
-**Additional Details:**
-The following new enumeration, ``PRUICCSS_INSTANCE_THREE``, for PRU-ICSS
-instance 3 has been added to ``PRUICSS_MaxInstances`` enumeration list as
-``PRUICCSS_INSTANCE_MAX`` is not longer valid when making PRUSS driver API
-calls.
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-MMU configuration is needed to enable NBO CFG registers access on A53 core.
-
-**Impact Scope:**
-Applicable for all AM65xx RTOS applications calling ``Board_init()`` with
-``BOARD_INIT_ICSS_ETH_PHY`` flag.
-
-**Additional Details:**
-Board library is setting ``NAVSS THREADMAP`` register to give higher priority
-for MSMC access from ICSSG which requires access to ``NBO CFG`` registers.
-
-
-Processor SDK 05.xx Releases
-============================
-
-Processor SDK 05.03
--------------------
-
-EMAC
-^^^^
-**Migration-1:**
-ICSS-G EMAC firmware binary directory location update for future extension.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Applications will need to update the include path to location of firmware header
-files for ICSSG use case:
-
-- **Prevous location:** ``ti/drv/emac/firmeare/icss_eth/src/dm``
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/bin``
-
-**Migration-2:**
-Release introduces support for additional firmware specific configuration
-files. Added for future extension to support multiple firmwares using same EMAC
-driver.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Firmware configuration has been moved to firmware specific configuration files,
-``emac_fw_config_dual_mac.h`` and ``emac_fw_config_dual_mac.c``. Previously the
-firmware configuration was specified in the test application. It is not expected
-that applicatons will need to modify these files as the are closely tied to the
-firmware.
-
-- **Previous location:** firmware specific configuration was specified in the
-  text application (``ti/drv/emac/test/EmacLoopbackTest/test_utils_k3.c``)
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/config/``
-
-Applications will need to update their makefiles to include c source file
-``emac_fw_config_dual_mac.c``.
-
-At time of ``emac_open()`` API call, applications need to udpate configuruation
-parameters to pass get firmware configuration pointer :
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V5 emac_cfg;
-   EMAC_socGetInitCfg(0, &emac_cfg);
-   emac_cfg.portCfg[port_num].getFwCfg = &emacGetDualMacFwConfig;
-   EMAC_socSetInitCfg(0, &emac_cfg);
-
-CSL
-^^^
-**Migration:**
-API changes on CSL-FL of AM65xx on ecc aggregator, vim, esm modules
-
-**Impact Scope**:
-Limited to the case if application is using the CSL-FL APIs
-
-**Additional Details**:
-The CSL-FL for ECC aggregator, ESM and VIM are modified to return API
-functionality success/failures and additional arguments are added as and when
-needed (especially during the cases where the return was the value instead of
-API success/failure). Applications that use these CSL-FL calls are impacted and
-are needed to align to new calling conventions. If applicable application
-modification required to align to updated APIs, refer doxygen API documentation
-for API details.
-
-
-DSP- TI CGT Compiler
-^^^^^^^^^^^^^^^^^^^^
-
-**Migration:**
-In DSP TI CGT compiler version 8.3.2 the rts library boot object file name is
-changed from ``boot.obj`` to ``boot.c.obj``.
-
-**Impact Scope:**
-Limited only to DSP applications that explicitly uses rts library object files
-in linker command file.
-
-**Additional Details:**
-The DSP application which is using linker command file of CSL module should
-change boot object name from boot.obj file to ``boot.c.obj``. If the user is
-using cpp version of boot object file then it should be mentioned as
-``boot.cpp.obj``. In general it can be also be used as ``boot.*.obj``. This can
-be referred from the following linker command file in the PDK package
-``<PDK>/packages/ti/csl/example/lnk_dsp.cmd``
-
-Processor SDK 05.02
--------------------
-
-SBL
-^^^
-**Migration:**
-Image integration and memory map changes.
-
-**Additional Details:**
-Release supports optimized boot times for booting MCU1_0 core from OSPI
-flash. To reduce the size of the SBL,  the system firmware image, which was
-earlier embedded in the SBL, is now a separate binary. The system firmware image
-can be found at ``<PDK>/packages/ti/drv/sciclient/soc/V0/sysfw.bin``
-
-For MMC/SD boot, if the steps followed in :ref:`Windows SD Card Creation Guide
-<windows-sd-card-creation-guide>` or :ref:`Linux SD Card
-Creation Guide <tools-create-sd-card-linux-label>` are
-used, no additional steps are need. If the SD card is being created manually,
-then the ``sysfw.bin`` file also needs to be copied into the root directory of
-the MMC SD card, along with ``tiboot3.bin`` and ``app``.
-
-For OSPI boot, the flash offsets have changed. ``sysfw.bin`` needs to be
-programmed into OSPI flash at offset ``0x40000`` (new for this release), along
-with ``sbl_ospi_img_mcu1_0_release.tiimage`` at offset ``0x0`` (no change from
-previous release) and the ``app`` at offset ``0xA0000`` (was ``0x80000``
-previous release).  For details please refer `Programming the OSPI flash
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Board_EVM_Abstration.html#uniflash>`__
-
-Applications that the SBL loads must co-exist with the SBL's memory usage.In the
-application's linker command file, care must be taken to not use the first 0x100
-bytes of MCU1_0's ATCM memory and SBL reserved memory from ``0x41C00100 to
-0x41C28000``. If the applications violate the SBL memory usage, then apps that
-were working with the last release might not work any more, as the memory
-constraints are tighter. For details, refer the `SBL Memory Utilization
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Foundational_Components.html#am655x-sbl-memory-usage>`__
-
-PDK
-^^^
-**Migration:**
-AM65xx PDK component dependency on sciclient module.
-
-**Impact Scope:**
-Applications will need to link to sciclient module library. No migration impact
-if application is already linking the library.
-
-**Additional Details**:
-All application using PDK components on AM65xx platform will need to link
-sciclient library  as components internally will be using sciclient API for PLL
-and interrupt configuration. In this release, requirement for application will
-be more mandated as more components are using common infrastructure.
-
-DMSC firmware should be loaded onto Cortex-M4 core using SBL or :ref:`CCS GEL script
-<advanced-am65x-debug-setup-with-dmsc-firmware-load>`
-before calling the Board Init API with 'BOARD_INIT_PLL' flag.
-
-Board
-^^^^^
-**Migration:**
-New APIs for EEPROM Board ID Information
-
-**Impact Scope:**
-Applications using Board ID info APIs on AM65xx platform. No migration impact
-for existing applications and boards using version 1 API.
-
-**Additional Details**:
-TI Board ID information format has been updated to new version on AM65xx. New
-board library APIs ``Board_getIDInfo_v2()`` and ``Board_writeIDInfo_v2()`` are
-added to support new Board ID information format. Old Board ID info APIs are
-still avaialble to retain the backward build compatibility but returns error
-when used on AM65xx platform.
-
-FATFS
-^^^^^
-**Migration:**
-FATFS module in this release includes multipartition support and capability of
-detecting single vs multiple partitions run time.
-
-**Impact Scope:**
-Limited to the case if user had used MS-DOS Floppy disk format for formatting
-the SD/eMMC memory. No impact if the SD/eMMC is formatted using the steps
-provided by :ref:`Windows SD Card Creation Guide
-<windows-sd-card-creation-guide>`/:ref:`Linux SD Card Creation
-Guide <tools-create-sd-card-linux-label>`.
-
-**Additional Details**:
-Partition entry information may be wrongly detected for the storage media
-formated to  MS-DOS Floppy disk format. FATFS APIs fail to access the disk in
-this case.
-
-**Workaround**:
-Format the storage media using the steps provided by :ref:`Windows SD Card Creation
-Guide <windows-sd-card-creation-guide>`/:ref:`Linux SD Card
-Creation Guide <tools-create-sd-card-linux-label>`
-in case this issue is observed.
-
-Processor SDK 05.01
--------------------
-
-Build
-^^^^^
-**Migration:**
-Applicable for applications migrating from SOCs supporting EDMA LLD to AM65x
-with updated DMA infrastructure. Additional UDMA driver support is available in
-package to support enhanced DMA infrastrcuture for AM65x Drivers for AM65x SOC
-is extended to support UDMA LLD abstracting changes needed by
-application. Limited change will be required for application using drivers
-included in Processor SDK.
-
-**Additional Details**:
-Modifications needed at application will be limited to initialization of UDMA
-driver using Udma_init() API in addition to linking  UDMA driver library. Driver
-Test code could be used as reference Additional migration details for all cases
-are covered in ``/ti/drv/udma/docs`` folder inside PDK package.
-
-DMA
-^^^
-**Migration:**
-For all drivers using DMA mode EDMA driver is updated to UDMA driver.
-
-**Additional Details:**
-Application will need to initialize UDMA driver and SCIClient interface using
-``Udma_init()`` and ``Sciclient_init()`` API. Test code could be used as
-reference.
-
-Networking
-^^^^^^^^^^
-**Migration:**
-Applicable for applications using NDK and Posix port of SysBIOS.
-
-**Additional Details:**
-Release introduces NS (Network Services Component) as independent portable
-networking API abstracting different network stacks. Detailed migration details
-is available at `NDK 2.x to 3.x Migration Guide <NDK_Migration_Guide_>`__
-
-Processor SDK 05.00
--------------------
-
-Build
-^^^^^
-**Migration:**
-``TOOLS_INSTALL_PATH`` macro value changed to ``SDK_INSTALL_PATH``. No migration
-impact if tools and SDK are installed in same location.
-
-**Additional Details:**
-``TOOLS_INSTALL_PATH`` macro value is set to ``SDK_INSTALL_PATH`` by
-default. For accessing the tools from a different path, modify
-``TOOLS_INSTALL_PATH`` in ``packages/ti/build/Rules.make`` file or can be
-overriden from the build console as shown below.
-
-Windows
-
-.. code:: console
-
-   set TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-Linux
-
-.. code:: console
-
-   TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-
-Build Setup
-^^^^^^^^^^^
-**Migration:**
-There is no migration need for components used within processor SDK. Application
-Software outside processor SDK may require a change if there is a dependency to
-internal Processor SDK environment variables. See more details below.
-
-**Additional Details:**
-Rules.make file is used instead of pdksetupenv to setup the build environment
-variables. Components inside processor SDK are updated to align with this
-change. Any applications making use of pdksetupenv from processor SDK to setup
-the build environment variables should include below line in the application
-makefile.
-
-.. code-block:: c
-
-  include $(RULES_MAKE)
-
-Processor SDK 04.xx Releases
-============================
-
-Processor SDK 04.03
--------------------
-
-OSAL
-^^^^
-**Migration:**
-No impact expected if Semaphore allocation and HwIP registration from OSAL is
-not invoked by application.
-
-**Additional Details:**
-OSAL module is fine tuned for optimized number of semaphores required internally
-within drivers. Module provides additional API to application for additional
-semaphore allocation if required.Application can configure for either default
-internal static allocation or it can select external memory block that can be
-provided to create these objects. Note that this decision to go with external
-memory block or internal memory block need to be done during init configuration
-of application (near to main) just after ``Board_init()`` is called. Below
-sample code sets SemaphoreP/HwiP to be used from external memory block:
-
-.. code-block:: c
-
-   /* Get the Hw Attrs */
-   osal_ret = Osal_getHwAttrs(&hwAttrs);
-   if (osal_ret != osal_OK)
-   {
-       return (false);
-   }
-
-   /* This API should set to use external memory block */
-   hwAttrs.extSemaphorePBlock.base = (uintptr_t) &semPMemBlock[0];
-   hwAttrs.extSemaphorePBlock.size = SEMP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.size       = HWIP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.base       = (uintptr_t) &hwiPMemBlock[0];
-   osal_ret = Osal_setHwAttrs(ctrlBitMap, &hwAttrs);
-
-
-Board
-^^^^^
-**Migration:**
-Section details applicable only to applications based on DRA7xx SoCs.
-
-**Additional Details**:
-DRA7xx board libraries have refactored pad configuration sequence by removing
-manual pinmux entries and replacing them with a full IODELAY reconfiguration
-procedure. This was done in order to simplify transition from a standalone
-application development in CCS to booting the whole device via SBL, ensuring
-that pad configuration is 100% consistent between the two application loading
-methods.
-
-The IODELAY and pin control data structures are maintained in each of evmDRA72x
-and evmDRA75x board library source directories. These structures are also
-included in the SBL compilation and used in the SBL's IODELAY
-reconfiguration. Therefore, changes can be made in one location but reused by
-both Board and SBL components just through recompilation.
-
-Note that DRA78x does not require IODELAY reconfiguration and pinmux setup is
-always contained entirely in the application. Hence, there are no corresponding
-changes to this library.
-
-All of this is done in a transparent manner, so there is **no API change** and
-will not affect existing applications. However, there are considerations with
-respect to memory placement and potential conflicts between the board library
-and SBL code. These restrictions have always existed but are now more clearly
-defined and documented. Please refer to :ref:`Board Support
-<board-board-support>` for more details.
-
-I2C
-^^^
-**Migration:**
-No migration required for existing user application.
-
-**Additional Details:**
-PRUICSS based I2C Firmware have been introduced in this release. This new
-features increases the number of I2C interface available in the SOC. I2C LLD now
-depends on PRUSS LLD for compilation of this new feature. All of this is done in
-a transparent manner, so there is **no API change** and will not affect existing
-applications. However, for using the I2C FW feature refer :ref:`I2C FW
-<PRU-ICSS-I2C-FIRMWARE-label>` for additional details.
-
-Processor SDK 04.02
--------------------
-
-GCC Toolchain Migration to 6-2017-q1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to TI-RTOS based application on ARM Cortex-A cores.
-
-**Additional Details:**
-Processor SDK RTOS components includes updates to be compatible with GCC tool
-chain. This includes updates to SysBIOS, compiler and linker options. Following
-migration changes required for applications:
-
-- Compiler options: Add nano libs to Include path
-
-  - Example:
-    ``gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/newlib-nano``
-
-- Linker Options: Replace fpu lib paths with hard lib and enable nano specs
-
-  - Example: ``"<SYS/BIOS Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu"``
-     with ``"<SYS/BIOS
-     Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard --specs=nano.specs”``
-
-**Additional References:**
-
-- PDK Project Creation Scipt:
-  ``<pdk_soc_x_x_x/packages/pdkProjectCreate.[bat/sh]>``
-
-**Note:** For baremetal applications, stack section needs to be aligned to 8
-bytes. Updated GCC toolchain is more stringent on memory alignment requirement.
-Misalignment can result in unexpected run time failures.
-
-EMAC Library
-^^^^^^^^^^^^
-**Migration:**
-Limited to C6657, OMAPL137/C6747 and OMAPL138/C6748 SoCs.
-
-**Additional Details:**
-Interrupt setup and ISR functions are implemented in the driver. Interrupt
-handling in applications need to be removed to use the latest driver
-version. Use ``EMAC_socGetInitCfg()`` and ``EMAC_socSetInitCfg()`` functions to
-change the default interrupt mapping in HW attributes if required.
-
-Example:
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V0             emac_hwattr;  /* Local instance for HW attributes */
-   EMAC_OPEN_CONFIG_INFO_T     open_cfg;
-
-   EMAC_socGetInitCfg(port_num, &emac_hwattr);  /* Get default SOC HW attributes */
-   emac_hwattr.txIntrNum = <Int Num>  /* Change default interrupt mapping Optional: if needed */
-   EMAC_socSetInitCfg(port_num, &emac_hwattr); /* Change the default HW attributes */
-   open_cfg.hwAttrs = &emac_hwattr;  /* Assign HW attributes to configuration parameters */
-   emac_open(port_num, &open_cfg);
-
-
-Processor SDK 04.01
--------------------
-
-Common CSL Library
-^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to Bare metal Application and Keystone SoCs such as K2HK/K2LE/K2G. No
-change required for other SoCs such as AM571x/AM572x/C6678/C6657.
-
-**Additional Details:**
-Default start address for the vectors modified to beginning of MSMCSRAM
-(``0x0C000000``) compared to previous release end of the MSMC. This matches to
-both secured and non secured devices Application is required to reserve
-(``0x0C000000 to 0x0C000040``) size 0x40 bytes.
-
-Bare metal Application needs to reserve this location for vectors when using CSL
-startup library. There is still option for overriding default configuration by
-defining ``vector_base`` to desired start address: Example: if the vector
-location desired is say ``0xC0E0000``, then add below line in the application's
-linker command file:
-
-.. code-block:: c
-
-   __vector_base__= 0xC0E0000;
-
-No change needed for application using default configuration matching CSL.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration required for applications using default icss_dualemac
-and icss_switch firmware.*
-
-The location of ``icss_emacFwConfig.c/.h`` has moved from
-``ti/drv/icss_emac/firmware/<SOC_TYPE>`` directory to
-``ti/drv/icss_emac/firmware/icss_dualemac/config/`` directory. If applications
-are compiled with ``icss_emacFwConfig.c``, please update your build/make
-infrastructure.
-
-Processor SDK 04.00
--------------------
-MCSDK 1.1 to Processor SDK Migration for OMAPL13x/C674x devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This release includes additional support for OMAPL13x/C674x
-architecture/SOCs. For more information on migrating aplications from
-MCSDK(OMAPL13x) to Processor SDK, see `this migration page
-<MCSDK_Migration_for_OMAPL13x_>`__.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Required. Application will need to link to firmware binaries.*
-
-ICSS EMAC driver component includes source code support for Dual-emac firmware
-with support for rebuilding. Firmware is no longer supported as header format
-*.h in order to align to PRUSS compiler.
-
-- In order to include new binary application will need to link the PRUSS
-  firmware binary as demonstrated through ``*project.txt``. **Note: firmware
-  binary to be linked will be dependent on the SOC as shown below**
-
-**Example:**
-*AM572x have support for both version so include both version of
-binaries and linker \*.cmd files.*
-
-.. code-block:: c
-
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU0.bin
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU1.bin
-
-- Default linker command file is available in PDK software which can be linked
-  by application based on cores where application is running. For A8, A9, A15
-  cores below linker command can be linked in makefile or CCS project. Refer the
-  ICSS-EMAC Unittest for additional details.
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_a8_a9_a15_<REVISION>.cmd
-
-- For c66 and m4 cores
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_c66_m4_<REVISION>.cmd
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact in case of applications using custom board
-library which is not following similar approach as default board library for
-Ethernet PHY configurations.*
-
-Updated Board library for OMAPL137 in this release includes additional Ethernet
-PHY initialization support for reference EVM during init and hence requiring
-dependency on I2C LLD. This is applicable to applications using default OMAPL137
-board library similar to other PDK/Processor SDK applications in the
-release. For all those cases linking to additional I2C LLD library will be
-required.
-
-Examples for including I2C LLD library for:
-
-- Baremetal Applications
-
-Include the I2C LLD library from below mentioned path in makefile or linker
-command file:
-
-- **ARM Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/arm9/release/ti.drv.i2c.ae9``
-- **DSP Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/c674/release/ti.drv.i2c.ae674``
-
-- SYS/BIOS RTOS Applications
-
-Include the I2C LLD library in SYS/BIOS config file using xdc load package
-module:
-
-.. code-block:: c
-
-   var devType = "omapl137"
-   var I2c     = xdc.loadPackage('ti.drv.i2c');
-   I2c.Settings.socType = devType;
-
-McASP Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact for applications initializing the structure using
-memset and default configuration: ``Mcasp_WordBitsSelect_LSB()``.*
-
-McASP driver includes additional configuration field in
-``Mcasp_ChanParams->wordBitsSelect`` to enable newly introduced mode
-Mcasp_WordBitsSelect_MSB. Configuration needs to be initialized by application.
-
-Processor SDK 03.xx Releases
-============================
-
-Processor SDK 03.03
--------------------
-
-Processor SDK 03.02
--------------------
-
-PDK I2C LLD
-^^^^^^^^^^^
-To support I2C slave mode, added ``I2C_transactionInit()`` API. Applications
-need to call ``I2C_transactionInit()`` API before calling ``I2C_transfer()``
-API.
-
-**Example:**
-
-.. code-block:: c
-
-   I2C_Transaction   transaction;
-   I2C_transactionInit(&transaction);
-   transaction.masterMode   = false;
-   transaction.writeCount = wrLen;
-   transaction.readCount  = rdLen;
-   transaction.timeout    = timeout;
-   I2C_transfer(i2c, &transaction);
-
-PDK MCASP LLD
-^^^^^^^^^^^^^
-The call back function's behavior has changed. The MCASP driver no longer
-modifies the ``cArg`` parameter of the registered call back function to indicate
-the transaction type(TX or RX). The cArg paramter will be unchanged and passed
-back to the application. Please refer to the examples, which have been updated
-to reflect this change.
-
-PDK MMCSD LLD
-^^^^^^^^^^^^^
-No update required for use of default SOC dependent library.This is applicable
-for applications which choose to include the ``soc/MMCSDDMA_soc.c``. The
-``soc/MMCSDDMA_soc.c`` file has now been removed as a part of combining the DMA
-and Non-DMA source code of the MMCSD library. Applications may include
-``soc/MMCSD_soc.c`` file instead.
-
-PDK USB LLD
-^^^^^^^^^^^
-- Cache is now supported. Buffers that are passed to low level USB bulk API's
-  need to be cache-size aligned. These include buffers passed to:
-  ``USBHMSCBlockWrite()``, ``USBHMSCBlockRead()``, ``USBHostRead()``,
-  ``USBHostWrite()``, or ``usbSetupEpReq()``, etc.
-
-- DMA is enabled by default on AM335x. Remove DMA_MODE flag in
-  ``build/makefile.mk`` to go back to FIFO mode.
-
-PDK ICSS EMAC LLD
-^^^^^^^^^^^^^^^^^
-Support has been added to all allow the icss-emac LLD to be configured with
-custom firmware memory map parameters which fall into the following 2
-categories:
-
-- *Static configuration*: Tied directly to the firmware. For example, location and
-  size of statistics, port status and conrol address offsets.
-
-- *Dynamic configuration*: Tuneable parameters based on application. For
-  example, sizes of TX/RX queues, port specific buffer/buffer descriptor
-  offsets.
-
-A complete list of these parameters can be found in
-``ti/drv/icss_emac/icss_emacDrv.h``. Refer to ``ICSS_EmacFwStaticMmap`` and
-``ICSS_EmacFwDynamicMmap`` structures.
-
-Firmare binaries which reside in ``ti/drv/icss_emac/firmware/<SOC>`` directory
-should be accompanied by a ``icss_emacFwConfig.c`` file. For existing firmware
-binaries in this release, there is an equivelent ``icss_emacFwConfig.c`` file
-already present. This file basically defines the 2 stuctures mentioned
-above. This file needs to be compiled in as part of the user application. User
-application can then use the following 2 newly introduced API's to "get" and
-"set" firmware memory map configuration parameters with the LLD and firmware.
-
-- ``icss_emacGetFwMMapInitConfig()``: Allows for retrieval of default firmware
-  memory map configuration. User application may call this if they wish to
-  update dynamic firmware memory map configuration paremeters. Static
-  configuration parameters MUST not be updated.
-
-- ``icss_emacSetFwMMapInitConfig()``: Allows for static and dynamic firmware
-  memory map configuration parameters to be configured into the the LLD and
-  firmware.
-
-Note that these API's need to be called prior to calling ``ICSS_EmacInit()``
-which is LLD's initialization function.
-
-Backward compatibility is also supported. If user application does not wish to
-update any configuration parameters, LLD will operate of default configuration
-parameters as specified in respective ``icss_emacFwConfig.c`` file which is
-being delivered as part of this release.
-
-TI-RTOS
-^^^^^^^
-The updated version of TI-RTOS (SYS/BIOS) includes a check to ensure the proper
-run-time library is linked. If you face a compilation issue, see `this note on
-RTOS FAQ <SYSBIOS_reentsupport_error_faq_>`__ for more information.
-
-Processor SDK 03.01
--------------------
-PDK CSL
-^^^^^^^
-- ``csl_a15init`` module is renamed to ``csl_init`` to support portability. The
-  impact of this change is limited to bare metal application using PDK makefile
-  infrastructure. As part of migration, the module name need to be updated.
-
-- ``csl_a15Aux.h`` is removed as it is duplicate of ``csl_a15.h``. The impact of
-  this change is limited to applications that include ``csl_a15Aux.h``. As part
-  of migration, the modification required is to include ``csl_a15.h`` instead.
-
-PDK SA LLD (K2x, C66x)
-^^^^^^^^^^^^^^^^^^^^^^
-Added a feature to select Air Cipher Engine over the default Encryption engine
-for algorithms such as AES_CTR part of ``Sa_DataModeConfigParams_t`` API. There
-is no migration impact if application is initializing the structure to zero
-using memset.
-
-Processor SDK 03.00
--------------------
-This release is a maintenance update with new features and bug fixes. The major
-number in the version changed to stay aligned with the Linux package that moved
-to 2016 LTS.
-
-Device Drivers
-^^^^^^^^^^^^^^
-- Locations of precompiled libraries have moved for the following PDK
-  components: ``CSL, PDK Examples, GPIO, GPMC, I2C, ICSS-EMAC, McASP, McSPI,
-  MMC-SD, PCIe, PRUSS, QSPI, UART, USB, VPS, PDK Utils, FATFS, BOARD, OSAL,
-  NIMU, NIMU_ICSS``. The overall change is to rename armv7 to a15/a8/a9 as
-  appropriate for the device. All cores have moved the libraries compiled with
-  optimization to ``release``, while a debug folder is available (but not
-  prebuilt) for libraries with ``-g``.
-
-  - No changes are needed for applications configured with a XDC/BIOS *.cfg with
-    dependancies specified through xdc.useModule or xdc.loadPackage because
-    updated library paths are autogenerated.
-
-  - For other applications which explicitly set libraries and/or library include
-    paths via ``-l, -I, or -L`` flags passed to the linker, the library paths
-    need to be updated. For example, for GPIO on A15, the path changes from
-    ``ti/drv/gpio/lib/am572x/armv7`` to ``ti/drv/gpio/lib/am572x/a15/release``.
-
-- The drivers GPIO, I2C, SPI and UART now use CSL-FL. Applications using these
-  drivers need to add include and library dependencies by adding xdc.useModule
-  for CSL-FL for XDC/BIOS based applications, or by adding ``-I/-l/-L`` paths to
-  the compilation/linker flags for the application. For XDC, here is a sample
-  code for adding CSL-FL:
-
-.. code-block:: javscript
-
-   /*use CSL package*/
-   var socType = "am571x";
-   var Csl     = xdc.loadPackage('ti.csl');
-
-   Csl.Settings.deviceType = socType;
-
-- The driver I2C has an API change for I2C_transfer, a new timeout field is
-  added to ``I2C_Transaction`` structure, and the return value type of this API
-  is changed from ``bool`` to ``int16_t``. In the test/example application,
-  timeout value need to be initialized before calling this API:
-
-**Example:**
-
-.. code-block:: c
-
-   int16_t status;
-
-   i2cTransaction.slaveAddress = I2C_EEPROM_ADDR;
-   i2cTransaction.writeBuf = (uint8_t *)&txBuf[0];
-   i2cTransaction.writeCount = I2C_EEPROM_TEST_LENGTH + I2C_EEPROM_ADDR_SIZE;
-   i2cTransaction.readBuf = NULL;
-   i2cTransaction.readCount = 0;
-   i2cTransaction.timeout   = I2C_TRANSACTION_TIMEOUT;
-
-   status = I2C_transfer(handle, &i2cTransaction);
-
-Processor SDK 02.xx Releases
-============================
-
-Processor SDK 02.00.02
-----------------------
-This release primarily adds support for K2G device. There is no migration impact
-to customers using devices supported in the previous release (AM3, AM4, AM5,
-C665x, C667x, K2E, K2H, K2K, K2L).
-
-Processor SDK 02.00.01
-----------------------
-This release primarily adds support for devices from the KeyStone architecture:
-C665x, C557x, K2E, K2H, K2K, and K2L. There is no migration impact to customers
-using devices supported in the previous release (AM3, AM4, AM5).
-
-For information on migrating from BIOS-MCSDK (C66x) or MCSDK (K2x) to Processor
-SDK, see `this migration page <MCSDK_Migration_Guide_>`__.
-
-Processor SDK 02.00.00
-----------------------
-**This is the initial Processor SDK RTOS release from Texas Instruments unifying
-platform software across multiple SOC's.**
-
-The strategy for forward/backwards compatibility is as follows:
-
-- `Device Drivers <Device_Drivers_>`__
-
-  - All new development efforts should use Device Drivers because:
-
-    - Device Drivers will maintain common APIs for all supported SoCs
-    - Customer applications can be easily ported to new and additional SoCs
-      hence providing scalable software platform
-    - All new features and development will occur only in the Device Drivers.
-
-- StarterWare is included for AM335x and AM437x for backwards compatibility with
-  Industrial SDK 02.01.00.01
-
-  - This will be maintenance only (bugs will be fixed, no new features)
-
-For applications that already depend on StarterWare from Industrial SDK
-02.01.00.01 on AM335x/AM437x, those APIs remain in Processor SDK in:
-
-- **AM335x SOC:** ``pdk_am335x_1_0_0/ti/starterware``
-- **AM437x SOC:** ``pdk_am437x_1_0_0/ti/starterware``
-
-.. _Linux_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#tools-create-sd-card-linux-label
-.. _Windows_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#windows-sd-card-creation-guide
-.. _NDK_Migration_Guide: http://software-dl.ti.com/targetcontent/ndk/3_40_01_01/exports/ndk_3_40_01_01/docs/ndk/NDK_2_to_3_Migration_Guide.html
-.. _Device_Drivers: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index.html#Device_Drivers
-.. _MCSDK_Migration_Guide: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk-to-processor-sdk-migration-guide
-.. _MCSDK_Migration_for_OMAPL13x: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk1-1-to-processor-sdk-linux-migration-guide-for-omapl13x-devices
-.. _SYSBIOS_reentsupport_error_faq: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/FAQ.html#Why_do_I_get_a_.22undefined_reference_to_.60ti_sysbios_rts_gnu_ReentSupport_checkIfCorrectLibrary.27.22_error_when_compiling_my_application.3F
diff --git a/source/devices/AM57X/rtos/Release_Specific_Release_Notes.rst b/source/devices/AM57X/rtos/Release_Specific_Release_Notes.rst
deleted file mode 100644
index 061980af0..000000000
--- a/source/devices/AM57X/rtos/Release_Specific_Release_Notes.rst
+++ /dev/null
@@ -1,408 +0,0 @@
-************************************
-Release Notes
-************************************
-
-Overview
-==========
-
-The **Processor Software Development Kit (Processor-SDK)** provides the
-core foundation and building blocks that facilitate application software
-development on TI's embedded processors. This *Release Notes* focuses on
-the Real-time operating system (RTOS).
-
-|
-
-Licensing
-===========
-
-Please refer to the software manifest, which outlines the licensing
-status for all packages included in this release. The manifest can be
-found on the SDK download page or in the installed directory as
-indicated below.
-
-|
-
-Documentation
-===============
-
--  :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`:
-   Provides information on getting the software and running basic
-   examples/demonstrations bundled in the SDK.
--  :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` Provides
-   migration information for applications built on top of the Processor
-   SDK for RTOS.
--  :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>`
-   Provides information on features, functions, delivery package and,
-   compile tools for the Processor SDK RTOS release. This also provides
-   detailed information regarding software elements and software
-   infrastructure to allow developers to start creating applications.
--  **Software Manifest**: Provides license information on software
-   included in the SDK release. This document is in the release at
-   ``/processor_sdk_rtos_<SOC>_<version>/docs`` and available to view
-   from the software download page.
--  **EVM Quick Start Guide**: Provides information on hardware setup and
-   running the demonstration application that is loaded on flash. This
-   document is provided as part of the EVM kit.
-
-|
-
-Processor SDK v08.01.00
-========================
-
-Released March 2022
-
-.. note::
-   | Limited testing is done on this release based on the components changed. Full testing of the SDK is not done.
-
-.. rubric::  What's New
-   :name: whats-new
-
-.. rubric::  New Features
-   :name: new-features
-
-- SDK
-   - Naming change for APIs, Macros and Data structures in some of the components. Please refer :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` for more details.
-- Board Diagnostics
-   - 4GB DDR support in memory diagnostic test
-- USB driver
-   - Added USB long run regression test
-- PRU
-   - Upgraded toolchain version to v2.3.3
-
-.. rubric::  Other Updates
-
-- Features/Components Removed
-   - RS485 Diagnostic test support is removed
-   - Big data IPC and Jailhouse demos
-- Bug Fixes
-   - Bug fixes for USB driver, SPI driver and diagnostic examples. Please refer `Fixed Issues <Release_Specific_Release_Notes.html#fixed-issues>`__ section for more details
-
-.. _release-notes-component-version:
-
-.. rubric::  Component Version
-   :name: component-version
-
-The following software components and host tools are bundled with the
-SDK installer. See the :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>` for
-more information on each item.
-
-.. note::
-   | This release has been tested with the following component and tool versions. It is recommended to use the versions listed here to avoid compatibility issues.
-
-+-------------+------------+
-|  Component  |   Version  |
-+=============+============+
-|  CG_XML     | 2.61.0     |
-+-------------+------------+
-|  CTOOLSLIB  | 2.2.0.0    |
-+-------------+------------+
-|  DSPLIB     | 3.4.0.4    |
-+-------------+------------+
-|  EDMA3 LLD  | 2.12.5.30  |
-+-------------+------------+
-|  FC         | 3.40.2.7   |
-+-------------+------------+
-|  IMGLIB     | 3.1.1.0    |
-+-------------+------------+
-|  IPC        | 3.50.4     |
-+-------------+------------+
-|  MATHLIB    | 3.1.2.4    |
-+-------------+------------+
-|  NDK        | 3.61.1     |
-+-------------+------------+
-|  NS         | 2.60.1     |
-+-------------+------------+
-|  OPENCL     | 1.2.0.2    |
-+-------------+------------+
-|  OPENMP     | 2.6.3.0    |
-+-------------+------------+
-|  PDK        | 1.0.19     |
-+-------------+------------+
-|  SYS/BIOS   | 6.76.3.1   |
-+-------------+------------+
-|  UIA        | 2.30.1.2   |
-+-------------+------------+
-|  XDAIS      | 7.24.0.4   |
-+-------------+------------+
-|  XDCTOOLS   | 3.55.02    |
-+-------------+------------+
-
-
-The following compilers are bundled with the SDK installer:
-
-+----------------+---------+
-|    Compiler    | Version |
-+================+=========+
-|GNU ARM Embedded|7-2018-q2|
-+----------------+---------+
-|TI ARM CGT      | 18.12.5 |
-+----------------+---------+
-|TI C6000 CGT    | 8.3.2   |
-+----------------+---------+
-|TI PRU CGT      | 2.3.3   |
-+----------------+---------+
-
-The SDK uses Code Composer Studio (CCS) as the integrated development
-environment (IDE) for all devices and EVMs:
-
-+-----------+----------+
-| Component | Version  |
-+===========+==========+
-|   CCS     | 9.3.0    |
-+-----------+----------+
-|   EMU Pack|Sitara    |
-|           |Device    |
-|           |1.4.5     |
-+-----------+----------+
-|    TI     |8.3.0.0   |
-| Emulators |          |
-+-----------+----------+
-
-If you need to install CCS, see the `CCS installation section <index_overview.html#code-composer-studio>`__
-in the *Getting Started Guide* for options to select for Processor-SDK.
-
-
-
-Fixed Issues
-==============
-
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | ID                                                             | Head Line                                                                                                             | Module            | Affected Versions    | Affected Platforms                                |
-    +================================================================+=======================================================================================================================+===================+======================+===================================================+
-    | PDK-9869                                                       | McSPI controller peripheral example failures with some HW setups                                                      | McSPI             | 6.03.02              | am571x-idk, am572x-idk, am574x-idk                |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10870                                                      | MCSPI controller peripheral example does not transfer more than 32bytes                                               | McSPI             | 6.03.02              | am571x-idk, am572x-idk, am574x-idk                |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10276                                                      | False test fail condition reported by diagnostic test framework                                                       | Diagnostics       | 6.03.02              | am571x-idk, am572x-idk, am574x-idk                |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10285                                                      | ICSS EMAC diagnostic test hang after link detection                                                                   | Diagnostics       | 6.03.02              | am574x-idk                                        |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10282                                                      | CSL timer example hang on DSP core while configuring timer instance 32                                                | CSL examples      | 6.03.02              | am571x-idk, am572x-evm, am572x-idk, am574x-idk    |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10302                                                      | Prebuilt SD images are not included in AM57x processor SDK demos package                                              | Demos             | 6.03.02              | am572x-evm, am571x-idk, am572x-idk, am574x-idk    |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10313                                                      | System fails to recover using clearFeature when USB bulk application is made to sleep in different sequences          | USB               | 6.03.02              | am571x-idk, am572x-idk, am574x-idk                |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-11043                                                      | ICSS EMAC Example in Poll Mode fails for incorrect overflow count                                                     | ICSS EMAC         | 6.03.02              | am574x-idk, am572x-idk                            |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10576                                                      | UART print hangs on A15_1 core after BIOS_start                                                                       | Demos             | 6.03.02              | am571x-idk, am572x-evm, am572x-idk, am574x-idk    |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10408                                                      | Audio EQ McASP example is not working when equalization is enabled                                                    | McASP             | 6.03.02              | am572x-evm                                        |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10406                                                      | QSPI flash block erase & DMA mode write issues                                                                        | QSPI              | 6.03.02              | am572x-idk                                        |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-11121                                                      | Fix for USB bulk write function infinite loop                                                                         | USB               | 6.03.02              | am571x-idk, am572x-idk, am574x-idk                |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10525                                                      | PULLUP misspelled as PILLUP (TYPO ERROR)                                                                              | SPI, Board        | 6.03.02              | am571x-idk, am572x-evm, am572x-idk, am574x-idk    |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10521                                                      | RS485 support is wrongly documented for AM57x platform                                                                | Diagnostics       | 6.03.02              | am571x-idk, am572x-idk, am574x-idk                |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10398                                                      | Documentation improvements                                                                                            | Documentation     | 6.03.02              | am571x-idk, am572x-evm, am572x-idk, am574x-idk    |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-    | PDK-10328                                                      | Build warnings from hexpru tool while generating PRU firmware loader files                                            | ICSS EMAC         | 8.01.00              |  am572x-idk, am574x-idk am571x-idk                |
-    +----------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-------------------+----------------------+---------------------------------------------------+
-
-Known Issues
-==============
-
-This section contains the list of known issues at the time of making the
-release and any known workaround.
-
-+----------------------------------------------------------------+---------------------------------------------------------------------------------------------------+-------------------+-----------------------+------------------------------------------------------+----------------------------------------------------------------+-------------------------------------------------------+
-| ID                                                             | Head Line                                                                                         | Module            | Reported in Release   | Affected Platforms                                   | Impact                                                         | Workaround in this release                            |
-+================================================================+===================================================================================================+===================+=======================+======================================================+================================================================+=======================================================+
-| PDK-11137                                                      | Queue overflow count is not returning proper value in poll mode                                   | ICSS EMAC         | 8.01.00               |  am572x-idk, am574x-idk                              | Applications will not be able to determine the overflow count  | Use the error count to track over all errors          |
-+----------------------------------------------------------------+---------------------------------------------------------------------------------------------------+-------------------+-----------------------+------------------------------------------------------+----------------------------------------------------------------+-------------------------------------------------------+
-
-.. _RN-Supported-Platforms-label:
-
-Supported Platforms
-=====================
-
-Devices
----------
-
-The following table lists all supported devices by the release installer.
-
-+----------------+------------+-------------------------------------------------------------------------------+
-|   Installer    |Platform/SOC|                                 Supported Devices                             |
-+================+======+=====+===============================================================================+
-|`RTOS-AM57X`_   |`AM57x`_    |`AM5706`_, `AM5708`_, `AM5716`_, `AM5718`_, `AM5726`_, `AM5728`_,              |
-|                |            |`AM5746`_, `AM5748`_                                                           |
-+----------------+------------+-------------------------------------------------------------------------------+
-
-
-.. _RTOS-AM57X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/latest/index_FDS.html
-.. _AM57x: http://www.ti.com/am57x
-.. _AM5706: http://www.ti.com/product/am5706
-.. _AM5708: http://www.ti.com/product/am5708
-.. _AM5716: http://www.ti.com/product/am5716
-.. _AM5718: http://www.ti.com/product/am5718
-.. _AM5726: http://www.ti.com/product/am5726
-.. _AM5728: http://www.ti.com/product/am5728
-.. _AM5746: http://www.ti.com/product/am5746
-.. _AM5748: http://www.ti.com/product/am5748
-
-
-Evaluation Modules
---------------------
-
-See :ref:`Processor SDK Supported Platforms <RTOS-SDK-Supported-Platforms>`
-page for a list of supported EVMs per platform and links to more
-information.
-
-Demonstrations
-----------------
-
-See `Examples and Demonstrations <Examples_and_Demonstrations.html>`__
-page for a list of demonstrations per platform and EVM.
-
-Drivers
----------
-
-The following tables show RTOS driver availability per platform and EVM.
-A shaded box implies that the feature is not applicable for that
-platform/EVM.
-
-**Sitara devices**
-
-+------------------+-----+-----------+
-|     Feature      | SoC | AM57x EVM |
-+==================+=====+=====+=====+
-|                  |AM57x| GP  | IDK |
-+------------------+-----+-----+-----+
-| CSL              |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| EMAC             |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| EDMA3            |  X  |  X  |     |
-+------------------+-----+-----+-----+
-| GPIO             |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| I2C              |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| PRUSS-I2C f/w    |  X  |     |  X  |
-+------------------+-----+-----+-----+
-| ICSS-EMAC        |  X  |     |  X  |
-+------------------+-----+-----+-----+
-| McASP            |  X  |  X  |     |
-+------------------+-----+-----+-----+
-| McSPI            |  X  |     |  X  |
-+------------------+-----+-----+-----+
-| MMC-SD           |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| PCIe             |  X  |     |  X  |
-+------------------+-----+-----+-----+
-| PM               |  X  |  X  |     |
-+------------------+-----+-----+-----+
-| PRUSS            |  X  |     |  X  |
-+------------------+-----+-----+-----+
-| QSPI             |  X  |     |  X  |
-+------------------+-----+-----+-----+
-| UART             |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| USB              |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| USB Device Bulk  |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-| VPS              |  X  |  X  |  X  |
-+------------------+-----+-----+-----+
-
-**Unsupported Features**
-
-- In general driver support is available across all cores within an SOC
-  with following exceptions
-
-+----------------+-------------------+
-|    Feature     | Not supported     |
-+================+=========+=========+
-|                |SOC      |CPU/Core |
-+----------------+---------+---------+
-|McASP           |  AM57x  |    M4   |
-+----------------+---------+---------+
-|USB             |  AM57x  |    C66x |
-+----------------+---------+---------+
-|USB             |  AM57x  |    M4   |
-+----------------+---------+---------+
-
-Other Features
-----------------
-
-The following table shows other feature availability per platform and
-EVM:
-
-**Sitara devices**
-
-+----------------------------+-----+-----------+
-|          Feature           | SoC | AM57x EVM |
-+============================+=====+=====+=====+
-|                            |AM57x| GP  | IDK |
-+----------------------------+-----+-----+-----+
-| Board Support              |  X  |  X  |  X  |
-+----------------------------+-----+-----+-----+
-| Boot (SBL)                 |  X  |  X  |  X  |
-+----------------------------+-----+-----+-----+
-| Diagnostics                |  X  |  X  |  X  |
-+----------------------------+-----+-----+-----+
-| FATFS                      |  X  |  X  |  X  |
-+----------------------------+-----+-----+-----+
-| NDK-NIMU(CPSW)             |  X  |  X  |  X  |
-+----------------------------+-----+-----+-----+
-| NDK-NIMU(ICSS)             |  X  |     |  X  |
-+----------------------------+-----+-----+-----+
-|CC-LINK IE Field Basic(CPSW)|  X  |  X  |  X  |
-+----------------------------+-----+-----+-----+
-|CC-Link IE Field Basic(ICSS)|  X  |     |  X  |
-+----------------------------+-----+-----+-----+
-
-Installation and Usage
-========================
-
-The :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>` provides
-instructions on how to setup up your development environment, install
-the SDK and start your development.
-
-To uninstall the SDK, remove the individual component directories from
-the installed path. This is safe to do even in Windows since these
-components do not modify the Windows registry.
-
-|
-
-Technical Support and Product Updates
-=======================================
-
-For further information or to report any problems, contact:
--  `TI E2E Processor Support <https://e2e.ti.com/support/processors/>`__ for all supported platforms
-
-
-|
-
-Archived
-==========
--  `Processor-SDK RTOS
-   6.3.2 <https://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/06_03_02_08/exports/docs/devices/AM57X/rtos/Release_Specific_Release_Notes.html#release-notes>`__
--  `Processor-SDK RTOS
-   6.3.0 <https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   6.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_01_00_08/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   6.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_00_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_03_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.2.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_02_00_10/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_01_00_11/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_15/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 AM65x EA Release <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_09/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   4.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/04_03_00_05/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
-
-**Note:** Release Notes prior to 4.3 are not archived. Please see the
-:ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` for information on
-migration from these releases.
-
-|
-
diff --git a/source/devices/AM57X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst b/source/devices/AM57X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst
deleted file mode 100644
index 010962ca8..000000000
--- a/source/devices/AM57X/rtos/Release_Specific_Supported_Platforms_and_Versions.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-.. _RTOS-SDK-Supported-Platforms:
-.. include:: /common/Release_Specific/_Processor_SDK_Supported_Platforms_and_Versions.rst
diff --git a/source/devices/AM57X/rtos/index.rst b/source/devices/AM57X/rtos/index.rst
deleted file mode 100644
index 0cf84cf54..000000000
--- a/source/devices/AM57X/rtos/index.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-.. _rtos-index:
-
-.. include:: /rtos/Overview/_Processor_SDK_RTOS_Software_Developers_Guide.rst
-
-.. toctree::
-   :maxdepth: 5
-   :hidden:
-   :numbered:
-
-   /rtos/Overview
-   Release_Specific
-   /rtos/Board_EVM_Abstration
-   /rtos/Foundational_Components
-   /rtos/DSP_Software
-   /rtos/Device_Drivers
-   /rtos/PRU_ICSS
-   /rtos/Compilers
-   /rtos/Examples_and_Demonstrations
-   /rtos/How_to_Guides
-   /rtos/FAQ
-   /rtos/Documentation_Tarball
-
-|
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/devices/AM57X/rtos/version.txt b/source/devices/AM57X/rtos/version.txt
deleted file mode 100644
index 4346036d3..000000000
--- a/source/devices/AM57X/rtos/version.txt
+++ /dev/null
@@ -1 +0,0 @@
-08_01_00
diff --git a/source/devices/GEN/rtos/version.txt b/source/devices/GEN/rtos/version.txt
deleted file mode 100644
index 414594a5a..000000000
--- a/source/devices/GEN/rtos/version.txt
+++ /dev/null
@@ -1 +0,0 @@
-10_01
diff --git a/source/files/Guide_Keystone_II_IPC_examples_.zip b/source/files/Guide_Keystone_II_IPC_examples_.zip
deleted file mode 100644
index 3bf5755c3..000000000
Binary files a/source/files/Guide_Keystone_II_IPC_examples_.zip and /dev/null differ
diff --git a/source/images/1.7.6_Image.png b/source/images/1.7.6_Image.png
deleted file mode 100644
index d4331b819..000000000
Binary files a/source/images/1.7.6_Image.png and /dev/null differ
diff --git a/source/images/1SER_MULTISER_1SLOT_SER_INTERLEAVED_2.PNG b/source/images/1SER_MULTISER_1SLOT_SER_INTERLEAVED_2.PNG
deleted file mode 100644
index 9cefa8772..000000000
Binary files a/source/images/1SER_MULTISER_1SLOT_SER_INTERLEAVED_2.PNG and /dev/null differ
diff --git a/source/images/1SER_MULTISER_1SLOT_SER_NON_INTERLEAVED.PNG b/source/images/1SER_MULTISER_1SLOT_SER_NON_INTERLEAVED.PNG
deleted file mode 100644
index a164a4503..000000000
Binary files a/source/images/1SER_MULTISER_1SLOT_SER_NON_INTERLEAVED.PNG and /dev/null differ
diff --git a/source/images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_1_UPDATED.PNG b/source/images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_1_UPDATED.PNG
deleted file mode 100644
index 8613eb222..000000000
Binary files a/source/images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_1_UPDATED.PNG and /dev/null differ
diff --git a/source/images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_2.PNG b/source/images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_2.PNG
deleted file mode 100644
index e13a0357a..000000000
Binary files a/source/images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_2.PNG and /dev/null differ
diff --git a/source/images/1SER_MULTISLOT_INTERLEAVED.PNG b/source/images/1SER_MULTISLOT_INTERLEAVED.PNG
deleted file mode 100644
index 0c688b049..000000000
Binary files a/source/images/1SER_MULTISLOT_INTERLEAVED.PNG and /dev/null differ
diff --git a/source/images/1SER_MULTISLOT_NON_INTERLEAVED.PNG b/source/images/1SER_MULTISLOT_NON_INTERLEAVED.PNG
deleted file mode 100644
index 871c1dbad..000000000
Binary files a/source/images/1SER_MULTISLOT_NON_INTERLEAVED.PNG and /dev/null differ
diff --git a/source/images/1SLOT_1SER.PNG b/source/images/1SLOT_1SER.PNG
deleted file mode 100644
index ae6ca8aae..000000000
Binary files a/source/images/1SLOT_1SER.PNG and /dev/null differ
diff --git a/source/images/488px-Gbr888.png b/source/images/488px-Gbr888.png
deleted file mode 100644
index 0e0a5ec45..000000000
Binary files a/source/images/488px-Gbr888.png and /dev/null differ
diff --git a/source/images/488px-Yuyv422.png b/source/images/488px-Yuyv422.png
deleted file mode 100644
index 16f6fc75f..000000000
Binary files a/source/images/488px-Yuyv422.png and /dev/null differ
diff --git a/source/images/560pcierror.jpg b/source/images/560pcierror.jpg
deleted file mode 100644
index 8b869e58f..000000000
Binary files a/source/images/560pcierror.jpg and /dev/null differ
diff --git a/source/images/AM4-GP-test-connection.png b/source/images/AM4-GP-test-connection.png
deleted file mode 100644
index b153648d0..000000000
Binary files a/source/images/AM4-GP-test-connection.png and /dev/null differ
diff --git a/source/images/AM437x-SD-Card-Example.png b/source/images/AM437x-SD-Card-Example.png
deleted file mode 100644
index 92bc1e62e..000000000
Binary files a/source/images/AM437x-SD-Card-Example.png and /dev/null differ
diff --git a/source/images/AM5706_Speed_Grades.png b/source/images/AM5706_Speed_Grades.png
deleted file mode 100644
index 5c1846313..000000000
Binary files a/source/images/AM5706_Speed_Grades.png and /dev/null differ
diff --git a/source/images/AM5708_EVM_target_configurations.png b/source/images/AM5708_EVM_target_configurations.png
deleted file mode 100644
index f42b9d33a..000000000
Binary files a/source/images/AM5708_EVM_target_configurations.png and /dev/null differ
diff --git a/source/images/AM572x_AM571X_AM570x_Comparison.png b/source/images/AM572x_AM571X_AM570x_Comparison.png
deleted file mode 100644
index 654ad1558..000000000
Binary files a/source/images/AM572x_AM571X_AM570x_Comparison.png and /dev/null differ
diff --git a/source/images/AM57x-SD-Card-Example.png b/source/images/AM57x-SD-Card-Example.png
deleted file mode 100644
index b7bb7bb3c..000000000
Binary files a/source/images/AM57x-SD-Card-Example.png and /dev/null differ
diff --git a/source/images/AM57xx_OPP.png b/source/images/AM57xx_OPP.png
deleted file mode 100644
index d40ba0320..000000000
Binary files a/source/images/AM57xx_OPP.png and /dev/null differ
diff --git a/source/images/AM65x_CCS_Hello_World.PNG b/source/images/AM65x_CCS_Hello_World.PNG
deleted file mode 100644
index 7e2dddfac..000000000
Binary files a/source/images/AM65x_CCS_Hello_World.PNG and /dev/null differ
diff --git a/source/images/AM65x_CCS_Hello_World_R5.PNG b/source/images/AM65x_CCS_Hello_World_R5.PNG
deleted file mode 100644
index 3a4f9d58b..000000000
Binary files a/source/images/AM65x_CCS_Hello_World_R5.PNG and /dev/null differ
diff --git a/source/images/AM65x_Create_CCS_Project.png b/source/images/AM65x_Create_CCS_Project.png
deleted file mode 100644
index 5ee66ccd7..000000000
Binary files a/source/images/AM65x_Create_CCS_Project.png and /dev/null differ
diff --git a/source/images/AM65x_Create_CCS_Project_R5.png b/source/images/AM65x_Create_CCS_Project_R5.png
deleted file mode 100644
index 3e8ee708e..000000000
Binary files a/source/images/AM65x_Create_CCS_Project_R5.png and /dev/null differ
diff --git a/source/images/Advanced_settings_GEL_setup.png b/source/images/Advanced_settings_GEL_setup.png
deleted file mode 100644
index b303c8815..000000000
Binary files a/source/images/Advanced_settings_GEL_setup.png and /dev/null differ
diff --git a/source/images/Alert_Me.png b/source/images/Alert_Me.png
deleted file mode 100644
index 8f7ec3994..000000000
Binary files a/source/images/Alert_Me.png and /dev/null differ
diff --git a/source/images/Am335x_usb_ac_bd.jpg b/source/images/Am335x_usb_ac_bd.jpg
deleted file mode 100644
index e1f0e3cd4..000000000
Binary files a/source/images/Am335x_usb_ac_bd.jpg and /dev/null differ
diff --git a/source/images/Am335x_usb_ac_setup.jpg b/source/images/Am335x_usb_ac_setup.jpg
deleted file mode 100644
index debdb0f81..000000000
Binary files a/source/images/Am335x_usb_ac_setup.jpg and /dev/null differ
diff --git a/source/images/Am572x_cio.jpg b/source/images/Am572x_cio.jpg
deleted file mode 100644
index 0aadf972c..000000000
Binary files a/source/images/Am572x_cio.jpg and /dev/null differ
diff --git a/source/images/Am572x_connect_a15.jpg b/source/images/Am572x_connect_a15.jpg
deleted file mode 100644
index 67b1fea74..000000000
Binary files a/source/images/Am572x_connect_a15.jpg and /dev/null differ
diff --git a/source/images/Am572x_connect_dsp1.jpg b/source/images/Am572x_connect_dsp1.jpg
deleted file mode 100644
index c07a31c05..000000000
Binary files a/source/images/Am572x_connect_dsp1.jpg and /dev/null differ
diff --git a/source/images/Am572x_connect_dsp2.jpg b/source/images/Am572x_connect_dsp2.jpg
deleted file mode 100644
index b21e0e5af..000000000
Binary files a/source/images/Am572x_connect_dsp2.jpg and /dev/null differ
diff --git a/source/images/Am572x_load_dsp1.jpg b/source/images/Am572x_load_dsp1.jpg
deleted file mode 100644
index 8da59b86e..000000000
Binary files a/source/images/Am572x_load_dsp1.jpg and /dev/null differ
diff --git a/source/images/Am572x_load_dsp2.jpg b/source/images/Am572x_load_dsp2.jpg
deleted file mode 100644
index 412677477..000000000
Binary files a/source/images/Am572x_load_dsp2.jpg and /dev/null differ
diff --git a/source/images/Am572x_load_host.jpg b/source/images/Am572x_load_host.jpg
deleted file mode 100644
index f2ec12851..000000000
Binary files a/source/images/Am572x_load_host.jpg and /dev/null differ
diff --git a/source/images/Am572x_web_1.jpg b/source/images/Am572x_web_1.jpg
deleted file mode 100644
index e4b731133..000000000
Binary files a/source/images/Am572x_web_1.jpg and /dev/null differ
diff --git a/source/images/Am572x_web_2.jpg b/source/images/Am572x_web_2.jpg
deleted file mode 100644
index 711176b52..000000000
Binary files a/source/images/Am572x_web_2.jpg and /dev/null differ
diff --git a/source/images/Amic110_ice_spi_boot_diag1.jpg b/source/images/Amic110_ice_spi_boot_diag1.jpg
deleted file mode 100644
index b6e995354..000000000
Binary files a/source/images/Amic110_ice_spi_boot_diag1.jpg and /dev/null differ
diff --git a/source/images/Amic110_ice_spi_boot_diag2.jpg b/source/images/Amic110_ice_spi_boot_diag2.jpg
deleted file mode 100644
index a2dff86c1..000000000
Binary files a/source/images/Amic110_ice_spi_boot_diag2.jpg and /dev/null differ
diff --git a/source/images/Amic110_ice_spi_boot_diag3.jpg b/source/images/Amic110_ice_spi_boot_diag3.jpg
deleted file mode 100644
index c1631ea72..000000000
Binary files a/source/images/Amic110_ice_spi_boot_diag3.jpg and /dev/null differ
diff --git a/source/images/Aud_pre_processing_after.png b/source/images/Aud_pre_processing_after.png
deleted file mode 100644
index 0d7bb8223..000000000
Binary files a/source/images/Aud_pre_processing_after.png and /dev/null differ
diff --git a/source/images/Aud_pre_processing_arch.png b/source/images/Aud_pre_processing_arch.png
deleted file mode 100644
index 32e63fc33..000000000
Binary files a/source/images/Aud_pre_processing_arch.png and /dev/null differ
diff --git a/source/images/Aud_pre_processing_before.png b/source/images/Aud_pre_processing_before.png
deleted file mode 100644
index 5000001c1..000000000
Binary files a/source/images/Aud_pre_processing_before.png and /dev/null differ
diff --git a/source/images/Aud_pre_processing_import.png b/source/images/Aud_pre_processing_import.png
deleted file mode 100644
index 7c552e487..000000000
Binary files a/source/images/Aud_pre_processing_import.png and /dev/null differ
diff --git a/source/images/Audben_dirStructure.png b/source/images/Audben_dirStructure.png
deleted file mode 100644
index 6df87b9c5..000000000
Binary files a/source/images/Audben_dirStructure.png and /dev/null differ
diff --git a/source/images/BIOS_Clock_Architecture.png b/source/images/BIOS_Clock_Architecture.png
deleted file mode 100644
index f5901f442..000000000
Binary files a/source/images/BIOS_Clock_Architecture.png and /dev/null differ
diff --git a/source/images/BIOS_Timer_Architecture.png b/source/images/BIOS_Timer_Architecture.png
deleted file mode 100644
index 9c853eac7..000000000
Binary files a/source/images/BIOS_Timer_Architecture.png and /dev/null differ
diff --git a/source/images/Bare-Metal_A8_templateselect.jpg b/source/images/Bare-Metal_A8_templateselect.jpg
deleted file mode 100644
index 9dda43722..000000000
Binary files a/source/images/Bare-Metal_A8_templateselect.jpg and /dev/null differ
diff --git a/source/images/Bare-Metal_A9_templateselect.jpg b/source/images/Bare-Metal_A9_templateselect.jpg
deleted file mode 100644
index 7e0a230aa..000000000
Binary files a/source/images/Bare-Metal_A9_templateselect.jpg and /dev/null differ
diff --git a/source/images/Bare-Metal_C66x_templateselect.jpg b/source/images/Bare-Metal_C66x_templateselect.jpg
deleted file mode 100644
index 0fe18fd87..000000000
Binary files a/source/images/Bare-Metal_C66x_templateselect.jpg and /dev/null differ
diff --git a/source/images/Bare-Metal_M4_templateselect.jpg b/source/images/Bare-Metal_M4_templateselect.jpg
deleted file mode 100644
index 26dfd6794..000000000
Binary files a/source/images/Bare-Metal_M4_templateselect.jpg and /dev/null differ
diff --git a/source/images/Bare-metal_driver_link.png b/source/images/Bare-metal_driver_link.png
deleted file mode 100644
index d1545000d..000000000
Binary files a/source/images/Bare-metal_driver_link.png and /dev/null differ
diff --git a/source/images/Baremetal_helloWorld_ProjectCreate_step1.png b/source/images/Baremetal_helloWorld_ProjectCreate_step1.png
deleted file mode 100644
index 9711ea2a6..000000000
Binary files a/source/images/Baremetal_helloWorld_ProjectCreate_step1.png and /dev/null differ
diff --git a/source/images/Bh560m-revd-loopbackenable.jpg b/source/images/Bh560m-revd-loopbackenable.jpg
deleted file mode 100644
index cab82e4ef..000000000
Binary files a/source/images/Bh560m-revd-loopbackenable.jpg and /dev/null differ
diff --git a/source/images/BigDataIPC_Rtos_Demo.png b/source/images/BigDataIPC_Rtos_Demo.png
deleted file mode 100644
index b5efeab3c..000000000
Binary files a/source/images/BigDataIPC_Rtos_Demo.png and /dev/null differ
diff --git a/source/images/Big_DATA_IPC_Linux_Software_blocks.png b/source/images/Big_DATA_IPC_Linux_Software_blocks.png
deleted file mode 100644
index c1b10e7a2..000000000
Binary files a/source/images/Big_DATA_IPC_Linux_Software_blocks.png and /dev/null differ
diff --git a/source/images/Big_Data_IPC_RTOS_Software_blocks.png b/source/images/Big_Data_IPC_RTOS_Software_blocks.png
deleted file mode 100644
index 146340dc5..000000000
Binary files a/source/images/Big_Data_IPC_RTOS_Software_blocks.png and /dev/null differ
diff --git a/source/images/Book_cfg.png b/source/images/Book_cfg.png
deleted file mode 100644
index e0ae6d55e..000000000
Binary files a/source/images/Book_cfg.png and /dev/null differ
diff --git a/source/images/Book_run.png b/source/images/Book_run.png
deleted file mode 100644
index 823d45cc5..000000000
Binary files a/source/images/Book_run.png and /dev/null differ
diff --git a/source/images/Build_Benchmark.png b/source/images/Build_Benchmark.png
deleted file mode 100644
index fad3e38d1..000000000
Binary files a/source/images/Build_Benchmark.png and /dev/null differ
diff --git a/source/images/C6678_cio.jpg b/source/images/C6678_cio.jpg
deleted file mode 100644
index f76b34f7c..000000000
Binary files a/source/images/C6678_cio.jpg and /dev/null differ
diff --git a/source/images/C6678_connect_core0.jpg b/source/images/C6678_connect_core0.jpg
deleted file mode 100644
index a434602ed..000000000
Binary files a/source/images/C6678_connect_core0.jpg and /dev/null differ
diff --git a/source/images/C6678_connect_group1.jpg b/source/images/C6678_connect_group1.jpg
deleted file mode 100644
index b47e85371..000000000
Binary files a/source/images/C6678_connect_group1.jpg and /dev/null differ
diff --git a/source/images/C6678_load_master.jpg b/source/images/C6678_load_master.jpg
deleted file mode 100644
index eca55c8af..000000000
Binary files a/source/images/C6678_load_master.jpg and /dev/null differ
diff --git a/source/images/C6678_load_slave.jpg b/source/images/C6678_load_slave.jpg
deleted file mode 100644
index 01863ccbd..000000000
Binary files a/source/images/C6678_load_slave.jpg and /dev/null differ
diff --git a/source/images/CCS-GP437x-EVM-Configure-Target.png b/source/images/CCS-GP437x-EVM-Configure-Target.png
deleted file mode 100644
index 553349de1..000000000
Binary files a/source/images/CCS-GP437x-EVM-Configure-Target.png and /dev/null differ
diff --git a/source/images/CCS-GP437x-EVM-Connnect-Target.png b/source/images/CCS-GP437x-EVM-Connnect-Target.png
deleted file mode 100644
index 3d126d665..000000000
Binary files a/source/images/CCS-GP437x-EVM-Connnect-Target.png and /dev/null differ
diff --git a/source/images/CCS-GP437x-EVM-Launch-Target.png b/source/images/CCS-GP437x-EVM-Launch-Target.png
deleted file mode 100644
index 110aa2149..000000000
Binary files a/source/images/CCS-GP437x-EVM-Launch-Target.png and /dev/null differ
diff --git a/source/images/CCS-GP437x-EVM-New-Target.png b/source/images/CCS-GP437x-EVM-New-Target.png
deleted file mode 100644
index 1fdae265a..000000000
Binary files a/source/images/CCS-GP437x-EVM-New-Target.png and /dev/null differ
diff --git a/source/images/CCS-GP437x-EVM-Run-Target.png b/source/images/CCS-GP437x-EVM-Run-Target.png
deleted file mode 100644
index db23a88c7..000000000
Binary files a/source/images/CCS-GP437x-EVM-Run-Target.png and /dev/null differ
diff --git a/source/images/CCS-GP437x-EVM-Save-Target.png b/source/images/CCS-GP437x-EVM-Save-Target.png
deleted file mode 100644
index da2d981dd..000000000
Binary files a/source/images/CCS-GP437x-EVM-Save-Target.png and /dev/null differ
diff --git a/source/images/CCS-GP437x-EVM-View-Target.png b/source/images/CCS-GP437x-EVM-View-Target.png
deleted file mode 100644
index d86e8afee..000000000
Binary files a/source/images/CCS-GP437x-EVM-View-Target.png and /dev/null differ
diff --git a/source/images/CCS-GP57x-EVM-Custom-Add.png b/source/images/CCS-GP57x-EVM-Custom-Add.png
deleted file mode 100644
index 9069864a5..000000000
Binary files a/source/images/CCS-GP57x-EVM-Custom-Add.png and /dev/null differ
diff --git a/source/images/CCS-GP57x-EVM-Custom-Confirm.png b/source/images/CCS-GP57x-EVM-Custom-Confirm.png
deleted file mode 100644
index a65ad993a..000000000
Binary files a/source/images/CCS-GP57x-EVM-Custom-Confirm.png and /dev/null differ
diff --git a/source/images/CCS-GP57x-EVM-Custom-Finish.png b/source/images/CCS-GP57x-EVM-Custom-Finish.png
deleted file mode 100644
index 6ae03757a..000000000
Binary files a/source/images/CCS-GP57x-EVM-Custom-Finish.png and /dev/null differ
diff --git a/source/images/CCS-GP57x-EVM-Custom-Preferences.png b/source/images/CCS-GP57x-EVM-Custom-Preferences.png
deleted file mode 100644
index 47715e2a2..000000000
Binary files a/source/images/CCS-GP57x-EVM-Custom-Preferences.png and /dev/null differ
diff --git a/source/images/CCS-discovered-products.png b/source/images/CCS-discovered-products.png
deleted file mode 100644
index d93f6f82a..000000000
Binary files a/source/images/CCS-discovered-products.png and /dev/null differ
diff --git a/source/images/CCSFault.PNG b/source/images/CCSFault.PNG
deleted file mode 100644
index 6178b7cc0..000000000
Binary files a/source/images/CCSFault.PNG and /dev/null differ
diff --git a/source/images/CCSV4xds100license.jpg b/source/images/CCSV4xds100license.jpg
deleted file mode 100644
index f9cb83259..000000000
Binary files a/source/images/CCSV4xds100license.jpg and /dev/null differ
diff --git a/source/images/CCS_Project_Browse.png b/source/images/CCS_Project_Browse.png
deleted file mode 100644
index c6391e72f..000000000
Binary files a/source/images/CCS_Project_Browse.png and /dev/null differ
diff --git a/source/images/CCS_console_output.png b/source/images/CCS_console_output.png
deleted file mode 100644
index 2b3825123..000000000
Binary files a/source/images/CCS_console_output.png and /dev/null differ
diff --git a/source/images/CanEth_PCANViewBitRateConfig.png b/source/images/CanEth_PCANViewBitRateConfig.png
deleted file mode 100644
index a36a6a11d..000000000
Binary files a/source/images/CanEth_PCANViewBitRateConfig.png and /dev/null differ
diff --git a/source/images/CanEth_PCANViewTransmitMessageConfig.png b/source/images/CanEth_PCANViewTransmitMessageConfig.png
deleted file mode 100644
index 10b50a51f..000000000
Binary files a/source/images/CanEth_PCANViewTransmitMessageConfig.png and /dev/null differ
diff --git a/source/images/Ccsetup-02.jpg b/source/images/Ccsetup-02.jpg
deleted file mode 100644
index de1b779b8..000000000
Binary files a/source/images/Ccsetup-02.jpg and /dev/null differ
diff --git a/source/images/Ccsetup-04.jpg b/source/images/Ccsetup-04.jpg
deleted file mode 100644
index 02673b956..000000000
Binary files a/source/images/Ccsetup-04.jpg and /dev/null differ
diff --git a/source/images/Ccsetup-05.jpg b/source/images/Ccsetup-05.jpg
deleted file mode 100644
index a577b986c..000000000
Binary files a/source/images/Ccsetup-05.jpg and /dev/null differ
diff --git a/source/images/Ccsv33adaptive.jpg b/source/images/Ccsv33adaptive.jpg
deleted file mode 100644
index 993ff3770..000000000
Binary files a/source/images/Ccsv33adaptive.jpg and /dev/null differ
diff --git a/source/images/Ccsv4adaptive.jpg b/source/images/Ccsv4adaptive.jpg
deleted file mode 100644
index 9d465bb55..000000000
Binary files a/source/images/Ccsv4adaptive.jpg and /dev/null differ
diff --git a/source/images/Ccsv7splash.jpg b/source/images/Ccsv7splash.jpg
deleted file mode 100644
index a4f7c758e..000000000
Binary files a/source/images/Ccsv7splash.jpg and /dev/null differ
diff --git a/source/images/Create_Project_Step1.png b/source/images/Create_Project_Step1.png
deleted file mode 100644
index 262111580..000000000
Binary files a/source/images/Create_Project_Step1.png and /dev/null differ
diff --git a/source/images/Create_Project_Step2.png b/source/images/Create_Project_Step2.png
deleted file mode 100644
index eddaeaeba..000000000
Binary files a/source/images/Create_Project_Step2.png and /dev/null differ
diff --git a/source/images/De1.png b/source/images/De1.png
deleted file mode 100644
index 402b5bcbc..000000000
Binary files a/source/images/De1.png and /dev/null differ
diff --git a/source/images/Demo_web_page_1.jpg b/source/images/Demo_web_page_1.jpg
deleted file mode 100644
index 1ff4553d1..000000000
Binary files a/source/images/Demo_web_page_1.jpg and /dev/null differ
diff --git a/source/images/Demo_web_page_2.jpg b/source/images/Demo_web_page_2.jpg
deleted file mode 100644
index 1770b0e76..000000000
Binary files a/source/images/Demo_web_page_2.jpg and /dev/null differ
diff --git a/source/images/Device_mode_printout.png b/source/images/Device_mode_printout.png
deleted file mode 100644
index 9d4569cc5..000000000
Binary files a/source/images/Device_mode_printout.png and /dev/null differ
diff --git a/source/images/Diag-screen1.jpg b/source/images/Diag-screen1.jpg
deleted file mode 100644
index b6ad8e249..000000000
Binary files a/source/images/Diag-screen1.jpg and /dev/null differ
diff --git a/source/images/Diag-screen2.jpg b/source/images/Diag-screen2.jpg
deleted file mode 100644
index 742ea2e9e..000000000
Binary files a/source/images/Diag-screen2.jpg and /dev/null differ
diff --git a/source/images/Diag-screen3.png b/source/images/Diag-screen3.png
deleted file mode 100644
index 783ed2cc7..000000000
Binary files a/source/images/Diag-screen3.png and /dev/null differ
diff --git a/source/images/Dramaddr.png b/source/images/Dramaddr.png
deleted file mode 100644
index 9a25adb55..000000000
Binary files a/source/images/Dramaddr.png and /dev/null differ
diff --git a/source/images/Dramaddram4.png b/source/images/Dramaddram4.png
deleted file mode 100644
index ece6a79df..000000000
Binary files a/source/images/Dramaddram4.png and /dev/null differ
diff --git a/source/images/Emacboot.jpg b/source/images/Emacboot.jpg
deleted file mode 100644
index d96352ca6..000000000
Binary files a/source/images/Emacboot.jpg and /dev/null differ
diff --git a/source/images/FFTbenchmark_sdBoot.png b/source/images/FFTbenchmark_sdBoot.png
deleted file mode 100644
index ef2801cfb..000000000
Binary files a/source/images/FFTbenchmark_sdBoot.png and /dev/null differ
diff --git a/source/images/Gravit-displayshot_version_01_00_00.jpg b/source/images/Gravit-displayshot_version_01_00_00.jpg
deleted file mode 100644
index 94a7ac124..000000000
Binary files a/source/images/Gravit-displayshot_version_01_00_00.jpg and /dev/null differ
diff --git a/source/images/Gravit-screenshot_version_01_00_00.png b/source/images/Gravit-screenshot_version_01_00_00.png
deleted file mode 100644
index c2596114a..000000000
Binary files a/source/images/Gravit-screenshot_version_01_00_00.png and /dev/null differ
diff --git a/source/images/Heapmp_bigfig.png b/source/images/Heapmp_bigfig.png
deleted file mode 100644
index 91833b2c3..000000000
Binary files a/source/images/Heapmp_bigfig.png and /dev/null differ
diff --git a/source/images/HelloWorldOutput.jpg b/source/images/HelloWorldOutput.jpg
deleted file mode 100644
index 3064321d9..000000000
Binary files a/source/images/HelloWorldOutput.jpg and /dev/null differ
diff --git a/source/images/HelloWorld_cortexA8.png b/source/images/HelloWorld_cortexA8.png
deleted file mode 100644
index 261c56e94..000000000
Binary files a/source/images/HelloWorld_cortexA8.png and /dev/null differ
diff --git a/source/images/HelloWorld_cortexA9.png b/source/images/HelloWorld_cortexA9.png
deleted file mode 100644
index 4b6a6f599..000000000
Binary files a/source/images/HelloWorld_cortexA9.png and /dev/null differ
diff --git a/source/images/Hello_dsp2.png b/source/images/Hello_dsp2.png
deleted file mode 100644
index 7db6faea3..000000000
Binary files a/source/images/Hello_dsp2.png and /dev/null differ
diff --git a/source/images/Hello_world_a8.jpg b/source/images/Hello_world_a8.jpg
deleted file mode 100644
index 303884570..000000000
Binary files a/source/images/Hello_world_a8.jpg and /dev/null differ
diff --git a/source/images/Hello_world_a9.jpg b/source/images/Hello_world_a9.jpg
deleted file mode 100644
index 529d4b3af..000000000
Binary files a/source/images/Hello_world_a9.jpg and /dev/null differ
diff --git a/source/images/Hello_world_dsp.jpg b/source/images/Hello_world_dsp.jpg
deleted file mode 100644
index 9f88d7e72..000000000
Binary files a/source/images/Hello_world_dsp.jpg and /dev/null differ
diff --git a/source/images/Hello_world_dsp674x.png b/source/images/Hello_world_dsp674x.png
deleted file mode 100644
index c4e305437..000000000
Binary files a/source/images/Hello_world_dsp674x.png and /dev/null differ
diff --git a/source/images/Hello_world_dsp674x_rtos.png b/source/images/Hello_world_dsp674x_rtos.png
deleted file mode 100644
index c654a5271..000000000
Binary files a/source/images/Hello_world_dsp674x_rtos.png and /dev/null differ
diff --git a/source/images/Hello_world_m4.jpg b/source/images/Hello_world_m4.jpg
deleted file mode 100644
index 80b74b471..000000000
Binary files a/source/images/Hello_world_m4.jpg and /dev/null differ
diff --git a/source/images/Host_shell_screen_shot.png b/source/images/Host_shell_screen_shot.png
deleted file mode 100644
index a4344dcfa..000000000
Binary files a/source/images/Host_shell_screen_shot.png and /dev/null differ
diff --git a/source/images/Hyperlink_blue.png b/source/images/Hyperlink_blue.png
deleted file mode 100644
index fe60f934f..000000000
Binary files a/source/images/Hyperlink_blue.png and /dev/null differ
diff --git a/source/images/IPC_comm_features.JPG b/source/images/IPC_comm_features.JPG
deleted file mode 100644
index 62b94b1e4..000000000
Binary files a/source/images/IPC_comm_features.JPG and /dev/null differ
diff --git a/source/images/ImportPjt.jpg b/source/images/ImportPjt.jpg
deleted file mode 100644
index 16fd0c411..000000000
Binary files a/source/images/ImportPjt.jpg and /dev/null differ
diff --git a/source/images/Interposer.png b/source/images/Interposer.png
deleted file mode 100644
index 4c58ed898..000000000
Binary files a/source/images/Interposer.png and /dev/null differ
diff --git a/source/images/IpcUG_ipc_2_3_1.png b/source/images/IpcUG_ipc_2_3_1.png
deleted file mode 100644
index ff2f91115..000000000
Binary files a/source/images/IpcUG_ipc_2_3_1.png and /dev/null differ
diff --git a/source/images/IpcUG_ipc_2_3_2.png b/source/images/IpcUG_ipc_2_3_2.png
deleted file mode 100644
index 0e45c10bc..000000000
Binary files a/source/images/IpcUG_ipc_2_3_2.png and /dev/null differ
diff --git a/source/images/IpcUG_ipc_2_4_1.png b/source/images/IpcUG_ipc_2_4_1.png
deleted file mode 100644
index db8a60de7..000000000
Binary files a/source/images/IpcUG_ipc_2_4_1.png and /dev/null differ
diff --git a/source/images/IpcUG_ipc_2_6_1.png b/source/images/IpcUG_ipc_2_6_1.png
deleted file mode 100644
index e859096eb..000000000
Binary files a/source/images/IpcUG_ipc_2_6_1.png and /dev/null differ
diff --git a/source/images/IpcUG_ipc_2_8_1.png b/source/images/IpcUG_ipc_2_8_1.png
deleted file mode 100644
index 49fc15067..000000000
Binary files a/source/images/IpcUG_ipc_2_8_1.png and /dev/null differ
diff --git a/source/images/IpcUG_ipc_2_8_2.png b/source/images/IpcUG_ipc_2_8_2.png
deleted file mode 100644
index 629dc6c87..000000000
Binary files a/source/images/IpcUG_ipc_2_8_2.png and /dev/null differ
diff --git a/source/images/IpcUG_over_1_2_1.png b/source/images/IpcUG_over_1_2_1.png
deleted file mode 100644
index f164e61c1..000000000
Binary files a/source/images/IpcUG_over_1_2_1.png and /dev/null differ
diff --git a/source/images/IpcUG_over_1_2_2.png b/source/images/IpcUG_over_1_2_2.png
deleted file mode 100644
index 95698cbad..000000000
Binary files a/source/images/IpcUG_over_1_2_2.png and /dev/null differ
diff --git a/source/images/IpcUG_over_1_2_3.png b/source/images/IpcUG_over_1_2_3.png
deleted file mode 100644
index a7f3f2dd3..000000000
Binary files a/source/images/IpcUG_over_1_2_3.png and /dev/null differ
diff --git a/source/images/IpcUG_over_1_2_4.png b/source/images/IpcUG_over_1_2_4.png
deleted file mode 100644
index b160e5a71..000000000
Binary files a/source/images/IpcUG_over_1_2_4.png and /dev/null differ
diff --git a/source/images/J21_gpio_input.png b/source/images/J21_gpio_input.png
deleted file mode 100644
index a1af9f30d..000000000
Binary files a/source/images/J21_gpio_input.png and /dev/null differ
diff --git a/source/images/K2-k1-hyplnk.jpg b/source/images/K2-k1-hyplnk.jpg
deleted file mode 100644
index dcd643bb1..000000000
Binary files a/source/images/K2-k1-hyplnk.jpg and /dev/null differ
diff --git a/source/images/K2g_boot_diag.jpg b/source/images/K2g_boot_diag.jpg
deleted file mode 100644
index 643fac250..000000000
Binary files a/source/images/K2g_boot_diag.jpg and /dev/null differ
diff --git a/source/images/K2h_cio.jpg b/source/images/K2h_cio.jpg
deleted file mode 100644
index 1b063c327..000000000
Binary files a/source/images/K2h_cio.jpg and /dev/null differ
diff --git a/source/images/K2h_connect_a15.jpg b/source/images/K2h_connect_a15.jpg
deleted file mode 100644
index a30953d51..000000000
Binary files a/source/images/K2h_connect_a15.jpg and /dev/null differ
diff --git a/source/images/K2h_connect_group1.jpg b/source/images/K2h_connect_group1.jpg
deleted file mode 100644
index 06bf32fef..000000000
Binary files a/source/images/K2h_connect_group1.jpg and /dev/null differ
diff --git a/source/images/K2h_from_group1.jpg b/source/images/K2h_from_group1.jpg
deleted file mode 100644
index 75c33f339..000000000
Binary files a/source/images/K2h_from_group1.jpg and /dev/null differ
diff --git a/source/images/K2h_load_a15.jpg b/source/images/K2h_load_a15.jpg
deleted file mode 100644
index c998b4cde..000000000
Binary files a/source/images/K2h_load_a15.jpg and /dev/null differ
diff --git a/source/images/K2h_load_group1.jpg b/source/images/K2h_load_group1.jpg
deleted file mode 100644
index a129d2d87..000000000
Binary files a/source/images/K2h_load_group1.jpg and /dev/null differ
diff --git a/source/images/K2h_run_a15.jpg b/source/images/K2h_run_a15.jpg
deleted file mode 100644
index d51b00259..000000000
Binary files a/source/images/K2h_run_a15.jpg and /dev/null differ
diff --git a/source/images/K2h_run_group1.jpg b/source/images/K2h_run_group1.jpg
deleted file mode 100644
index 8d8f6653c..000000000
Binary files a/source/images/K2h_run_group1.jpg and /dev/null differ
diff --git a/source/images/K2h_web_1.jpg b/source/images/K2h_web_1.jpg
deleted file mode 100644
index 6d55634b8..000000000
Binary files a/source/images/K2h_web_1.jpg and /dev/null differ
diff --git a/source/images/K2h_web_2.jpg b/source/images/K2h_web_2.jpg
deleted file mode 100644
index a4a4660bd..000000000
Binary files a/source/images/K2h_web_2.jpg and /dev/null differ
diff --git a/source/images/KSII_RS.png b/source/images/KSII_RS.png
deleted file mode 100644
index b9425ff90..000000000
Binary files a/source/images/KSII_RS.png and /dev/null differ
diff --git a/source/images/KSI_RS.png b/source/images/KSI_RS.png
deleted file mode 100644
index 8c1448ace..000000000
Binary files a/source/images/KSI_RS.png and /dev/null differ
diff --git a/source/images/Lib_sw_stack_rtos.jpg b/source/images/Lib_sw_stack_rtos.jpg
deleted file mode 100644
index cec459a41..000000000
Binary files a/source/images/Lib_sw_stack_rtos.jpg and /dev/null differ
diff --git a/source/images/Linalg.jpg b/source/images/Linalg.jpg
deleted file mode 100644
index 0b4d06606..000000000
Binary files a/source/images/Linalg.jpg and /dev/null differ
diff --git a/source/images/MDL-ADA2_cables.jpg b/source/images/MDL-ADA2_cables.jpg
deleted file mode 100644
index f273c1d3f..000000000
Binary files a/source/images/MDL-ADA2_cables.jpg and /dev/null differ
diff --git a/source/images/MPROG_3.5.jpg b/source/images/MPROG_3.5.jpg
deleted file mode 100644
index 7e05ecfe6..000000000
Binary files a/source/images/MPROG_3.5.jpg and /dev/null differ
diff --git a/source/images/Make_help.png b/source/images/Make_help.png
deleted file mode 100644
index 0824610aa..000000000
Binary files a/source/images/Make_help.png and /dev/null differ
diff --git a/source/images/MesgQ_arm0.png b/source/images/MesgQ_arm0.png
deleted file mode 100644
index 72e542682..000000000
Binary files a/source/images/MesgQ_arm0.png and /dev/null differ
diff --git a/source/images/Multicore_app_image.png b/source/images/Multicore_app_image.png
deleted file mode 100644
index 1e15f608e..000000000
Binary files a/source/images/Multicore_app_image.png and /dev/null differ
diff --git a/source/images/NDK_ARCH.png b/source/images/NDK_ARCH.png
deleted file mode 100644
index e3154de44..000000000
Binary files a/source/images/NDK_ARCH.png and /dev/null differ
diff --git a/source/images/Nandboot.jpg b/source/images/Nandboot.jpg
deleted file mode 100644
index e22b943f8..000000000
Binary files a/source/images/Nandboot.jpg and /dev/null differ
diff --git a/source/images/Ndksend.png b/source/images/Ndksend.png
deleted file mode 100644
index b3d8b427f..000000000
Binary files a/source/images/Ndksend.png and /dev/null differ
diff --git a/source/images/NewCCSProject_Hello_world.png b/source/images/NewCCSProject_Hello_world.png
deleted file mode 100644
index 0ea367aaf..000000000
Binary files a/source/images/NewCCSProject_Hello_world.png and /dev/null differ
diff --git a/source/images/Norboot.jpg b/source/images/Norboot.jpg
deleted file mode 100644
index 6134d8625..000000000
Binary files a/source/images/Norboot.jpg and /dev/null differ
diff --git a/source/images/Notify_peer_arm0.png b/source/images/Notify_peer_arm0.png
deleted file mode 100644
index bbfc4ad03..000000000
Binary files a/source/images/Notify_peer_arm0.png and /dev/null differ
diff --git a/source/images/OMAPL138_SYSBIOS_TI_RTOS_CCSv7.png b/source/images/OMAPL138_SYSBIOS_TI_RTOS_CCSv7.png
deleted file mode 100644
index 54dce9433..000000000
Binary files a/source/images/OMAPL138_SYSBIOS_TI_RTOS_CCSv7.png and /dev/null differ
diff --git a/source/images/Omapl137_boot_example.jpg b/source/images/Omapl137_boot_example.jpg
deleted file mode 100644
index f35e523d1..000000000
Binary files a/source/images/Omapl137_boot_example.jpg and /dev/null differ
diff --git a/source/images/Omapl137_usb_ac_setup.jpg b/source/images/Omapl137_usb_ac_setup.jpg
deleted file mode 100644
index cb1671c32..000000000
Binary files a/source/images/Omapl137_usb_ac_setup.jpg and /dev/null differ
diff --git a/source/images/Omapl138_boot_example.png b/source/images/Omapl138_boot_example.png
deleted file mode 100644
index 4faa76b40..000000000
Binary files a/source/images/Omapl138_boot_example.png and /dev/null differ
diff --git a/source/images/Omapl138_usb_ac_setup.jpg b/source/images/Omapl138_usb_ac_setup.jpg
deleted file mode 100644
index d9a715736..000000000
Binary files a/source/images/Omapl138_usb_ac_setup.jpg and /dev/null differ
diff --git a/source/images/Omp_h1_project_setup.jpg b/source/images/Omp_h1_project_setup.jpg
deleted file mode 100644
index e94008d1d..000000000
Binary files a/source/images/Omp_h1_project_setup.jpg and /dev/null differ
diff --git a/source/images/Omp_h2_debug_icon.JPG b/source/images/Omp_h2_debug_icon.JPG
deleted file mode 100644
index e84d188eb..000000000
Binary files a/source/images/Omp_h2_debug_icon.JPG and /dev/null differ
diff --git a/source/images/Omp_h3_select_cores.JPG b/source/images/Omp_h3_select_cores.JPG
deleted file mode 100644
index f773c89f5..000000000
Binary files a/source/images/Omp_h3_select_cores.JPG and /dev/null differ
diff --git a/source/images/Omp_h4_resume_icon.JPG b/source/images/Omp_h4_resume_icon.JPG
deleted file mode 100644
index c5bd6e438..000000000
Binary files a/source/images/Omp_h4_resume_icon.JPG and /dev/null differ
diff --git a/source/images/Omp_h5_matvec_setup.JPG b/source/images/Omp_h5_matvec_setup.JPG
deleted file mode 100644
index ba1154d60..000000000
Binary files a/source/images/Omp_h5_matvec_setup.JPG and /dev/null differ
diff --git a/source/images/Omp_h6_group_cores.JPG b/source/images/Omp_h6_group_cores.JPG
deleted file mode 100644
index e0ae506ba..000000000
Binary files a/source/images/Omp_h6_group_cores.JPG and /dev/null differ
diff --git a/source/images/Omp_h7_cpu_reset.JPG b/source/images/Omp_h7_cpu_reset.JPG
deleted file mode 100644
index f8d6308b4..000000000
Binary files a/source/images/Omp_h7_cpu_reset.JPG and /dev/null differ
diff --git a/source/images/Pcap.zip b/source/images/Pcap.zip
deleted file mode 100644
index ad8c9a791..000000000
Binary files a/source/images/Pcap.zip and /dev/null differ
diff --git a/source/images/Ping_dsp1.png b/source/images/Ping_dsp1.png
deleted file mode 100644
index 1e5945cc2..000000000
Binary files a/source/images/Ping_dsp1.png and /dev/null differ
diff --git a/source/images/Platfrom_configuration.png b/source/images/Platfrom_configuration.png
deleted file mode 100644
index 1c4fe191b..000000000
Binary files a/source/images/Platfrom_configuration.png and /dev/null differ
diff --git a/source/images/Posix-demo-uart.PNG b/source/images/Posix-demo-uart.PNG
deleted file mode 100644
index 6bb10b514..000000000
Binary files a/source/images/Posix-demo-uart.PNG and /dev/null differ
diff --git a/source/images/Posix-smp2.png b/source/images/Posix-smp2.png
deleted file mode 100644
index c47581d3a..000000000
Binary files a/source/images/Posix-smp2.png and /dev/null differ
diff --git a/source/images/Processor-SDK-RTOS-directories.png b/source/images/Processor-SDK-RTOS-directories.png
deleted file mode 100644
index 77778f18b..000000000
Binary files a/source/images/Processor-SDK-RTOS-directories.png and /dev/null differ
diff --git a/source/images/Processor-SDK-RTOS-directory-top.png b/source/images/Processor-SDK-RTOS-directory-top.png
deleted file mode 100644
index 875a0f50b..000000000
Binary files a/source/images/Processor-SDK-RTOS-directory-top.png and /dev/null differ
diff --git a/source/images/Processor-SDK_CCS-Emu-Update.png b/source/images/Processor-SDK_CCS-Emu-Update.png
deleted file mode 100644
index fe9a4a1b4..000000000
Binary files a/source/images/Processor-SDK_CCS-Emu-Update.png and /dev/null differ
diff --git a/source/images/Processor-SDK_CCSv7-Setup-Processor-Support.png b/source/images/Processor-SDK_CCSv7-Setup-Processor-Support.png
deleted file mode 100644
index ebfb3838c..000000000
Binary files a/source/images/Processor-SDK_CCSv7-Setup-Processor-Support.png and /dev/null differ
diff --git a/source/images/QMSSIPC_project1.png b/source/images/QMSSIPC_project1.png
deleted file mode 100644
index 4fce6318b..000000000
Binary files a/source/images/QMSSIPC_project1.png and /dev/null differ
diff --git a/source/images/Qmss_IPC.png b/source/images/Qmss_IPC.png
deleted file mode 100644
index 1f36bf280..000000000
Binary files a/source/images/Qmss_IPC.png and /dev/null differ
diff --git a/source/images/Qmss_transports.png b/source/images/Qmss_transports.png
deleted file mode 100644
index 5120b90a6..000000000
Binary files a/source/images/Qmss_transports.png and /dev/null differ
diff --git a/source/images/RTOS-Software-Architecture.png b/source/images/RTOS-Software-Architecture.png
deleted file mode 100644
index 8f952a17f..000000000
Binary files a/source/images/RTOS-Software-Architecture.png and /dev/null differ
diff --git a/source/images/RTOS_CortexA8_HelloWorld.png b/source/images/RTOS_CortexA8_HelloWorld.png
deleted file mode 100644
index 5cbd4486a..000000000
Binary files a/source/images/RTOS_CortexA8_HelloWorld.png and /dev/null differ
diff --git a/source/images/RTOS_CortexA9_HelloWorld.png b/source/images/RTOS_CortexA9_HelloWorld.png
deleted file mode 100644
index 2fe2a850c..000000000
Binary files a/source/images/RTOS_CortexA9_HelloWorld.png and /dev/null differ
diff --git a/source/images/Rebuild_addrep.png b/source/images/Rebuild_addrep.png
deleted file mode 100644
index fe984a3e3..000000000
Binary files a/source/images/Rebuild_addrep.png and /dev/null differ
diff --git a/source/images/Rebuild_deselect.png b/source/images/Rebuild_deselect.png
deleted file mode 100644
index 966c12fc5..000000000
Binary files a/source/images/Rebuild_deselect.png and /dev/null differ
diff --git a/source/images/RegisterDump.PNG b/source/images/RegisterDump.PNG
deleted file mode 100644
index bc46f90f0..000000000
Binary files a/source/images/RegisterDump.PNG and /dev/null differ
diff --git a/source/images/Rov.png b/source/images/Rov.png
deleted file mode 100644
index c8e6486f9..000000000
Binary files a/source/images/Rov.png and /dev/null differ
diff --git a/source/images/Rta_exec2.png b/source/images/Rta_exec2.png
deleted file mode 100644
index 0da885557..000000000
Binary files a/source/images/Rta_exec2.png and /dev/null differ
diff --git a/source/images/SA.png b/source/images/SA.png
deleted file mode 100644
index 9ee7fc107..000000000
Binary files a/source/images/SA.png and /dev/null differ
diff --git a/source/images/SBL_mem_k2g.jpg b/source/images/SBL_mem_k2g.jpg
deleted file mode 100644
index cffb0ee2b..000000000
Binary files a/source/images/SBL_mem_k2g.jpg and /dev/null differ
diff --git a/source/images/SBL_memory_map.png b/source/images/SBL_memory_map.png
deleted file mode 100644
index 9a3d280f6..000000000
Binary files a/source/images/SBL_memory_map.png and /dev/null differ
diff --git a/source/images/SDF_Format_complete.png b/source/images/SDF_Format_complete.png
deleted file mode 100644
index b1c85bae0..000000000
Binary files a/source/images/SDF_Format_complete.png and /dev/null differ
diff --git a/source/images/SDFormatter_screenshot.png b/source/images/SDFormatter_screenshot.png
deleted file mode 100644
index 96ec36a51..000000000
Binary files a/source/images/SDFormatter_screenshot.png and /dev/null differ
diff --git a/source/images/SYSBIOS_CPUload.jpg b/source/images/SYSBIOS_CPUload.jpg
deleted file mode 100644
index 5253f5295..000000000
Binary files a/source/images/SYSBIOS_CPUload.jpg and /dev/null differ
diff --git a/source/images/SYSBIOS_DSP_platformSelect.jpg b/source/images/SYSBIOS_DSP_platformSelect.jpg
deleted file mode 100644
index 78676a9ef..000000000
Binary files a/source/images/SYSBIOS_DSP_platformSelect.jpg and /dev/null differ
diff --git a/source/images/SYSBIOS_Diag.jpg b/source/images/SYSBIOS_Diag.jpg
deleted file mode 100644
index 03081019f..000000000
Binary files a/source/images/SYSBIOS_Diag.jpg and /dev/null differ
diff --git a/source/images/SYSBIOS_M4_platformSelect.jpg b/source/images/SYSBIOS_M4_platformSelect.jpg
deleted file mode 100644
index 5c0395f8d..000000000
Binary files a/source/images/SYSBIOS_M4_platformSelect.jpg and /dev/null differ
diff --git a/source/images/SYSBIOS_Rawlog.jpg b/source/images/SYSBIOS_Rawlog.jpg
deleted file mode 100644
index 594b4905b..000000000
Binary files a/source/images/SYSBIOS_Rawlog.jpg and /dev/null differ
diff --git a/source/images/SYSBIOS_hello_world_M4_template.jpg b/source/images/SYSBIOS_hello_world_M4_template.jpg
deleted file mode 100644
index cfc4b3990..000000000
Binary files a/source/images/SYSBIOS_hello_world_M4_template.jpg and /dev/null differ
diff --git a/source/images/SYSBIOS_hello_world_dsp_template.jpg b/source/images/SYSBIOS_hello_world_dsp_template.jpg
deleted file mode 100644
index 50b0ee8cf..000000000
Binary files a/source/images/SYSBIOS_hello_world_dsp_template.jpg and /dev/null differ
diff --git a/source/images/Sbl_example.jpg b/source/images/Sbl_example.jpg
deleted file mode 100644
index 50ba763b7..000000000
Binary files a/source/images/Sbl_example.jpg and /dev/null differ
diff --git a/source/images/Select_core.JPG b/source/images/Select_core.JPG
deleted file mode 100644
index 09d452eb5..000000000
Binary files a/source/images/Select_core.JPG and /dev/null differ
diff --git a/source/images/Sound.png b/source/images/Sound.png
deleted file mode 100644
index ff4b0de43..000000000
Binary files a/source/images/Sound.png and /dev/null differ
diff --git a/source/images/SourceInsightCrashDump.PNG b/source/images/SourceInsightCrashDump.PNG
deleted file mode 100644
index 6d968fbe1..000000000
Binary files a/source/images/SourceInsightCrashDump.PNG and /dev/null differ
diff --git a/source/images/Sourcefilepjt.jpg b/source/images/Sourcefilepjt.jpg
deleted file mode 100644
index d17621d3b..000000000
Binary files a/source/images/Sourcefilepjt.jpg and /dev/null differ
diff --git a/source/images/Speaker_setup.png b/source/images/Speaker_setup.png
deleted file mode 100644
index af7dce789..000000000
Binary files a/source/images/Speaker_setup.png and /dev/null differ
diff --git a/source/images/Spi_flash_writer_output.jpg b/source/images/Spi_flash_writer_output.jpg
deleted file mode 100644
index dd00d722a..000000000
Binary files a/source/images/Spi_flash_writer_output.jpg and /dev/null differ
diff --git a/source/images/StackTraceDump.PNG b/source/images/StackTraceDump.PNG
deleted file mode 100644
index 68684074f..000000000
Binary files a/source/images/StackTraceDump.PNG and /dev/null differ
diff --git a/source/images/StackTraceDump2.PNG b/source/images/StackTraceDump2.PNG
deleted file mode 100644
index a40bec8d7..000000000
Binary files a/source/images/StackTraceDump2.PNG and /dev/null differ
diff --git a/source/images/Storm_Prevention_architecture_Industrial.jpeg b/source/images/Storm_Prevention_architecture_Industrial.jpeg
deleted file mode 100644
index 83badc8f3..000000000
Binary files a/source/images/Storm_Prevention_architecture_Industrial.jpeg and /dev/null differ
diff --git a/source/images/Stormprev.png b/source/images/Stormprev.png
deleted file mode 100644
index c1f4fa83f..000000000
Binary files a/source/images/Stormprev.png and /dev/null differ
diff --git a/source/images/Sys_bios_hello_example_screen_1.jpg b/source/images/Sys_bios_hello_example_screen_1.jpg
deleted file mode 100644
index 7902518e7..000000000
Binary files a/source/images/Sys_bios_hello_example_screen_1.jpg and /dev/null differ
diff --git a/source/images/Sys_bios_hello_example_screen_2.jpg b/source/images/Sys_bios_hello_example_screen_2.jpg
deleted file mode 100644
index be37a7913..000000000
Binary files a/source/images/Sys_bios_hello_example_screen_2.jpg and /dev/null differ
diff --git a/source/images/System_Analyzer_Execution_log.png b/source/images/System_Analyzer_Execution_log.png
deleted file mode 100644
index 44b29f201..000000000
Binary files a/source/images/System_Analyzer_Execution_log.png and /dev/null differ
diff --git a/source/images/TMDSADP1414-ISO.jpg b/source/images/TMDSADP1414-ISO.jpg
deleted file mode 100644
index b14ba0901..000000000
Binary files a/source/images/TMDSADP1414-ISO.jpg and /dev/null differ
diff --git a/source/images/TMDSADP1414.jpg b/source/images/TMDSADP1414.jpg
deleted file mode 100644
index d40b8521d..000000000
Binary files a/source/images/TMDSADP1414.jpg and /dev/null differ
diff --git a/source/images/TMDSADP1420.jpg b/source/images/TMDSADP1420.jpg
deleted file mode 100644
index 2519e8830..000000000
Binary files a/source/images/TMDSADP1420.jpg and /dev/null differ
diff --git a/source/images/TMDSADP1460.jpg b/source/images/TMDSADP1460.jpg
deleted file mode 100644
index 13b3fb3e6..000000000
Binary files a/source/images/TMDSADP1460.jpg and /dev/null differ
diff --git a/source/images/TMDSADPEMU-20A.png b/source/images/TMDSADPEMU-20A.png
deleted file mode 100644
index 1f52805ad..000000000
Binary files a/source/images/TMDSADPEMU-20A.png and /dev/null differ
diff --git a/source/images/TMDSADPEMU-20T.png b/source/images/TMDSADPEMU-20T.png
deleted file mode 100644
index a0b608571..000000000
Binary files a/source/images/TMDSADPEMU-20T.png and /dev/null differ
diff --git a/source/images/UIAMetaData.zip b/source/images/UIAMetaData.zip
deleted file mode 100644
index 147dee954..000000000
Binary files a/source/images/UIAMetaData.zip and /dev/null differ
diff --git a/source/images/USB_Audio_class_flowchart.jpg b/source/images/USB_Audio_class_flowchart.jpg
deleted file mode 100644
index 9e4ed04cb..000000000
Binary files a/source/images/USB_Audio_class_flowchart.jpg and /dev/null differ
diff --git a/source/images/USB_MSC_device.PNG b/source/images/USB_MSC_device.PNG
deleted file mode 100644
index 884f2f36a..000000000
Binary files a/source/images/USB_MSC_device.PNG and /dev/null differ
diff --git a/source/images/USB_MSC_device_API_flow.PNG b/source/images/USB_MSC_device_API_flow.PNG
deleted file mode 100644
index c435b77bb..000000000
Binary files a/source/images/USB_MSC_device_API_flow.PNG and /dev/null differ
diff --git a/source/images/USB_MSC_device_example_blocks.PNG b/source/images/USB_MSC_device_example_blocks.PNG
deleted file mode 100644
index 412f63d3f..000000000
Binary files a/source/images/USB_MSC_device_example_blocks.PNG and /dev/null differ
diff --git a/source/images/USB_MSC_host.PNG b/source/images/USB_MSC_host.PNG
deleted file mode 100644
index 4a1533c08..000000000
Binary files a/source/images/USB_MSC_host.PNG and /dev/null differ
diff --git a/source/images/USB_MSC_host_API_flow.PNG b/source/images/USB_MSC_host_API_flow.PNG
deleted file mode 100644
index 6c6e10e78..000000000
Binary files a/source/images/USB_MSC_host_API_flow.PNG and /dev/null differ
diff --git a/source/images/USB_MSC_host_example_blocks.PNG b/source/images/USB_MSC_host_example_blocks.PNG
deleted file mode 100644
index a58095bb8..000000000
Binary files a/source/images/USB_MSC_host_example_blocks.PNG and /dev/null differ
diff --git a/source/images/Uniflash_Execution_Steps.png b/source/images/Uniflash_Execution_Steps.png
deleted file mode 100644
index 13a4ff3d4..000000000
Binary files a/source/images/Uniflash_Execution_Steps.png and /dev/null differ
diff --git a/source/images/Usb_device_mmcsd.PNG b/source/images/Usb_device_mmcsd.PNG
deleted file mode 100644
index 1bf447cb6..000000000
Binary files a/source/images/Usb_device_mmcsd.PNG and /dev/null differ
diff --git a/source/images/Use_rov_1.jpg b/source/images/Use_rov_1.jpg
deleted file mode 100644
index 93f0e2a70..000000000
Binary files a/source/images/Use_rov_1.jpg and /dev/null differ
diff --git a/source/images/Use_rov_2.png b/source/images/Use_rov_2.png
deleted file mode 100644
index df3aa0a8b..000000000
Binary files a/source/images/Use_rov_2.png and /dev/null differ
diff --git a/source/images/Windows_pdk_usb.png b/source/images/Windows_pdk_usb.png
deleted file mode 100644
index 3c24e0a2c..000000000
Binary files a/source/images/Windows_pdk_usb.png and /dev/null differ
diff --git a/source/images/WordSelect_LSB.PNG b/source/images/WordSelect_LSB.PNG
deleted file mode 100644
index 2770e371f..000000000
Binary files a/source/images/WordSelect_LSB.PNG and /dev/null differ
diff --git a/source/images/WordSelect_MSB.PNG b/source/images/WordSelect_MSB.PNG
deleted file mode 100644
index baaaeac5b..000000000
Binary files a/source/images/WordSelect_MSB.PNG and /dev/null differ
diff --git a/source/images/Xd100damagedvidpid.jpg b/source/images/Xd100damagedvidpid.jpg
deleted file mode 100644
index 59e03578b..000000000
Binary files a/source/images/Xd100damagedvidpid.jpg and /dev/null differ
diff --git a/source/images/Xds100onWin10-sysdevices.png b/source/images/Xds100onWin10-sysdevices.png
deleted file mode 100644
index ca1885ac6..000000000
Binary files a/source/images/Xds100onWin10-sysdevices.png and /dev/null differ
diff --git a/source/images/Xds100v1nopiddbgjtagpodfail.jpg b/source/images/Xds100v1nopiddbgjtagpodfail.jpg
deleted file mode 100644
index 1822eecdd..000000000
Binary files a/source/images/Xds100v1nopiddbgjtagpodfail.jpg and /dev/null differ
diff --git a/source/images/Xds100v1poderror.jpg b/source/images/Xds100v1poderror.jpg
deleted file mode 100644
index 817cc18f8..000000000
Binary files a/source/images/Xds100v1poderror.jpg and /dev/null differ
diff --git a/source/images/Xds100v2_adaptiveb.jpg b/source/images/Xds100v2_adaptiveb.jpg
deleted file mode 100644
index be77fb7e9..000000000
Binary files a/source/images/Xds100v2_adaptiveb.jpg and /dev/null differ
diff --git a/source/images/Xds100v2_dm365_timeout.jpg b/source/images/Xds100v2_dm365_timeout.jpg
deleted file mode 100644
index 2df6feeb8..000000000
Binary files a/source/images/Xds100v2_dm365_timeout.jpg and /dev/null differ
diff --git a/source/images/am572x-evm-hw-setup-back.jpg b/source/images/am572x-evm-hw-setup-back.jpg
deleted file mode 100644
index 89eda4ba0..000000000
Binary files a/source/images/am572x-evm-hw-setup-back.jpg and /dev/null differ
diff --git a/source/images/am572x-evm-hw-setup-front.jpg b/source/images/am572x-evm-hw-setup-front.jpg
deleted file mode 100644
index 1ca57dad2..000000000
Binary files a/source/images/am572x-evm-hw-setup-front.jpg and /dev/null differ
diff --git a/source/images/am572x-evm-target-config.png b/source/images/am572x-evm-target-config.png
deleted file mode 100644
index 9b35431f5..000000000
Binary files a/source/images/am572x-evm-target-config.png and /dev/null differ
diff --git a/source/images/am65x_evm_idk_board_changes_for_mcan_interface1.png b/source/images/am65x_evm_idk_board_changes_for_mcan_interface1.png
deleted file mode 100644
index 0da14fa77..000000000
Binary files a/source/images/am65x_evm_idk_board_changes_for_mcan_interface1.png and /dev/null differ
diff --git a/source/images/am65x_evm_idk_board_changes_for_mcan_interface2.png b/source/images/am65x_evm_idk_board_changes_for_mcan_interface2.png
deleted file mode 100644
index c768a0c11..000000000
Binary files a/source/images/am65x_evm_idk_board_changes_for_mcan_interface2.png and /dev/null differ
diff --git a/source/images/can-eth-gateway.png b/source/images/can-eth-gateway.png
deleted file mode 100644
index 08d1c9b58..000000000
Binary files a/source/images/can-eth-gateway.png and /dev/null differ
diff --git a/source/images/ccs-debug-pers.png b/source/images/ccs-debug-pers.png
deleted file mode 100644
index e67f31632..000000000
Binary files a/source/images/ccs-debug-pers.png and /dev/null differ
diff --git a/source/images/gpio_test.png b/source/images/gpio_test.png
deleted file mode 100644
index ad16a6d8f..000000000
Binary files a/source/images/gpio_test.png and /dev/null differ
diff --git a/source/images/gpmc_cs0_t1.png b/source/images/gpmc_cs0_t1.png
deleted file mode 100644
index 2db5b1c58..000000000
Binary files a/source/images/gpmc_cs0_t1.png and /dev/null differ
diff --git a/source/images/import-ccs-project.png b/source/images/import-ccs-project.png
deleted file mode 100644
index 192543e23..000000000
Binary files a/source/images/import-ccs-project.png and /dev/null differ
diff --git a/source/images/install-discovered-products.png b/source/images/install-discovered-products.png
deleted file mode 100644
index dc037eb9d..000000000
Binary files a/source/images/install-discovered-products.png and /dev/null differ
diff --git a/source/images/ipclld_Linux_Start.png b/source/images/ipclld_Linux_Start.png
deleted file mode 100644
index 55d081b3d..000000000
Binary files a/source/images/ipclld_Linux_Start.png and /dev/null differ
diff --git a/source/images/ipclld_LoadingSysFw_sciclient.png b/source/images/ipclld_LoadingSysFw_sciclient.png
deleted file mode 100644
index 53505a5e9..000000000
Binary files a/source/images/ipclld_LoadingSysFw_sciclient.png and /dev/null differ
diff --git a/source/images/ipclld_Sample_output_mpu.png b/source/images/ipclld_Sample_output_mpu.png
deleted file mode 100644
index 3b2f60def..000000000
Binary files a/source/images/ipclld_Sample_output_mpu.png and /dev/null differ
diff --git a/source/images/ipclld_data_flow.png b/source/images/ipclld_data_flow.png
deleted file mode 100644
index 46faba375..000000000
Binary files a/source/images/ipclld_data_flow.png and /dev/null differ
diff --git a/source/images/ipclld_file_org.png b/source/images/ipclld_file_org.png
deleted file mode 100644
index 2a8b839e4..000000000
Binary files a/source/images/ipclld_file_org.png and /dev/null differ
diff --git a/source/images/ipclld_linux_output.png b/source/images/ipclld_linux_output.png
deleted file mode 100644
index dc9401322..000000000
Binary files a/source/images/ipclld_linux_output.png and /dev/null differ
diff --git a/source/images/k3_sbl_arch_block_diag.png b/source/images/k3_sbl_arch_block_diag.png
deleted file mode 100644
index 2e041477d..000000000
Binary files a/source/images/k3_sbl_arch_block_diag.png and /dev/null differ
diff --git a/source/images/k3_sbl_mem_usage.png b/source/images/k3_sbl_mem_usage.png
deleted file mode 100644
index 835dea635..000000000
Binary files a/source/images/k3_sbl_mem_usage.png and /dev/null differ
diff --git a/source/images/load-executable.png b/source/images/load-executable.png
deleted file mode 100644
index 2c5ff3c32..000000000
Binary files a/source/images/load-executable.png and /dev/null differ
diff --git a/source/images/omapl13x_arm9_hello_nonos_ccs.png b/source/images/omapl13x_arm9_hello_nonos_ccs.png
deleted file mode 100644
index fa6d056be..000000000
Binary files a/source/images/omapl13x_arm9_hello_nonos_ccs.png and /dev/null differ
diff --git a/source/images/omapl13x_arm9_hello_nonos_ccs2.png b/source/images/omapl13x_arm9_hello_nonos_ccs2.png
deleted file mode 100644
index bb09b5fce..000000000
Binary files a/source/images/omapl13x_arm9_hello_nonos_ccs2.png and /dev/null differ
diff --git a/source/images/omapl13x_arm9_hello_rtos_ccs.png b/source/images/omapl13x_arm9_hello_rtos_ccs.png
deleted file mode 100644
index c8271678a..000000000
Binary files a/source/images/omapl13x_arm9_hello_rtos_ccs.png and /dev/null differ
diff --git a/source/images/omapl13x_arm9_hello_rtos_tirex.png b/source/images/omapl13x_arm9_hello_rtos_tirex.png
deleted file mode 100644
index b1d5b6836..000000000
Binary files a/source/images/omapl13x_arm9_hello_rtos_tirex.png and /dev/null differ
diff --git a/source/images/pa_k2g_EVM_DC_HDMI_setup.png b/source/images/pa_k2g_EVM_DC_HDMI_setup.png
deleted file mode 100644
index 01987dc5e..000000000
Binary files a/source/images/pa_k2g_EVM_DC_HDMI_setup.png and /dev/null differ
diff --git a/source/images/pa_k2g_EVM_DC_setup.png b/source/images/pa_k2g_EVM_DC_setup.png
deleted file mode 100644
index 38081d8fc..000000000
Binary files a/source/images/pa_k2g_EVM_DC_setup.png and /dev/null differ
diff --git a/source/images/pa_k2g_layout.png b/source/images/pa_k2g_layout.png
deleted file mode 100644
index 236e77978..000000000
Binary files a/source/images/pa_k2g_layout.png and /dev/null differ
diff --git a/source/images/pcan_view_device_selection.png b/source/images/pcan_view_device_selection.png
deleted file mode 100644
index e283cee6f..000000000
Binary files a/source/images/pcan_view_device_selection.png and /dev/null differ
diff --git a/source/images/pinmux_gpio_1.png b/source/images/pinmux_gpio_1.png
deleted file mode 100644
index ddc25867c..000000000
Binary files a/source/images/pinmux_gpio_1.png and /dev/null differ
diff --git a/source/images/pinmux_gpio_2.png b/source/images/pinmux_gpio_2.png
deleted file mode 100644
index ce868a5eb..000000000
Binary files a/source/images/pinmux_gpio_2.png and /dev/null differ
diff --git a/source/images/pinmux_save_files.jpg b/source/images/pinmux_save_files.jpg
deleted file mode 100644
index f11fc2df7..000000000
Binary files a/source/images/pinmux_save_files.jpg and /dev/null differ
diff --git a/source/images/prsdk_rtos_custom_board_porting_steps.png b/source/images/prsdk_rtos_custom_board_porting_steps.png
deleted file mode 100644
index 386c81b01..000000000
Binary files a/source/images/prsdk_rtos_custom_board_porting_steps.png and /dev/null differ
diff --git a/source/images/resume-button.png b/source/images/resume-button.png
deleted file mode 100644
index 4b77b5637..000000000
Binary files a/source/images/resume-button.png and /dev/null differ
diff --git a/source/images/sciclient_ccsLoad1.png b/source/images/sciclient_ccsLoad1.png
deleted file mode 100644
index 6ee1bc913..000000000
Binary files a/source/images/sciclient_ccsLoad1.png and /dev/null differ
diff --git a/source/images/sciclient_ccsLoad2.png b/source/images/sciclient_ccsLoad2.png
deleted file mode 100644
index eafd0e5a2..000000000
Binary files a/source/images/sciclient_ccsLoad2.png and /dev/null differ
diff --git a/source/images/sl_uart_boot_1st.jpg b/source/images/sl_uart_boot_1st.jpg
deleted file mode 100644
index 31f16b013..000000000
Binary files a/source/images/sl_uart_boot_1st.jpg and /dev/null differ
diff --git a/source/images/sl_uart_boot_2nd.jpg b/source/images/sl_uart_boot_2nd.jpg
deleted file mode 100644
index c5a7d45cc..000000000
Binary files a/source/images/sl_uart_boot_2nd.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_ccs_import.jpg b/source/images/sl_wifi_demo_ccs_import.jpg
deleted file mode 100644
index 498e0e5ea..000000000
Binary files a/source/images/sl_wifi_demo_ccs_import.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_connected.jpg b/source/images/sl_wifi_demo_connected.jpg
deleted file mode 100644
index 67da5d607..000000000
Binary files a/source/images/sl_wifi_demo_connected.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_connection.jpg b/source/images/sl_wifi_demo_connection.jpg
deleted file mode 100644
index 022f0d6ba..000000000
Binary files a/source/images/sl_wifi_demo_connection.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_overview.jpg b/source/images/sl_wifi_demo_overview.jpg
deleted file mode 100644
index ee6d5a8cd..000000000
Binary files a/source/images/sl_wifi_demo_overview.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_uart_help.jpg b/source/images/sl_wifi_demo_uart_help.jpg
deleted file mode 100644
index 804900670..000000000
Binary files a/source/images/sl_wifi_demo_uart_help.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_uart_init.jpg b/source/images/sl_wifi_demo_uart_init.jpg
deleted file mode 100644
index fb6511185..000000000
Binary files a/source/images/sl_wifi_demo_uart_init.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_uart_ping.jpg b/source/images/sl_wifi_demo_uart_ping.jpg
deleted file mode 100644
index 4b2bf8c0a..000000000
Binary files a/source/images/sl_wifi_demo_uart_ping.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_uart_scan.jpg b/source/images/sl_wifi_demo_uart_scan.jpg
deleted file mode 100644
index d557f82d1..000000000
Binary files a/source/images/sl_wifi_demo_uart_scan.jpg and /dev/null differ
diff --git a/source/images/sl_wifi_demo_uart_wlanconnect.jpg b/source/images/sl_wifi_demo_uart_wlanconnect.jpg
deleted file mode 100644
index 12d8710a0..000000000
Binary files a/source/images/sl_wifi_demo_uart_wlanconnect.jpg and /dev/null differ
diff --git a/source/images/terminate-button.png b/source/images/terminate-button.png
deleted file mode 100644
index 1b536fcc2..000000000
Binary files a/source/images/terminate-button.png and /dev/null differ
diff --git a/source/images/usb_dev_bulk_console.png b/source/images/usb_dev_bulk_console.png
deleted file mode 100644
index 70c94ee64..000000000
Binary files a/source/images/usb_dev_bulk_console.png and /dev/null differ
diff --git a/source/images/usb_dev_bulk_host_tool_output.png b/source/images/usb_dev_bulk_host_tool_output.png
deleted file mode 100644
index aa88d0167..000000000
Binary files a/source/images/usb_dev_bulk_host_tool_output.png and /dev/null differ
diff --git a/source/images/usb_device_generic_bulk_example_application.png b/source/images/usb_device_generic_bulk_example_application.png
deleted file mode 100644
index c4fea0df9..000000000
Binary files a/source/images/usb_device_generic_bulk_example_application.png and /dev/null differ
diff --git a/source/rtos/Board_EVM_Abstration.rst b/source/rtos/Board_EVM_Abstration.rst
deleted file mode 100644
index 415417f68..000000000
--- a/source/rtos/Board_EVM_Abstration.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-######################
-Board/EVM Abstration
-######################
-
-.. toctree::
-   :maxdepth: 3
-
-   index_board
-
diff --git a/source/rtos/Compilers.rst b/source/rtos/Compilers.rst
deleted file mode 100644
index b706887c6..000000000
--- a/source/rtos/Compilers.rst
+++ /dev/null
@@ -1,35 +0,0 @@
-########################
-Compilers
-########################
-
-Compiler User's Guides are located at the links below.
-
-Please refer to the Processor SDK `Release Notes <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_release_specific.html#release-notes>`__ to determine which version to use.
-
-.. _compilers-ti-c6000:
-
-*********
-TI C6000
-*********
-- `TI C6000 Compilers <http://www.ti.com/tool/C6000-CGT>`__
-
-.. _compilers-ti-arm:
-
-*******
-TI ARM
-*******
-- `TI ARM Compilers <http://www.ti.com/tool/ARM-CGT>`__
-
-.. _compilers-ti-pru:
-
-*******
-TI PRU
-*******
-- `TI PRU Compilers <http://www.ti.com/tool/PRU-CGT>`__
-
-.. _compilers-linaro-gcc-arm:
-
-***************
-Linaro GCC ARM
-***************
-- `Linaro GCC ARM Compilers <https://launchpad.net/gcc-arm-embedded>`__
diff --git a/source/rtos/Compute/_OpenMP.rst b/source/rtos/Compute/_OpenMP.rst
deleted file mode 100644
index 12bf1844a..000000000
--- a/source/rtos/Compute/_OpenMP.rst
+++ /dev/null
@@ -1,324 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/OpenMP_on_C6000
-
-.. rubric:: Introduction
-   :name: introduction
-
-As of April 2016, this article is out of date. Please visit
-`here <http://downloads.ti.com/mctools/esd/docs/openmp-dsp/index.html>`__.
-
-This page is intended to be the starting point for all information about
-OpenMP on C6000. However, at this writing, that is not the case. The
-information in this article is correct if you are using C667x devices
-which only contain C66x CorePac DSPs, and not any ARM cores. If you are
-using a 66AK2H device, then please see `MCSDK HPC 3.x
-OpenMP <http://processors.wiki.ti.com/index.php/MCSDK_HPC_3.x_OpenMP>`__. OpenMP is not supported on
-any other C6000 devices.
-
-Still here? After reading this article, you will be able to execute your
-own OpenMP code on C6000 under control of Code Composer Studio.
-
-.. rubric:: Presumptions
-   :name: presumptions
-
--  You are experienced at programming OpenMP applications on hosted
-   systems like Windows or Linux PC's.
--  You have never programmed anything on an embedded system like those
-   that use C6000 devices.
--  You have never used any TI development tools such as Code Composer
-   Studio (CCS).
-
-.. rubric:: Acronyms Used in This Article
-   :name: acronyms-used-in-this-article
-
--  CCS - Code Composer Studio. Software development environment for
-   creating code to execute on TI devices.
--  SYS/BIOS - Or BIOS for short. Scalable real-time kernel which runs on
-   the DSP.
--  MCSDK - Multicore Software Development Kit. Bundles all the software
-   supplied by TI which runs on the DSP.
-
-.. rubric:: Conceptual Overview
-   :name: conceptual-overview
-
-This section discusses, at a high level, how different pieces of
-software from TI work together to form the OpenMP solution.
-
-The OpenMP source code, at the level of OpenMP pragmas and function
-calls, is the same. Your code must be organized into a *project*, as
-that term is defined by CCS. A central element of this project is the
-SYS/BIOS configuration. SYS/BIOS (or BIOS for short) is a scalable
-real-time kernel produced by TI. BIOS implements the multi-threading
-features of OpenMP. An initial BIOS configuration (*.cfg) is supplied.
-Changing this BIOS configuration may never be required. The build is
-done within CCS. At the start, system execution is also done within CCS.
-Besides BIOS, many other software components execute on the DSP to
-comprise the OpenMP solution. All of these components are delivered
-together under the name Multicore Software Development Kit (MCSDK).
-
-.. rubric:: Installation
-   :name: installation
-
-Getting the MCSDK installed calls for you to install and configure
-everything else, so this section focuses on the MCSDK.
-
-Start with the `general download
-page <http://www.ti.com/tool/bioslinuxmcsdk>`__ for all flavors of the
-MCSDK. Follow the link for *SYS/BIOS MCSDK for C66x*. Get MCSDK version
-2.1 or later. That page includes a link to a *Getting Started Guide*.
-That is where you will find directions on hardware setup, installing
-CCS, and so on. Follow all the steps in the Getting Started Guide, up to
-Running the Demonstration Application. (Actually, go ahead and run the
-Demo if you want. But it isn't required.)
-
-.. rubric:: Confidence Test
-   :name: confidence-test
-
-If you are familiar with CCS, you may skip over this section. But,
-installing and configuring all that software may leave you wondering if
-you did it all correctly. In this section, simplify things by pretending
-your system only has one core. This allows you to check whether you have
-installed most of the software correctly, while ignoring many of the
-complicated details.
-
-Please check out `this set of Getting Started
-Guides <http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5#Getting_Started>`__
-just for CCS. You only need to go through one of them. Choose the one
-that seems best for you. These guides provide a gentle introduction to
-those who are new to CCS.
-
-When you load and run your first program, CCS needs to know which core
-to run it on. You see a dialog box similar this one:
-
-.. Image:: /images/Select_core.JPG
-
-Check the box only for core 0.
-
-.. rubric:: First OpenMP Project
-   :name: first-openmp-project
-
-This section walks through a simple hello world example project. Four
-threads run concurrently. Each thread prints hello world and the thread
-ID.
-
-.. rubric:: Version and HW Information
-   :name: version-and-hw-information
-
-This section was developed with CCS version 5.2.0.00069, MCSDK version
-2.1.0.3, and executed on an C6678 EVM. If your environment differs, you
-may have to make a few adjustments.
-
-.. rubric:: Project Setup
-   :name: project-setup
-
-In this section you create a new CCS project. This project is not
-written from scratch, but uses example source files that come with CCS.
-
-Put CCS in the Edit Perspective. Select: **Window \| Open Perspective \|
-Other \| CCS Edit**. To start this new project select: **Project \| New
-CCS Project**. Enter a **Project Name**. For **Family** select
-**C6000**. For **Variant**, ignore the first drop-down box, and in the
-second choose **Generic C66xx Device**. In the box just under **Project
-templates and examples** type in *hello*. Under *OMP Examples* you will
-see some *Hello world example* projects. Select the best one for your HW
-platform. In this screen shot, the selection is for C6678. Select
-**Next**.
-
-.. Image:: /images/Omp_h1_project_setup.jpg
-
-The next dialog shows the RTSC Configuration Settings. If only one
-version of the MCSDK is installed, then nothing more is required. If
-more than one version of the MCSDK is installed, review the version
-numbers of the selected packages and insure they are from the desired
-MCSDK. Do not forget the drop-down box at the top for the version of the
-XDCtools.
-
-Click **Finish**. CCS creates the project, complete with source code,
-and adds an entry to the **Project Explorer** window.
-
-.. rubric:: Project Modifications
-   :name: project-modifications
-
-One modification to the example project is required.
-
-In the **Project Explorer** window, expand the set of files available
-under the new project. Open the file *omp_config.cfg* by double-clicking
-on it. The edit window has two tabs on the bottom left. Select the
-**Source** tab. Find the source line which begins *var OpenMP ...*
-Change the code as follows ...
-
-::
-
-    var OpenMP = xdc.useModule('ti.omp.utils.OpenMP');    // no change
-    OpenMP.setNumProcessors(4);                           // no change
-    OpenMP.autoDnldCore = false;                          // add this line
-
-The new line disables the feature called auto-download. A side effect of
-auto-download is that printf works only on core 0.
-
-Save the change to the configuration file by entering control+S or
-selecting **File \| Save**.
-
-.. rubric:: Build and Load
-   :name: build-and-load
-
-The target configuration that should launch when this OpenMP project is
-debugged is the same one used for previous single core projects. To
-check on this detail, choose **View \| Target Configurations**. Find
-that target configuration and insure it is the default.
-
-In the **Project Explorer** window, insure the new project is selected.
-
-Select the Debug icon.
-
-.. Image:: /images/Omp_h2_debug_icon.JPG
-
-Next a dialog will come up which asks which CPU cores to load the
-program on. Select cores 0-3, then click **OK**. It will appear similar
-to this ...
-
-.. Image:: /images/Omp_h3_select_cores.JPG
-
-The following actions take place automatically:
-
--  CCS changes to the Debug perspective
--  The project is built
--  The target configuration is launched
--  The target connection is made
--  The program is loaded on cores 0-3
--  The system begins execution and runs to the start of main on core 0
-
-.. rubric:: Execute and See Output
-   :name: execute-and-see-output
-
-Now you are ready to execute. In the Debug window, click the Resume
-execution icon.
-
-.. Image:: /images/Omp_h4_resume_icon.JPG
-
-The console window will show output similar to, but not exactly the same
-as, the following ...
-
-::
-
-    [C66xx_0] Hello World from thread = 0
-    [C66xx_0] Number of threads = 4
-    [C66xx_1] Hello World from thread = 1
-    [C66xx_2] Hello World from thread = 2
-    [C66xx_3] Hello World from thread = 3
-
-Because the threads are executing on the cores concurrently, there is no
-control over the order in which the output appears. But you should see
-all of these lines.
-
-.. rubric:: Tips on System Startup
-   :name: tips-on-system-startup
-
-If things do not go smoothly, please see the article
-`SystemAnalyzerTutorial7 <http://processors.wiki.ti.com/index.php/SystemAnalyzerTutorial7>`__. That
-article is about running a tutorial for a tool named Unified
-Instrumentation Architecture (UIA). UIA is for analyzing system
-performance and behavior. This tutorial contains several tips on how to
-use CCS to run OpenMP programs. It is relevant to the versions of the
-MCSDK components listed near the beginning.
-
-.. rubric:: Second OpenMP Project
-   :name: second-openmp-project
-
-Now try another project like hello world, but a bit more complicated. It
-will serve as the basis for your future OpenMP projects.
-
-.. rubric:: Project Setup
-   :name: project-setup-1
-
-Start it the same way as the hello world project. But give it a
-different name, look for *matrix* among the examples, and choose the
-*OpenMP matrix vector multiplication example* for your system.
-
-.. Image:: /images/Omp_h5_matvec_setup.JPG
-
-.. rubric:: Build and Execute
-   :name: build-and-execute
-
-All the remaining steps are the same as with the hello world project.
-
-Upon executing, output in the console window should appear similar to
-...
-
-::
-
-    [C66xx_0]
-    [C66xx_0] Starting values of matrix A and vector b:
-    [C66xx_0]   A[0]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[0]= 1.0
-    [C66xx_0]   A[1]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[1]= 2.0
-    [C66xx_0]   A[2]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[2]= 3.0
-    [C66xx_0]   A[3]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[3]= 4.0
-    [C66xx_0]   A[4]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[4]= 5.0
-    [C66xx_0]   A[5]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[5]= 6.0
-    [C66xx_0]   A[6]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[6]= 7.0
-    [C66xx_0]   A[7]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[7]= 8.0
-    [C66xx_0]   A[8]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[8]= 9.0
-    [C66xx_0]   A[9]= 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0   b[9]= 10.0
-    [C66xx_0]
-    [C66xx_0] Results by thread/row:
-    [C66xx_0]   thread 0 did row 0   c[0]=55.00 Running total= 55.00
-    [C66xx_3]   thread 3 did row 9   c[9]=550.00    Running total= 605.00
-    [C66xx_1]   thread 1 did row 3   c[3]=220.00    Running total= 825.00
-    [C66xx_0]   thread 0 did row 1   c[1]=110.00    Running total= 935.00
-    [C66xx_1]   thread 1 did row 4   c[4]=275.00    Running total= 1210.00
-    [C66xx_2]   thread 2 did row 6   c[6]=385.00    Running total= 1595.00
-    [C66xx_0]   thread 0 did row 2   c[2]=165.00    Running total= 1760.00
-    [C66xx_1]   thread 1 did row 5   c[5]=330.00    Running total= 2090.00
-    [C66xx_2]   thread 2 did row 7   c[7]=440.00    Running total= 2530.00
-    [C66xx_2]   thread 2 did row 8   c[8]=495.00    Running total= 3025.00
-    [C66xx_0]
-    [C66xx_0] Matrix-vector total - sum of all c[] = 3025.00
-    [C66xx_0]
-
-The parts before and after *Results by thread/row* should match,
-particularly the final result of 3025.00. The *thread N* lines will
-vary, but there should be one line for each row 0-9.
-
-.. rubric:: Start Your OpenMP Project
-   :name: start-your-openmp-project
-
-Build your OpenMP project out of the matrix multiply project. In the
-**Project Explorer** window, select the matrix multiply project,
-right-click and choose **Copy**. Right-click again and choose **Paste**.
-Give the new project a name. It starts as a copy of the matrix multiply
-project in every respect, except the name. Remove files, add files, and
-make the project your own. Modifications to the omp_config.cfg file are
-not required for base functionality.
-
-.. rubric:: Debugging Tips
-   :name: debugging-tips
-
-Suppose you want to immediately execute one of those example projects
-again. You need to reset the CPU cores, reload the program, and run
-again. Here is a good way to do that.
-
-In the **Debug** window, select cores 0-3, right-click and choose
-**Group Core(s)**.
-
-.. Image:: /images/Omp_h6_group_cores.JPG
-
-Now reset the cores in the newly formed group. Select the group and
-click the **CPU Reset** icon near the top right of the **Debug** window.
-
-CPU Reset icon
-
-.. Image:: /images/Omp_h7_cpu_reset.JPG
-
-Then reload the program with the menu selection **Run \| Load \| Reload
-Program**. Now you are ready to resume execution as before. Compare with
-the output you got last time, and see how some lines are in a different
-order.
-
-.. rubric:: How to Obtain Support
-   :name: how-to-obtain-support
-
-Post your questions and suspected bugs to the `compiler
-forum <http://e2e.ti.com/support/development_tools/compiler/f/343.aspx>`__
-with the tag ``openmp``. Please use the tag. Use of the tag triggers an
-e-mail to the current support team. Without the tag, the issue may go
-unnoticed for some time.
-
diff --git a/source/rtos/DSP_Software.rst b/source/rtos/DSP_Software.rst
deleted file mode 100644
index 97e43e183..000000000
--- a/source/rtos/DSP_Software.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-######################
-DSP Software
-######################
-
-.. toctree::
-   :maxdepth: 3
-
-   index_dsp_sw
-
diff --git a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_CToolsLib.rst b/source/rtos/DSP_Software/DSP_Debug_and_Trace/_CToolsLib.rst
deleted file mode 100644
index 28f09238d..000000000
--- a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_CToolsLib.rst
+++ /dev/null
@@ -1,360 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/CToolsLib
-
-Introduction
-------------
-
-See `CToolsLib Article <http://processors.wiki.ti.com/index.php/CToolsLib_Article>`__ for a
-comprehensive article on cToolsLibs and the hardware modules supported.
-
-Overview
---------
-
--  CToolsLib is collection of embedded target APIs/library focused to
-   enable easy programmatic access to `CTools <http://processors.wiki.ti.com/index.php/CTools>`__
-   debug capabilities
--  CToolsLib purpose is provided in source code for easy integration
-   into applications
--  CToolsLib consists of several libraries
-
-AETLib
-^^^^^^
-
--  The `AETLIB <http://processors.wiki.ti.com/index.php/AETLIB>`__ library provides programmatic
-   access to the `Advanced Event
-   Triggering <http://processors.wiki.ti.com/index.php/Advanced_Event_Triggering>`__ capability on
-   64x and 64x+ processor cores.
-
-ETBLib
-^^^^^^
-
--  This library provides the ability to program and read trace data from
-   an Embedded Trace Buffer (ETB). The ETB can be used with other
-   libraries to setup and capture DSP core trace data, ARM core trace
-   data, or STM data sources.
--  In some devices each core has a dedicated ETB, while others have a
-   single ETB shared between trace sources.
--  After the ETB data is read into local memory, the user must transport
-   the binary trace data back to a host where the binary trace data can
-   be converted to text, csv or a .tdf file that can be imported into
-   CCS for display. The GettingStarted.htm file (available at
-   `[1] <http://downloads.ti.com/emulation/esd/ctoolslib/GettingStarted.htm>`__
-   )provides instructions for generating these files from utilities
-   provided with CCS.
--  The Examples projects are also a good source of information on using
-   ETBLib for different cases.
-
--  Instructions for `STM EDMA Example <http://processors.wiki.ti.com/index.php/STM_EDMA_Example>`__
-   to extend ETB using target memory
--  Instructions for `DSPTrace EDMA
-   Example <http://processors.wiki.ti.com/index.php/DSPTrace_EDMA_Example>`__ to extend ETB using
-   target memory
-
-DSPTraceLib
-^^^^^^^^^^^
-
--  This library provides the ability to programmaticly setup 64x+ DSP
-   trace export.
-
-ETMLib
-^^^^^^
-
--  The ETM Library provides the interface to configure and control
-   instruction and data tracing during program execution. A trace
-   session is defined as the time frame from the trace system getting
-   armed(enabled and waiting for a start trace condition), to the time
-   when the trace completes, either from an end trace condition that has
-   been configured or a manual call to stop tracing.
--  Developed and tested for the CortexA8 on TCI6614 and C6A816x devices.
--  The `ETMLib Examples <http://processors.wiki.ti.com/index.php/ETMLib_Examples>`__ page provides
-   instructions on how to run the examples and display the results.
-
-STMLib
-^^^^^^
-
--  This library provides "C" printf and binary APIs for hardware
-   assisted (System Trace software messages) instrumentation in your
-   code. STM messages are captured via an ETB or with an external
-   XDS560v2 System Trace receiver.
--  For instructions on setting up CCS to capture STM data see `Using
-   System Trace(STM) <http://processors.wiki.ti.com/index.php/Using_System_Trace_(STM)>`__.
-
-ITMLib
-^^^^^^
-
--  The ITMLib provides "C" string amd binary value logging APIs for TI
-   M3/M4 devices that includes an ITM module and supports SWD (Serial
-   Wire Debug) with SWO (Serial Wire Output) Trace. ITM requires at a
-   minimum CCSv5.5 and emupack 5.1.340.0 with an XDS2xx or XDS110 (Note:
-   your XDS may need a firmware update to work with "SWD with SWO
-   Trace". See your XDS vendor for firmware update instructions).
-
-CPTLib
-^^^^^^
-
--  The Common Platform Tracer modules provides profile information via
-   STM messages for critical buses within the device. CPTLib provides
-   low level CP Tracer module setup. The provided use case based helper
-   file combined with CPTLib makes for an easy to use environment. For
-   examples see `Common platform Tracer
-   Examples <http://processors.wiki.ti.com/index.php/Common_Platform_Tracer_Examples>`__. For debug
-   help see `Debugging with Common Platform
-   Tracer <http://processors.wiki.ti.com/index.php/Debugging_With_Common_Platform_Tracer>`__.
-
-cTools_UCLib
-^^^^^^^^^^^^
-
--  The cTools_UCLib is a library for Keystone family devices (C66xx,
-   TCI66xx, 66AK2Hxx, 66AK2Exx and TCI6630K2L) that consolidates the
-   most common CP Tracer and AET/DSP Trace uses cases into a single
-   library. The Library also consolidates ETB setup and operation into a
-   few easy to use functions.
-
--  Use cases supported include:
-
-   -  Exception tracking with DSP Trace
-   -  Application Program Counter Trace
-   -  Illegal Memory Access Watching with DSP Trace
-   -  CP Tracer Strategic Bus Throughput and Latency profiling
-   -  Function Statistical Profiling with DSP Trace
-
--  Keystone Ctools_UCLib examples (platform specific CCS projects) are
-   available as a separate zip package in the file repository listed
-   below.
--  Keystone Ctools_UCLib examples are also available as a part of
-   Keystone MCSDK instrumentation. For more details please refer to
-   `Keystone MCSDK instrumentation
-   examples <http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#cToolsLibrary>`__
--  For more information about Ctools use-cases, please refer to
-   Ctools_UCLib doxygen at Ctools_UCLib/doc/Ctools_UCLib.html/index.html
-
-PMICMILib
-^^^^^^^^^
-
--  The PMI and CMI units provide power and clock state profiling via STM
-   messages. The PMICMILib provides a common programming and control API
-   for both units. For more details see `OMAP4 Power and Clock
-   management
-   Profiling <http://processors.wiki.ti.com/index.php/OMAP4_Power_and_Clock_Management_Profiling>`__.
-
-Linux Kernel Driver for STM printf
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  Linux kernel module device driver enables applications to use MIPI
-   STM as a standard character device driver. Users can redirect output
-   (from printf) to a STM device, or directly write() to the STM device
-   from their application. For details and examples see `STM Linux
-   Device Driver <http://processors.wiki.ti.com/index.php/STM_Linux_Device_Driver>`__.
-
-SCILib
-^^^^^^
-
--  The OMAP44xx and OMAP54xx Statistic Collectors provides profile data
-   for SDRAM load monitoring and Master load and Latency monitoring.
-   Data is exported as STM messages. SCILib provides a use case based
-   API for configuring and controlling bus profile data for all the
-   statistic collectors on a device.
-
--  Use cases supported include:
-
-   -  Average Throughput (for SDRAM and Master SC Modules)
-   -  Link Occupancy (for SDRAM and Master SC Modules)
-   -  Average Burst Length (for SDRAM and Master SC Modules)
-   -  Average Latentcy (For Master SC Module only)
-
-Examples
---------
-
--  The CToolsLib examples package contains device or platform specific
-   CCSv5 examples, which portrays typical use case scenarios involving
-   individual or multiple CTools libraries. These examples also show how
-   to integrate various CTools libraries into one's application SW.
-
--  The following are the various supported devices or platforms:
-
-   -  Keystone1 family of devices (C667x, C665x and TCI661x)
-   -  Keystone2 family of devices (66AK2Hxx, 66AK2Exx and TCI6630K2L)
-   -  TCI648x family of devices
-   -  OMAP family of devices (OMAP44xx and OMAP54xx)
-   -  C6A816x family of devices
-   -  DRA7xx family of devices
-
-Documentation
--------------
-
--  There is a generated Doxygen API description included with each
-   CToolsLib.
-
-Download
---------
-
-All cToolsLib libraries and example source are available in the links
-below. After downloading the zips you need, simply expand each zip under
-the same top level directory. All library and example projects are
-compatible with CCSv6.
-
-+-----------------------+-----------------------+-----------------------+
-| Library               | Purpose               | File Repository       |
-+=======================+=======================+=======================+
-| GettingStarted        | Provides processor    | `GettingStarted       |
-|                       | specific notes for    | <http://downloads.ti  |
-|                       | libraries and         | .com/emulation/esd/	|
-|                       | examples              | ctoolslib/GettingStar |
-|                       |                       | ted.htm>`__           |
-+-----------------------+-----------------------+-----------------------+
-| STMLib                | Software Message      | `STMLib_5.2 <http://d |
-|                       | Library               | ownloads.ti.com/emula |
-|                       |                       | tion/esd/ctoolslib/ST |
-|                       |                       | MLib_5.2.zip>`__      |
-+-----------------------+-----------------------+-----------------------+
-| AETLib                | Software library for  | `aet_4.18 <http://dow |
-|                       | programmatically      | nloads.ti.com/emulati |
-|                       | using the 64x+ AET    | on/esd/ctoolslib/aet_ |
-|                       | hardware breakpoint   | 4.18.zip>`__          |
-|                       | and watchpoint units. |                       |
-|                       | Also useful for       |                       |
-|                       | triggering/halting    |                       |
-|                       | trace.                |                       |
-+-----------------------+-----------------------+-----------------------+
-| ETBLib                | Software Library for  | `ETBLib_1.22 <http:// |
-|                       | configuring and       | downloads.ti.com/emul |
-|                       | retrieving the ETB    | ation/esd/ctoolslib/E |
-|                       | contents.             | TBLib_1.22.zip>`__    |
-+-----------------------+-----------------------+-----------------------+
-| ETMLib                | Software Library for  | `ETMLib_0.6 <http://d |
-|                       | configuring ARM       | ownloads.ti.com/emula |
-|                       | CortexA8 Core Trace   | tion/esd/ctoolslib/ET |
-|                       | triggering.           | MLib_0.6.zip>`__      |
-+-----------------------+-----------------------+-----------------------+
-| DSPTraceLib           | Software Library to   | `DSPTraceLib_1.14 <ht |
-|                       | configure DSP Trace   | tp://downloads.ti.com |
-|                       | export                | /emulation/esd/ctools |
-|                       |                       | lib/DSPTraceLib_1.14. |
-|                       |                       | zip>`__               |
-+-----------------------+-----------------------+-----------------------+
-| cTools_UCLib          | Library that          | `Ctools_UCLib_1.5 <ht |
-|                       | configures key        | tp://downloads.ti.com |
-|                       | Keystone CP Tracer    | /emulation/esd/ctools |
-|                       | and DSP Trace Use     | lib/Ctools_UCLib_1.5. |
-|                       | Case                  | zip>`__               |
-+-----------------------+-----------------------+-----------------------+
-| PMICMILib             | Power and Clock       | `PMICMILib_1.3 <http: |
-|                       | management            | //downloads.ti.com/em |
-|                       | Instrumentation       | ulation/esd/ctoolslib |
-|                       | Library               | /PMICMILib_1.3.zip>`_ |
-|                       |                       | _                     |
-+-----------------------+-----------------------+-----------------------+
-| SCILib                | Statistic Collector   | `SCILib_1.5 <http://d |
-|                       | Instrumentation       | ownloads.ti.com/emula |
-|                       | Library               | tion/esd/ctoolslib/SC |
-|                       |                       | ILib_1.5.zip>`__      |
-+-----------------------+-----------------------+-----------------------+
-| CPTLib                | CP Tracer             | `CPTLib_0.15 <http:// |
-|                       | Instrumentation       | downloads.ti.com/emul |
-|                       | Library               | ation/esd/ctoolslib/C |
-|                       |                       | PTLib_0.15.zip>`__    |
-+-----------------------+-----------------------+-----------------------+
-| ITMLib                | Instrumentation Trace | `ITMLib_1.1 <http://d |
-|                       | Macrocell Library     | ownloads.ti.com/emula |
-|                       |                       | tion/esd/ctoolslib/IT |
-|                       |                       | MLib_1.1.zip>`__      |
-+-----------------------+-----------------------+-----------------------+
-| Examples              | CToolsLib Examples    | `Examples_5.9 <http:/ |
-|                       |                       | /downloads.ti.com/emu |
-|                       |                       | lation/esd/ctoolslib/ |
-|                       |                       | Examples_5.9.zip>`__  |
-+-----------------------+-----------------------+-----------------------+
-| Ctools_UCLib_Examples | CTools Use-Case       | `Ctools_UCLib_	|
-|                       | Library Examples      | Examples_1.3 <http://	|
-|                       |                       | downloads.ti.com/	|
-|                       |                       | emulation/esd/ctool	|
-|                       |                       | slib/Ctools_UCLib_	|
-|                       |                       | Examples_1.3.zip>`__	|
-+-----------------------+-----------------------+-----------------------+
-
-|
-
-The latest release of all libraries now come with CCS projects. Please
-refer GettingStarted.htm for more details.
-
-Trace Decoding
---------------
-
-To decoder trace from a binary dump of the ETB memory, two tools are
-avaialble:
-
-**Bin2TDF utility**
-
-Refer here for the detail on using `BIN2TDF. <http://processors.wiki.ti.com/index.php/BIN2TDF>`__
-
-**TD utility**
-
-Refer here for the detail on using
-`TD <http://processors.wiki.ti.com/index.php/TD>`__ .
-
- 
-
-Support
--------
-
--  `Support Forum - Please put CToolsLib in
-   title <http://e2e.ti.com/support/development_tools/code_composer_studio/f/81.aspx>`__
-
-.. rubric:: Frequent Asked Questions (FAQ)
-   :name: frequent-asked-questions-faq
-
-.. rubric:: Q: Can I get the source code?
-   :name: q-can-i-get-the-source-code
-
--  A: The source code is included with each library.
-
-.. rubric:: Q: How do I know if my device supports CTools?
-   :name: q-how-do-i-know-if-my-device-supports-ctools
-
--  A: The datasheet or Technical Reference Manual (TRM) will usually
-   contain details on the features support and avaialble on your device.
-   If you are unsure, you may wish to ask in the support forum.
-
-.. rubric:: Q: Do I have to use CToolsLib with `Code Composer
-   Studio <http://processors.wiki.ti.com/index.php/Code_Composer_Studio>`__?
-   :name: q-do-i-have-to-use-ctoolslib-with-code-composer-studio
-
--  A: No, other tools such as Lauterbach Trace32 can be used with the
-   CToolsLib. Please contact your tools vendor regarding support.
-
-.. rubric:: Q: Do you have approximate cycle counts for each library?
-   :name: q-do-you-have-approximate-cycle-counts-for-each-library
-
--  A: For `AETlib <http://processors.wiki.ti.com/index.php/AETlib>`__ there is a file called
-   "aetlib_profiling_stats.txt" that gives this information
--  A: For ETBLib, on the TI c6x compiler on a 64x+ device, it takes
-   approximately 1000 cycles per call at the "-o2" optimization level.
-
-.. rubric:: Q: Do you have the code size for each library?
-   :name: q-do-you-have-the-code-size-for-each-library
-
--  A: For `AETlib <http://processors.wiki.ti.com/index.php/AETlib>`__ there is a file called
-   "aetlib_size_stats.txt" that gives this information
--  A: For ETBLib, on the TI c6x compiler on a 64x+ device, it is
-   approximately 4KB at the "-o2" optimization level.
-
-.. rubric:: Q: What license is this code provided under? / Is the code
-   GPL compatible?
-   :name: q-what-license-is-this-code-provided-under-is-the-code-gpl-compatible
-
--  A: The header files in CToolsLib will have the relevant licenses.
-   Generally, CToolsLib is licnesed under modified BSD license which is
-   GPL compatible. Please see `this wikipedia
-   article. <http://en.wikipedia.org/wiki/BSD_License#3-clause_license_.28.22New_BSD_License.22_or_.22Modified_BSD_License.22.29>`__
-
-.. rubric:: Related
-   :name: related
-
--  `TI.com XDS560 Product Page <http://www.ti.com/tool/TMDSEMU560V2STM-U>`__
--  `XDS560v2 System Trace <http://processors.wiki.ti.com/index.php/XDS560v2_System_Trace>`__
--  `CTools <http://processors.wiki.ti.com/index.php/CTools>`__
--  `How OMAP software developers use System Trace to boost
-   performance <http://e2e.ti.com/blogs_/b/mobile_momentum/archive/2011/01/03/how-omap-software-developers-use-system-trace-to-boost-performance.aspx>`__
--  `Using System Trace (STM) <http://processors.wiki.ti.com/index.php/Using_System_Trace_(STM)>`__
--  Etblib Example
-   `Here <http://processors.wiki.ti.com/index.php/Capturing_ETB_Trace_Data_With_ETBLib>`__
-
diff --git a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_Fault_Management.rst b/source/rtos/DSP_Software/DSP_Debug_and_Trace/_Fault_Management.rst
deleted file mode 100644
index a3c48fe29..000000000
--- a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_Fault_Management.rst
+++ /dev/null
@@ -1,277 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_FM
-
-Introduction
-------------
-
-This section describes the Fault Management APIs and provides
-information on how to instrument a DSP image for exception. This library
-is currently supported for K2x devices only.
-
-FM DSP Exception APIs & Usage
------------------------------
-
-A DSP application can create and install an exception hook configured
-with the following features using the APIs provided by FM:
-
--  Retrieve DSP register status for a core dump
--  Halt system IO, such as DMAs
--  Inform remote DSPs an exception has occurred
--  Inform ARM/Host a DSP exception has occurred
-
-.. rubric:: Retrieving Last Register Status
-   :name: retrieving-last-register-status
-
-An exception hook function that intends to create a core dump must call
-the following API:
-
-``void Fault_Mgmt_getLastRegStatus(void);``
-
-The API stores relevant DSP core register values into the memory region
-mapped to the fault_mgmt_data data array for the core dump that is
-provided to the ARM/Host.
-
-.. rubric:: Halting System IO
-   :name: halting-system-io
-
-When a DSP exception is detected, invoking the FM instrumented exception
-hook function, system IO that offload data transfers can be stopped
-using the following API:
-
-``Fault_Mgmt_haltIoProcessing(Fm_GlobalConfigParams *fmGblCfgParams, Fm_HaltCfg *haltCfg)``
-
-The API provides the ability to disable all or subsets of the following
-system IO:
-
--  AIF2 PE (Tx) and PD (Rx) channels
--  EDMA3 DMA, QDMA, and INT channels
--  CPDMA Tx/Rx channels
--  SGMII switch
-
-The exception hook can invoke this function in order to stop DSP enabled
-IO from continuing data transfers that may wipe out data important to
-deciphering the source of the DSP exception. However, care must be taken
-to not disable resources in use by the ARM/Host. If this occurs the
-ARM/Host may experience unstable behavior preventing it from properly
-receiving and handling the DSP core dump.
-
-.. rubric:: IO Halt Configuration Parameters
-   :name: io-halt-configuration-parameters
-
-The Fm_HaltCfg structure is used to define which system IO will be
-disabled upon invocation of the IO halt API. A user can specify that an
-entire IO be disabled or a subset of an IO be disabled. The Fm_HaltCfg
-structure has the following parameters:
-
--  ``int32_t haltAif`` If set to a non-zero value, will halt all AIF2 PE
-   and PD channels except those specified within the
-   Fm_ExcludedResource's list. All AIF2 PE and PD channels will be
-   disabled if the Fm_ExcludedResource's list is NULL.
--  ``int32_t haltSGMII`` If set to a non-zero value, will halt the SGMII
-   ethernet switch.
-   **Note:** This will prevent ARM Linux ethernet from working properly.
--  ``int32_t haltEdma3`` If set to a non-zero value, will halt all EMDA3
-   DMA, QDMA, and INT channels except those specified within the
-   Fm_ExcludedResource's list. All EDMA3 DMA, QDMA, and INT channels
-   will be disabled if the Fm_ExcludedResource's list is NULL.
-   **Note:** Some EDMA3 channels are used by ARM Linux to access
-   NAND in UBIFS. UBIFS will not work correctly if these channels are
-   halted.
--  ``int32_t haltCpdma`` If set to a non-zero value, will halt all CPDMA
-   channels except those specified within the Fm_ExcludedResource's
-   list. All CPDMA channels will be disabled if the
-   Fm_ExcludedResource's list is NULL.
-   **Note:** Some CPDMA channels are used by ARM Linux which will exhibit
-   unknown behavior if the relevant CPDMA channels are halted.
--  ``Fm_ExcludedResource *excludedResources;`` List of specific system
-   IO values that should not be disabled.
-
-A customized version of the Fm_ExcludedResource's list can be created.
-However, a version has been created and supplied in
-*pdk_#_##_##_##\\packages\\ti\\instrumentation\\fault_mgmt\\device\\k2x\\src\\fm_device.c*
-which already accounts for all resources used the ARM Linux kernel
-delivered with the latest PROCSDK release.
-
-.. note::
-   Following the IO halt configuration defined in the FM test source code
-   will diable all IO except that used by ARM Linux UBIFS and NFS.
-
-.. rubric:: Informing Remote DSP Core's of Exception
-   :name: informing-remote-dsp-cores-of-exception
-
-Remote DSP cores can be informed of a DSP exception and told to halt
-functioning using the following API:
-
-``void Fault_Mgmt_notify_remote_core(uint32_t core_id);``
-
-The DSP local to the exception will interrupt remote cores via their NMI
-causing them to enter their own exception handling routine. This allows
-all DSPs to be brought down when a single DSP exception occurs. In
-multi-core application this may help preserve information relevant to
-deciphering the root cause of the original DSP exception.
-
-.. rubric:: Informing ARM/Host of DSP Exception
-   :name: informing-armhost-of-dsp-exception
-
-A DSP core can inform the ARM/Host an exception has occurred via the
-following API:
-
-``void Fault_Mgmt_notify(void);``
-
-This function will notify the ARM/Host an exception has occurred via
-Remoteproc and should be the last FM API called within the instrumented
-exception hook function.
-
-Instrumenting a DSP Application with FM Exception APIs
-------------------------------------------------------
-
-Create and install an exception hook in the DSP application that
-utilizes the DSP FM APIs.
-
--  In the .cfg (Configuro Script) file of the application add following
-   commands to create a section
-
-::
-
-    var devType = "k2?";  /* Replace k2? with the k2 device in use k2e, k2h, k2k, or k2l */
-    /* Load and use the Fault Management package */
-    var Fault_mgmt = xdc.useModule('ti.instrumentation.fault_mgmt.Settings')
-    Fault_mgmt.deviceType = devType;
-
-    /*
-     * The SysMin used here vs StdMin, as trace buffer address is required for
-     * Linux trace debug driver, plus provides better performance.
-     */
-    Program.global.sysMinBufSize = 0x8000;
-    var System = xdc.useModule('xdc.runtime.System');
-    var SysMin = xdc.useModule('xdc.runtime.SysMin');
-    System.SupportProxy = SysMin;
-    SysMin.bufSize = Program.global.sysMinBufSize;
-
-    /* Configure resource table for trace only.
-       Note that traceOnly parameter should not
-       be set if application is using MessageQ based IPC
-       to communicate between cores.
-     */
-    var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
-    Resource.loadSegment = Program.platform.dataMemory;
-    Resource.traceOnly = true;
-
-    /* Load the Exception and register a exception hook */
-    var Exception = xdc.useModule('ti.sysbios.family.c64p.Exception');
-    Exception.exceptionHook = '&myExceptionHook';
-    Exception.enablePrint = true;
-
-    /* Add note section for coredump */
-    Program.sectMap[".note"] = new Program.SectionSpec();
-    Program.sectMap[".note"] = Program.platform.dataMemory;
-    Program.sectMap[".note"].loadAlign = 128;
-
--  In a source/header file, create a exception hook function as follows
-
-.. code-block:: c
-
-    /* Fault Management Include File */
-    #include <ti/instrumentation/fault_mgmt/fault_mgmt.h>
-
-    Void myExceptionHook(Void)
-    {
-        uint32_t   i;
-        Fm_HaltCfg haltCfg;
-        uint32_t   efr_val;
-
-        /* Copy register status into fault management data region for ARM/Host */
-        Fault_Mgmt_getLastRegStatus();
-
-        memset(&haltCfg, 0, sizeof(haltCfg));
-        efr_val = CSL_chipReadEFR();
-
-        /* If triggered exception originates from another core through
-         * NMI exception don't need to halt processing and notify other cores
-         * since the parent core where the exception originally triggered via
-         * event would notify them.  This eliminates recursive exceptions */
-        if (!(efr_val & 0x80000000)) {
-            /* Halt all processing - Only need to be done on one core */
-            haltCfg.haltAif = 1;
-            haltCfg.haltCpdma = 1;
-    #if EXCLUDE_LINUX_RESOURCES_FROM_HALT
-            haltCfg.haltSGMII = 0;
-            /* EDMA used by kernel to copy data to/from NAND in UBIFS */
-            haltCfg.haltEdma3 = 0;
-            haltCfg.excludedResources = &linuxResources[0];
-    #else
-            haltCfg.haltSGMII = 1;
-            haltCfg.haltEdma3 = 1;
-            haltCfg.excludedResources = NULL;
-    #endif
-
-            Fault_Mgmt_haltIoProcessing(&fmGblCfgParams, &haltCfg);
-
-            for (i = 0; i < fmGblCfgParams.maxNumCores; i++) {
-                /* Notify remote DSP cores of exception - WARNING: This will generate NMI
-                 * pulse to the remote DSP cores */
-                if (i != CSL_chipReadDNUM()) {
-                    Fault_Mgmt_notify_remote_core(i);
-                }
-            }
-        }
-
-        /* Notify ARM/Host of crash */
-        Fault_Mgmt_notify();
-    }
-
-A sample test application is provided in
-*pdk_#_##_##_##\\packages\\ti\\instrumentation\\fault_mgmt\\test\\k2x\\c66\\bios\\fmCoreDumpK2XC66TestProject*.
-The test application uses the default resource exclusion list provided
-with FM in
-*pdk_#_##_##_##\\packages\\ti\\instrumentation\\fault_mgmt\\device\\k2x\\src*.
-The default list has been configured to exclude all Linux owned IO from
-the halting on exception. This allows the Linux kernel to remain
-operational after DSP exception so that the core dump can be processed.
-
-.. note::
-   It is recommended that the IO halt configuration defined within #if
-   EXCLUDE_LINUX_RESOURCES_FROM_HALT be used in addition to halting AIF and
-   CPDMA if Linux must remain active after a DSP exception occurs. This IO
-   halt configuration has been tested with both UBIFS and NFS. The
-   documented configuration shuts down all IO except those needed by Linux
-   to operate, such as EDMA3 (for access to NAND), the SGMII (for
-   Ethernet), and Linux owned CPPI DMAs.
-
-
-FM Global Configuration Parameters
-----------------------------------
-
-The Fm_GlobalConfigParams structure informs the IO halt and cleanup
-features of the system peripheral resource ranges that could not be
-pulled from CSL. The user should not create their own version of this
-structure. Instead, the version of the structure provided within
-*pdk_#_##_##_##\\packages\\ti\\instrumentation\\fault_mgmt\\device\\k2x\\src\\fm_device.c*
-should be used. This structure has been statically created based on
-device peripheral parameters.
-
-FM Tests
---------
-
-The Fault Management module comes with a single test application,
-fmCoreDumpK2HC66TestProject. The fmCoreDumpK2HC66TestProject forces a
-DSP exception which causes the FM core dump logic to execute. The
-example can be run from CCS or downloaded from Linux via MPM. After
-executing the application, from the Linux shell, check /var/log/syslog
-for a message saying a crash event was detected on the DSP to which the
-core dump test was loaded and run.
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------+
-| **Document**                      | **Location**                      |
-+-----------------------------------+-----------------------------------+
-| Fault Management API Reference    | $(TI_PDK_INSTALL_DIR)\\packages\\ |
-| Manual                            | ti\\instrumentation\\fault_mgmt\\ |
-|                                   | docs\\doxygen\html\index.html     |
-+-----------------------------------+-----------------------------------+
-| Fault Management Release Notes    | $(TI_PDK_INSTALL_DIR)\\packages\\ |
-|                                   | ti\\instrumentation\\fault_mgmt\\ |
-|                                   | docs\\ReleaseNotes_fault_mgmt.pdf |
-+-----------------------------------+-----------------------------------+
-
diff --git a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_Trace.rst b/source/rtos/DSP_Software/DSP_Debug_and_Trace/_Trace.rst
deleted file mode 100644
index 7c822f32f..000000000
--- a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_Trace.rst
+++ /dev/null
@@ -1,107 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_TF
-
-Overview
---------
-
-In a multicore environment there would be data generated by a producer
-in one core and would need to be consumed by multiple consumers in other
-cores/same core. For example, a target log information to be consumed by
-ARM and CCS System Analyzer.
-
-The trace framework (TF) provides a mechanism to send the information to
-multiple consumers for a given producer. In trace framework, Producer
-populates the associated Ring buffer. Consumers consume the ring buffer
-and send the data to external actual consumers (like System Analyzer in
-CCS). The hand shake between producers and consumers happen using shared
-memory area known as contract memory between producers and consumers.
-
-It is upto the consumer application to either send the data to final
-consumers (using ethernet for System Analyzer) or local consuption for
-any OAM (Operations and maintenance) features on ARM.
-
-Driver Configuration
---------------------
-
-Traceframework requires Producer, Consumer and Contract shared memory to
-be configured using tf_contractInit(), tf_contractCreate(),
-tf_prodCreate() and tf_consCreate() functions. For details about
-individual fields of this structure, see the Doxygen help by opening
-PDK_INSTALL_DIR\\Traceframeworkckages\\ti\\drv\\Traceframework\\docs\\doxygen\\html\\index.html.
-
-APIs
-----
-
-API reference for application:
-
-::
-
-    #include <ti/instrumentation/traceframework/traceframework.h>
-
-|
-
-Example
--------
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results      |
-+=======================+=======================+=======================+
-| Traceframework_UnitTe | | Unit Test           | | User observes the   |
-| stApplication         |   application to test |   output printed over |
-|                       |   all APIs            |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-
-Application Integration Details
--------------------------------
-
-**Sys BIOS DSP (C66) Use case**
-
-Reference library path to be included in application build environment:
-
-::
-
-     <ti/instrumentation/traceframework/lib/c66>
-
-
-**SysBIOS based application**
-
-Any RTSC application that needs to use trace framework library, should
-have a RTSC configuration file. Please refer to
-<ti/instrumentation/traceframework/test/TFUnitTest/<soc>/c66/bios/tfw_Uia_utest.cfg>
-sample RTSC cfg file for reference.
-
-|
-
-Additional References
----------------------
-
-+--------------------+-------------------------------------------------+
-|                 **Traceframework Library Summary**                   |
-+====================+=================================================+
-| Component Type     | Library                                         |
-+--------------------+-------------------------------------------------+
-| Install Package    | PDK                                             |
-+--------------------+-------------------------------------------------+
-| Install Directory  | pdk_keystone_<version>\\packages\\ti\\          |
-|                    | instrumentation\\traceframework                 |
-+--------------------+-------------------------------------------------+
-| Project Type       | `Eclipse RTSC <http://www.eclipse.org/rtsc/>`__ |
-+--------------------+-------------------------------------------------+
-| Endian Support     | Little                                          |
-+--------------------+-------------------------------------------------+
-| Linker Path        | $(TI_PDK_INSTALL_DIR)/packages/ti/              |
-|                    | instrumentation/traceframework                  |
-+--------------------+-------------------------------------------------+
-| Linker Sections    | .vecs , .switch, .args, .cio                    |
-+--------------------+-------------------------------------------------+
-| Include Paths      | $(TI_PDK_INSTALL_DIR)/packages/ti/              |
-|                    | instrumentation/traceframework                  |
-+--------------------+-------------------------------------------------+
-| Reference Guides   | $(TI_PDK_INSTALL_DIR)/packages/ti/              |
-|                    | instrumentation/traceframework/docs/            |
-|                    | doxygen/html/index.html                         |
-+--------------------+-------------------------------------------------+
-| Release Notes      | $(TI_PDK_INSTALL_DIR)/packages/ti/              |
-| Resources          | instrumentation/traceframework/docs/            |
-|                    | ReleaseNotes_traceframework.pdf                 |
-+--------------------+-------------------------------------------------+
-
diff --git a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_UIA.rst b/source/rtos/DSP_Software/DSP_Debug_and_Trace/_UIA.rst
deleted file mode 100644
index 1a2158a43..000000000
--- a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_UIA.rst
+++ /dev/null
@@ -1,380 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Multicore_System_Analyzer#Unified_Instrumentation_Architecture_.28UIA.29
-
-Overview
---------
-
-System Analyzer is a real-time tool for analyzing, visualizing and
-profiling application running on single or multi core systems. Data is
-collected using UIA (Unified Instrumentation Architecture) software
-instrumentation on the target and transported via Ethernet, run-mode
-JTAG, stop-mode JTAG, USB or UART to the host PC for analysis and
-visualization in Code Composer Studio.
-
-In a multi core system, data from all cores are correlated to a single
-timeline.
-
-.. Image:: /images/SA.png
-
-Unified Instrumentation Architecture (UIA)
-------------------------------------------
-
-UIA is the target-side package which defines the APIs, transports,
-interfaces and guidelines that enable developers to instrument embedded
-software in a way that is portable and flexible. It enables the creation
-of advanced tooling that can be used both in the lab and in the field.
-The framework includes:
-
--  a messaging infrastructure that allows instrumentation clients to
-   interact with instrumentation endpoints on a target device while the
-   target is running
--  an extensible set of commands and messages that can be sent over the
-   messaging infrastructure
--  protocols to be used by the target-side instrumentation framework and
-   the host-side instrumentation client
--  built-in instrumentation for DSP/BIOS for 'out of the box' real-time
-   visibility into the operation of the O/S
--  guidelines on how to instrument other RTOSes
-
-Portable and Flexible
-^^^^^^^^^^^^^^^^^^^^^
-
-System Analyzer and UIA are designed to be portable and flexible:
-
--  ISA independent: UIA can be re-used across a wide range of TI
-   platforms, single-core devices and multi-core devices
--  O/S independent: UIA not tied to any specific operating system
--  Transport independent: can use a wide variety of different transports
-   to upload software events from the target to the host, without having
-   to change the source code
--  Platform independent: Host-side tooling works on both Windows and
-   Linux platforms
--  IDE independent: Host-side tooling will support both tight
-   integration with Code Composer Studio and stand-alone operation for
-   use with other IDEs.
-
-System Analyzer together with it's UIA packages define an
-instrumentation framework that enables the development of
-instrumentation client tools, instrumented target content,
-infrastructure components, and instrumentation middleware components
-that interoperate and can be re-used across TI platforms and devices.
-
-Available Analysis
-^^^^^^^^^^^^^^^^^^
-
--  RTOS Execution Graph
--  CPU Load
--  Task Load
--  Duration Analysis
--  Context-aware Function Profiler
--  Concurrency Analysis
--  Task Profiler
--  Count/Statistical Analysis
-
-.. rubric:: Execution Graph
-   :name: execution-graph
-
-Graphical representation of RTOS context switches, events, semaphores,
-HWIs and SWIs. Start/Stop events logged for Duration Analysis and
-Enter/Exit events logged for Function Profiler are also shown in graph.
-In a multi core system all cores are shown in the same graph on the same
-timeline.
-
-.. rubric:: CPU Load
-   :name: cpu-load
-
-Graphical representation and min, max, average statistics of CPU loading
-data collected from RTOS.
-In a multi core system loading and statistics for all cores are shown.
-
-.. rubric:: Task Load
-   :name: task-load
-
-Graphical representation and min, max, average statistics of task
-loading data collected from RTOS.
-In a multi core system different instance of analysis can be opened for
-each core.
-
-.. rubric:: Duration Analysis
-   :name: duration-analysis
-
-Analyze time to perform operations. Start/Stop events logged for each
-operation is used to calculate and graph the time for each instance of
-each operation. Summary statistics (including count, min, max and
-average) is also shown for each operation.
-
-.. rubric:: Context Aware Function Profiler
-   :name: context-aware-function-profiler
-
-Min, max and average inclusive time (includes time spend in called
-functions) and exclusive time (excludes time spent in called functions)
-for functions. Functions to be profiled must have their entry and exit
-instrumented. See FAQ below on how to leverage compiler entry/exit hook
-functions. For context awareness, RTOS context switch logging must also
-be enabled.
-
-.. rubric:: Concurrency Analysis
-   :name: concurrency-analysis
-
-This is a multi-core tool to analyze parallel execution of application
-across multiple cores. RTOS Idle task is use to determine when the core
-is not in use. Task switch logging must be enabled for this analysis.
-
-.. rubric:: Task Profiler
-   :name: task-profiler
-
-The task profiler analyzes what percent of time tasks are spending in
-their different states. RTOS context switch events are required for this
-analysis.
-
-.. rubric:: Count/Statistical Analysis
-   :name: countstatistical-analysis
-
-Graphical representation of any counter/variable that is being logger.
-Also calculates number of occurrences and min, max, average value for
-each counter/variable.
-
-.. note::
-   TIRTOS/SYSBIOS instrumentation is not enabled by default.
-   See User Guide or Tutorials on how to enable this.
-
-.. note::
-   More information on the analysis features is available in the
-   `System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-Documents and Tutorials
------------------------
-
-`System Analyzer Getting Started
-Guide <http://processors.wiki.ti.com/images/7/7b/MCSA1.1_Getting_Started_Guide.pdf>`__ - Get familar
-with System Analyzer features using a data file shipped with CCStudio.
-
-`System Analyzer User's Guide <http://processors.wiki.ti.com/images/b/bc/MCSA1.1_User_Guide.pdf>`__ -
-Detail guide on configuring and using System Analyzer and UIA.
-
-`System Analyzer Tutorials
-(CCSv5) <http://processors.wiki.ti.com/index.php/System_Analyzer_Tutorials_(CCSv5)>`__ - Includes a
-series of projects that can be built and use, along with step-by-step
-walkthroughs of how to configure code, set up System Analyzer, work with
-Analysis Features, etc.
-
-System Analyzer and the MCSDK Demo
-----------------------------------
-
-System Analyzer provides visibility into the real-time behavior and
-performance of the `BIOS MCSDK
-2.0 <http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide>`__
-Image Processing Demo. The `System Analyzer and the MCSDK
-Demo <http://processors.wiki.ti.com/index.php/MCSA_and_the_MCSDK_Demo>`__
-page provides more information about how to use System Analyzer with the
-MCSDK.
-
-Known Issues/Errata
--------------------
-
-.. rubric:: CCS Crash when opening Graph in System Analyzer
-   :name: ccs-crash-when-opening-graph-in-system-analyzer
-
--  It appears that some graphics card drivers are not compatible with
-   Eclipse support for text rotation. This may result in a CCS crash
-   (inside the graphics driver) when opening graphs in System Analyzer
-   (graphs use text rotation for y-axis label). If you encounter this
-   problem, try updating the graphics card driver. This has resolved the
-   occurrences of this problem we've seen so far.
-
-.. rubric:: Multicore correlation not working
-   :name: multicore-correlation-not-working
-
--  Multicore event correlation is not automatically supported for JTAG
-   transports (it is supported for Ethernet). User can explicitly add
-   synchronization logs to enable correlation. (See `Tutorial
-   4B <http://processors.wiki.ti.com/index.php/System_Analyzer_Tutorial_4B>`__
-   for details)
--  if the target is halted (either by explict halt or implicit halts
-   such as Console I/O / CIO) while data is being collected via Ethernet
-   then correlation will not work.
--  if some target is generating data very infrequently then correlation
-   may timeout resulting in uncorrelated data. In this case the data can
-   be saved to a binary file and post process for correlation to work.
-
-.. rubric:: uia_1_00_04_35 : Tutorial 1 and Tutorial 2 do not build properly.
-   :name: uia_1_00_04_35-tutorial-1-and-tutorial-2-do-not-build-properly.
-
--  The build fails with the error *"dc.services.global.XDCException:
-   xdc.PACKAGE_NOT_FOUND: can't locate the package 'ti.sysbios.knl'"*
--  To overcome this, please unzip `UIAMetaData.zip <./images/UIAMetaData.zip>`__
-   <uia_1_00_04_35 install folder>/packages/ti/uia/runtime/ to update
-   the UIAMetaData.xs file. Then delete the <Debug> folder from your
-   project and rebuild.
-
-.. rubric:: uia_1_03_00_02 : JTAG Transport does not work properly on
-   some devices.
-   :name: uia_1_03_00_02-jtag-transport-does-not-work-properly-on-some-devices.
-
--  Project builds cleanly, System Analyzer starts normally, but no
-   events are captured.
--  To overcome this, please use
-   `uia_1_03_01_08 <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/uia/1_03_01_08/index_FDS.html>`__
-   or later.
-
-FAQs
-----
-
-.. rubric:: Q: When can I use System Analyzer auto configuration
-   :name: q-when-can-i-use-system-analyzer-auto-configuration
-
-When launching a Live or Binary File session users can choose to let
-System Analyzer auto configure itself. For this to work you must:
-
--  have a debug session running with the symbol/program file loaded
--  generated rta and uia xml file (*program*.rta.xml and
-   *program*.uia.xml) files should be located where the project
-   generated them or in the same folder as the .out file
--  if using Ethernet transport it is expected that IP address is output
-   in the console
-
-.. rubric:: Q: Configuring System Analyzer when auto configuration is
-   not possible
-   :name: q-configuring-system-analyzer-when-auto-configuration-is-not-possible
-
-See **Configuring System Analyzer Transport and Endpoints** in Chapter 4
-of the `System Analyzer User's
-Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: Q: Can I launch System Analyzer before the target if running
-   :name: q-can-i-launch-system-analyzer-before-the-target-if-running
-
-If using Ethernet transport, System Analyzer expects that the target is
-up and running and the Ethernet connection is established before it is
-started. For JTAG transport the target does not have to be running.
-
-.. rubric:: Q: What happens if the target is halted while collecting
-   data using Ethernet transport
-   :name: q-what-happens-if-the-target-is-halted-while-collecting-data-using-ethernet-transport
-
-Halting the target may result in the ethenet connection getting
-disconnected. The connection can be re-established using the **connect**
-button.
-
-.. rubric:: Q: How to Profile functions using enter and exit hook
-   functions
-   :name: q-how-to-profile-functions-using-enter-and-exit-hook-functions
-
-In order to do inclusive and exclusive profiling of functions(using
-Context Aware Profiler of System Analyzer), a UIA log is needed at the
-entry and exit point of functions. One can add entry and exit hook
-functions to every function in the source by doing the following
-
-Use the following compiler options when compiling the source
-
-::
-
-    --entry_hook=functionEntryHook
-    --entry_parm=address
-    --exit_hook=functionExitHook
-    --exit_parm=address
-
-To use the required UIA events, need this include
-
-::
-
-    #include <ti/uia/events/UIABenchmark.h>
-
-|
-Add entry and exit hook functions to the source (The below one is for
-Context aware function profiling)
-
-.. code-block:: c
-
-    void functionEntryHook( void (*addr)() ){
-        Log_write3(UIABenchmark_startInstanceWithAdrs, (IArg)"context=0x%x, fnAdrs=0x%x:",(IArg)0, (IArg)addr);
-    }
-
-    void functionExitHook( void (*addr)() ){
-        Log_write3(UIABenchmark_stopInstanceWithAdrs,  (IArg)"context=0x%x, fnAdrs=0x%x:",(IArg)0, (IArg)addr);
-    }
-
-For CCS 5.5 and later
-
-.. code-block:: c
-
-    void functionEntryHook( void (*addr)() ){
-        Log_write2(UIAProfile_enterFunctionAdrs, (IArg)0, (IArg)addr);
-    }
-
-    void functionExitHook( void (*addr)() ){
-        Log_write2(UIAProfile_exitFunctionAdrs,  (IArg)0, (IArg)addr);
-    }
-
-|
-The 1st parameter after the message string( 3rd parameter to
-Log_write3) is a context parameter (For CCS 5.5 and later is the 2nd
-parameter to Log_write2) and can be used to specify an additional
-level of qualification (e.g. Task Context). For our purpose out here
-we can ignore this and just set it to 0.
-
-If task aware profiling is needed, the Task context has to be logged.
-SYS/BIOS automatically logs events for task switches and SWI and HWI
-Start and Stop events. See Enabling and Disabling logging Sec 5.2.2 in
-the `System Analyzer User's
-Guide <http://www.ti.com/lit/pdf/spruh43>`__. Context change can also be
-explicitly logged by the application. For more on Profiling using system
-analyzer refer to Section 3.5,4.12 of the user's guide.
-
-**Profiling Results when using Libraries:** Hook functions will not be
-added and hence called from functions in libraries that have been linked
-in. This will cause the Exclusive counts of the functions making calls
-to the Library, to include the Library functions duration.
-
-Trouble Shooting
-----------------
-
-.. rubric:: System Analyzer Events or Packets are being dropped
-   :name: system-analyzer-events-or-packets-are-being-dropped
-
-See **Troubleshooting System Analyzer Connections** section in the
-`System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: No Events showing up in System Analyzer Views
-   :name: no-events-showing-up-in-system-analyzer-views
-
-See **Troubleshooting System Analyzer Connections** section in the
-`System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: System Analyzer cannot connect to the target to retrieve
-   logs
-   :name: system-analyzer-cannot-connect-to-the-target-to-retrieve-logs
-
-See **Troubleshooting System Analyzer Connections** section in the
-`System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: System Analyzer Events do not make sense
-   :name: system-analyzer-events-do-not-make-sense
-
-See **Troubleshooting System Analyzer Connections** section in the
-`System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: Time values in the logs are too large
-   :name: time-values-in-the-logs-are-too-large
-
-See **Troubleshooting System Analyzer Connections** section in the
-`System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-Technical Support and Product Updates
--------------------------------------
-
-For technical discussions and issues, please visit
-
--  `E2E Processor Support:
-   https://e2e.ti.com/support/processors/ <https://e2e.ti.com/support/processors/>`__
--  `BIOS Embedded Software forum:
-   http://e2e.ti.com/support/embedded/f/355.aspx <http://e2e.ti.com/support/embedded/f/355.aspx>`__
--  :ref:`Embedded Processors Documentation: <Index-Processor-SDK-RTOS-label>`
-
-.. note::
-   When asking for help in the forum you should tag your posts in the
-   Subject with "System Analyzer", the part number (e.g. "C6678"), and
-   component (e.g. "UIA").
-
-For product updates,
--  Use the CCS/Eclipse Update Manager (see the Getting Started Guide above)
-
diff --git a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_WDT.rst b/source/rtos/DSP_Software/DSP_Debug_and_Trace/_WDT.rst
deleted file mode 100644
index a76037fc4..000000000
--- a/source/rtos/DSP_Software/DSP_Debug_and_Trace/_WDT.rst
+++ /dev/null
@@ -1,105 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_WDT
-
-Introduction
-------------
-
-The Watchdog Timer Module provides configuration and use of the watchdog
-timer mode for the DSP local timers. The watchdog mode is a 64-bit timer
-mode for the local timers.
-
-Modes of Operation
-------------------
-
-Following modes of operations are supported
-
--  **DEFAULT_NO_OUTPUT_EVENT**: Default on system reset, WD timeout
-   causes no output event
--  **LOCAL_RESET_INPUT**: WD timeout causes local reset input to CorePac
--  **NMI_INPUT**: WD timeout causes NMI input to CorePac
--  **NMI_INPUT_PLUS_LOCAL_RESET_INPUT**: WD timeout causes an NMI input
-   followed by a local reset input. The delay between the NMI and the
-   local reset is configurable.
--  **DEVICE_RESET**: WD timeout event causes a device reset.
-
-Resets can be configured as a hard or soft reset.
-
-Driver Configuration
---------------------
-
-Watchdog Timer Configuration Structure
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The watchdog timer configuration is passed at the time of the
-WatchdogTimer_Init() function call and cannot be changed afterwards. For
-details about individual fields of the configuration structure,
-WatchdogTimer_InitCfg, see the Watchdog Timer XDC by opening
-``[PDK_INSTALL_DIR]\packages\ti\instrumentation\wdtimer\WatchdogTimer.xdc``.
-
-APIs
-^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/instrumentation/wdtimer/WatchdogTimer.h>
-
-Initialize a Watchdog Timer
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code:: c
-
-     ...
-     memset((void *)&wdCfg, 0, sizeof(WatchdogTimer_InitCfg));
-
-     wdCfg.wdPeriodLo = ...;
-     wdCfg.wdPeriodHi = ...;
-     ...
-     /* Initialize and start the timer */
-     WatchdogTimer_Init(&wdCfg);
-
-At this point the watchdog timer is enabled and running.
-
-Service Watchdog Timer
-^^^^^^^^^^^^^^^^^^^^^^
-
-The watchdog timer must be serviced prior to the configured period in
-order to avoid a timeout. The following API is used to service the
-watchdog timer, resetting the count back to zero.
-
-::
-
-    WatchdogTimer_ResetTimer()
-
-Tests
-^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results      |
-+=======================+=======================+=======================+
-| Watchdog Timer Test   | | Tests configuration | | Watchdog timer      |
-| Application           |   and expiration of   |   expires on all DSP  |
-|                       |   DSP watchdog        |   cores.              |
-|                       |   timers. Reference   |                       |
-|                       |   test for            | | See                 |
-|                       |   developers.         |   ti/instrumentation/ |
-|                       |                       |   wdtimer/test/       |
-|                       |                       |   README.t xt         |
-|                       |                       |   for more details.   |
-+-----------------------+-----------------------+-----------------------+
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------+
-| **Document**                      | **Location**                      |
-+-----------------------------------+-----------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ |
-|                                   | ti\\instrumentation\\wdtimer\\    |
-|                                   | docs\\doxygen\\html\\index.html   |
-+-----------------------------------+-----------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ |
-|                                   | ti\\instrumentation\\wdtimer\\do  |
-|                                   | cs\\ReleaseNotes_WatchdogTimer.pdf|
-+-----------------------------------+-----------------------------------+
-
diff --git a/source/rtos/DSP_Software/_DSP_Optimized_Libraries.rst b/source/rtos/DSP_Software/_DSP_Optimized_Libraries.rst
deleted file mode 100644
index ea79ce16b..000000000
--- a/source/rtos/DSP_Software/_DSP_Optimized_Libraries.rst
+++ /dev/null
@@ -1,157 +0,0 @@
-************************
-DSP Optimized Libraries
-************************
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_Libraries
-
-
-Available Libraries
-===================
-
-The table below lists currently available libraries and the
-corresponding information - whether they are included in Proc-SDK Linux
-or RTOS, supported devices, and documentation links.
-
-+-------------+-------------+-------------+-------------+---------------+
-| Library     | Proc-SDK    | Proc-SDK    | Supported   | Documentation |
-|             | Linux       | RTOS        | Devices     |               |
-+=============+=============+=============+=============+===============+
-| MATHLIB     | No          | Yes         | K1/K2/AM57x | `MATHLIB      |
-|             |             |             |             | Documentation |
-|             |             |             |             | <http://      |
-|             |             |             |             | processors.   |
-|             |             |             |             | wiki.ti.com   |
-|             |             |             |             | /index.php/   |
-|             |             |             |             | Software_li   |
-|             |             |             |             | braries#Mat   |
-|             |             |             |             | hLIB>`__      |
-+-------------+-------------+-------------+-------------+---------------+
-| DSPLIB      | No          | Yes         | K1/K2/AM57x | `DSPLIB       |
-|             |             |             |             | Documentation |
-|             |             |             |             | <http://      |
-|             |             |             |             | processors.   |
-|             |             |             |             | wiki.ti.com   |
-|             |             |             |             | /index.php/   |
-|             |             |             |             | Software_li   |
-|             |             |             |             | braries#DSP   |
-|             |             |             |             | LIB>`__       |
-+-------------+-------------+-------------+-------------+---------------+
-| IMGLIB      | No          | Yes         | K1/K2/AM57x | `IMGLIB       |
-|             |             |             |             | Documentation |
-|             |             |             |             | <http://      |
-|             |             |             |             | processors.   |
-|             |             |             |             | wiki.ti.com   |
-|             |             |             |             | /index.php/   |
-|             |             |             |             | Software_li   |
-|             |             |             |             | braries#IMG   |
-|             |             |             |             | LIB>`__       |
-+-------------+-------------+-------------+-------------+---------------+
-| LibArch     | Yes         | Yes         | C6678(RTOS) | `LibArch      |
-|             |             |             | /K2H(Linux) | User's        |
-|             |             |             | /AM572x     | Guide <http   |
-|             |             |             | (Linux)     | ://processo   |
-|             |             |             |             | rs.wiki.ti.   |
-|             |             |             |             | com/index.p   |
-|             |             |             |             | hp/Processo   |
-|             |             |             |             | r_SDK_Libra   |
-|             |             |             |             | ry_Architec   |
-|             |             |             |             | ture_and_Fr   |
-|             |             |             |             | amework>`__   |
-+-------------+-------------+-------------+-------------+---------------+
-| FFTLIB      | Yes         | Yes         | C6678(RTOS) | `FFT User's   |
-|             |             |             | /K2H(Linux) | Guide (Linux) |
-|             |             |             | /AM572x     | <http://proce |
-|             |             |             | (Linux)     | ssors.wiki.ti |
-|             |             |             |             | .com/index.ph |
-|             |             |             |             | p/MCSDK_HPC   |
-|             |             |             |             | _3.x_FFTW_Lib |
-|             |             |             |             | rary>`__      |
-|             |             |             |             |               |
-|             |             |             |             | FFT User's    |
-|             |             |             |             | Guide (RTOS): |
-|             |             |             |             | Refer to FFT  |
-|             |             |             |             | LIB folder    |
-+-------------+-------------+-------------+-------------+---------------+
-| LINALG      | Yes         | Yes         | C6678(RTOS) | `LINALG       |
-|             |             |             | /K2H(Linux) | User's        |
-|             |             |             | /AM572x     | Guide <http   |
-|             |             |             | (Linux)     | ://processo   |
-|             |             |             |             | rs.wiki.ti.   |
-|             |             |             |             | com/index.p   |
-|             |             |             |             | hp/Processo   |
-|             |             |             |             | r_SDK_Linea   |
-|             |             |             |             | r_Algebra_L   |
-|             |             |             |             | ibrary>`__    |
-+-------------+-------------+-------------+-------------+---------------+
-
-Processor SDK libraries can be categorized into two groups, general
-purpose libraries and high performance or application specific
-libraries.
-
-General Purpose Libraries
--------------------------
-
--  MATHLIB:\ `Standalone download
-   page <http://www.ti.com/tool/mathlib>`__
--  DSPLIB: `Standalone download page <http://www.ti.com/tool/sprc265>`__
--  IMGLIB: `Standalone download page <http://www.ti.com/tool/sprc264>`__
-
-These libraries are delivered with TI C66x object code and included in
-Processor-SDK ROTS. For development in Processor-SDK Linux, they can be
-downloaded from the links listed above and used in any C66x DSP code.
-
-|
-
-High Performance or Application Specific Libraries
---------------------------------------------------
-
--  `LibArch <http://processors.wiki.ti.com/index.php/Processor_SDK_Library_Architecture_and_Framework>`__:
-   Library Architecture and Framework, an abstraction layer for
-   multi-core DSP library development.
--  `FFTLIB <http://processors.wiki.ti.com/index.php/MCSDK_HPC_3.x_FFTW_Library>`__:
-   optimized library for performing fast Fourier transform.
--  `LINALG <http://processors.wiki.ti.com/index.php/Processor_SDK_Linear_Algebra_Library>`__:
-   optimized library for performing dense linear algebra computations.
-
-These libraries are available in both Processor-SDK RTOS and
-Processor-SDK Linux.
-
-Library Usage
-=============
-
-Libraries can be used in either Processor-SDK RTOS or Processor-SDK
-Linux.
-
-Using Libraries in Processor-SDK RTOS
--------------------------------------
-
-The following diagram illustrates the software stack of various
-components including libraries provided with the Processor-SDK RTOS.
-
-.. Image:: /images/Lib_sw_stack_rtos.jpg
-
-Using Libraries in Processor-SDK Linux
---------------------------------------
-
-The following diagram illustrates the software stack in Processor-SDK
-Linux environment, taking LINALG as an example. Applications access the
-libraries on the host (ARM) side, and the actual computation may be
-executed on ARM or DSP according to configuration and problem size. This
-is explained in detail in each library's documentation page.
-
-.. Image:: /images/Linalg.jpg
-
-Delivery Format
-===============
-
-All libraries are delivered with both source code and object code. The
-source code can be recompiled according to the instructions given in
-each individual library's documentation.
-
-Core benchmark comparison
-=========================
-
-Please refer to `Core Benchmarks
-<http://www.ti.com/processors/digital-signal-processors/core-benchmarks/core-benchmarks.html>`__
-for DSP vs A15 core benchmark comparison for computation intensive tasks.
-
diff --git a/source/rtos/Development_Tools/_Create_SD_Card_Linux.rst b/source/rtos/Development_Tools/_Create_SD_Card_Linux.rst
deleted file mode 100644
index 60b79bd00..000000000
--- a/source/rtos/Development_Tools/_Create_SD_Card_Linux.rst
+++ /dev/null
@@ -1,163 +0,0 @@
-Linux SD Card Creation Guide
-=============================
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_create_SD_card_script
-
-Overview
-----------
-
-The Processor SDK RTOS for AM3/AM4/AM5/K2G includes a script in the
-directory
-
-::
-
-     [SDK Install Path]\processor_sdk_rtos_<platform>_<version>\bin\
-
-named **create-sdcard.sh**. The purpose of this script is to create SD
-cards to load with images for RTOS applications.
-
-The contents of an bootable RTOS application will contain two files on
-the SD card:
-
--  **app** - Application image
--  **MLO** - Boot loader image
-
-The script will give you information about each step, but the following
-sections will go over the details and walk you through how to use the
-script as well.
-
-|
-
-What is Needed
-----------------
-
--  Access to a Linux PC
--  A valid Processor SDK RTOS for the appropriate processor installed
-   (AM335x, AM437x, AM57xx, K2G)
--  A SD card appropriate for the required hardware platform, must be 1GB
-   or larger
--  A SD card reader/writer
-
-|
-
-Creating an SD card
----------------------
-
-Invoking the Script
-^^^^^^^^^^^^^^^^^^^^
-
-The **create-sdcard.sh** script can be run from any location but must be
-run with ``root`` permissions. This usually means using the ``sudo``
-command to start execution of the script. For example:
-
-::
-
-     sudo [SDK INSTALL DIR]/bin/create-sdcard.sh [path/to/sdcard/files]
-
-The SDK comes with pre-built images that can be directly loaded on an SD
-card without having to do any builds. These are typically a
-demonstration or a Power-On Self Test (POST) application. The path for
-these files are:
-
-::
-
-     sudo [SDK INSTALL DIR]/bin/create-sdcard.sh [SDK INSTALL DIR]/prebuilt-sdcards/[EVM DIR]/sd_card_files/
-
-If you fail to execute the script with root permissions you will receive
-a message that root permissions are required and the script will exit.
-
-Select the SD Card Device
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The first step of the script will ask you to select the drive
-representing the SD card that you want to format. In most cases your
-host root file system drive has been masked off to prevent damage to the
-host system. When prompted enter the device number corresponding to the
-SD card. For example, if the output looks like:
-
-::
-
-    Availible Drives to write images to:
-
-    #  major   minor    size   name
-    1:   8       16    7761920 sdb
-
-    Enter Device Number:
-
-You would enter **1** to select the *sdb* device.
-
-For most common installations, this script works fine. However, if you
-are using more advanced disk slicing and volume management, the
-presented list of device nodes are off by one; in the best case (picking
-the last item) it will flag a range error, and in the worst case
-(anything in the middle) the wrong DASD can be destroyed. The problem
-originates when it attempts to determine the ``$ROOTDRIVE`` to "mask"
-the volume where "/" is mounted from the selection list using a
-``grep -v $ROOTDRIVE``.
-
-For the naive partitioning case, its heuristic is fine, yielding
-something like "sda" --- but for LVM, it grabs some chunk of the device
-name, e.g. "mapp" (out of "/dev/mapper/kubuntu--vg-root on / type ...").
-
-.. rubric:: Partition and Format the SD Card
-   :name: partition-and-format-the-sd-card
-
-Any partitions of the device that are already mounted will be un-mounted
-so that the device is ready for partitioning. The SD Card will then be
-partitioned and formatted into FAT32.
-
-Installing SD Card Contents
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-After the SD card is partitioned and formatted, the files under the
-path/to/sdcard/files will be installed onto the SD card, then safely
-exit the script.
-
-.. tip::
-   Once SD card is made bootable, it contains sample “MLO” and “app”
-   which can be used on the target platform.
-
-|
-
-Load Default Images to SD Card
--------------------------------
-The purpose of this section is to cover how to use the
-**create-sdcard.sh** script to populate an SD card that can be used to
-boot the device using the default images that ship with the Processor
-SDK for RTOS.
-
-For example purposes, you can use the one that is bundled in the SDK.
-The file is located in
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>/prebuilt-sdcards/<evm>/sd_card_files/
-
-For example, the default location of the image file for the GP AM57x EVM
-is
-
-::
-
-     ~/ti/processor_sdk_rtos_am57xx_2_00_00_00/prebuilt-sdcards/evmAM572x/sd_card_files/
-
-The command to load the SD card is
-
-::
-
-     sudo [SDK Install Path]/bin/create-sdcard.sh ~/ti/processor_sdk_rtos_am57xx_2_00_00_00/prebuilt-sdcards/evmAM572x/sd_card_files
-
-|
-
-Boot from SD Card
--------------------
-To boot from SD card, simply plug in the SD card to the EVM and power on
-the board. If you used the examples provided in the Processor SDK RTOS
-installer, you will see
-
--  AM335x/AM437x:
-
-.. Image:: /images/AM437x-SD-Card-Example.png
-
--  AM57x:
-
-.. Image:: /images/AM57x-SD-Card-Example.png
-
diff --git a/source/rtos/Development_Tools/_Create_SD_Card_Windows.rst b/source/rtos/Development_Tools/_Create_SD_Card_Windows.rst
deleted file mode 100644
index bc4b9362b..000000000
--- a/source/rtos/Development_Tools/_Create_SD_Card_Windows.rst
+++ /dev/null
@@ -1,210 +0,0 @@
-.. _windows-sd-card-creation-guide:
-
-Windows SD Card Creation Guide
-===============================
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Creating_a_SD_Card_with_Windows
-
-Overview
-----------
-
-This page details how to use an image file to create a bootable SD card
-for the Processor SDK RTOS for AM3/AM4/AM5/K2G. This is only required
-one time. After that, you can use Windows to delete the SD card contents
-and replace it with whatever you would like to boot.
-
-The contents of an bootable RTOS application will contain two files on
-the SD card:
-
--  **app** - Application image
--  **MLO** - Boot loader image
-
-
-.. tip::
-   If you have the SD card that came in the EVM kit, you can skip the
-   following steps to *create* a bootable SD card and simply copy your
-   SD card image files directly to the SD card.
-
-|
-
-What is Needed
-----------------
-
--  Access to a Windows PC
--  A valid Processor SDK RTOS for the appropriate processor installed
-   (AM335x, AM437x, AM57xx, K2G)
--  Software to write an image file to a SD card
--  A SD card appropriate for the required hardware platform, must be 1GB
-   or larger
--  A SD card reader/writer
-
-|
-
-Steps to Follow
------------------
-
-Here is the process to follow to create the SD card.
-
-Create a bootable SD image file
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For example purposes, you can use the one that is bundled in the SDK.
-The file is located in
-
-::
-
-     [SDK Install Path]\processor_sdk_rtos_<platform>_<version>\prebuilt-sdcards\<evm>\sd_card_img\
-
-For example, the default location of the image file for the GP AM57x EVM
-is
-``C:\processor_sdk_rtos_am57xx_2_00_00_00\prebuilt-sdcards\evmAM572x\sd_card_img\sd_card.img.gz``.
-To save installer space, this file is compressed. Once uncompressed, the
-file name will be ``boot.img``.
-
-.. rubric:: Download a disk imager program to write the image file to
-   the SD card
-   :name: download-a-disk-imager-program-to-write-the-image-file-to-the-sd-card
-
-The open source `Win32 Disk
-Imager <http://sourceforge.net/projects/win32diskimager>`__ is a good
-option.
-
-.. note::
-   This application needs to be installed with Administrative privilages.
-
-Use the software for writing an image to disk to write the .img file to the SD card
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--  Plug the SD card into the SD card reader/writer.
--  Insert the SD card reader/writer into the PC.
--  Launch the disk writer software. In the screenshots below, we are
-   using *Win32 Disk Imager*.
-
-.. Image:: /images/Win32_Disk_Imager_open.png
-
--  Choose the image file for the SDK that you want to write.
-
-.. Image:: /images/Win32_disk_imager_select_a_disk_image.png
-
--  Choose the SD card as the "Device".
--  Write the image to the SD card by click "Write". You will likely get
-   the below confirmation box. This command will overwrite whatever disk
-   you point it to, please make sure and choose the correct disk.
-
-.. Image:: /images/Win32_disk_imager_Confirm_overwrite.png
-
--  You should see the following status bar as the image is being written
-   to the disk:
-
-.. Image:: /images/Win32_Disk_Imager_writing_to_disk.png
-
--  When the write is complete, you will get the following notification:
-
-.. Image:: /images/Win32_Disk_Imager_Complete.png
-
--  You can now close the image writing program by click "Exit".
-
-Limitations to the WinDisk32 SD card utility and alternate options
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The WinDisk32 utility described in the sections above is used to format the SD card to FAT format and copy an 1GB SD card image to the SD card. While, this utility formats the SD card in FAT format recognized by all the ROM bootloader supported on Sitara and K2G devices, it limits the storage capacity of larger volume SD cards to 1 GB volume. The utility is designed to update the SD card volume information to match the size of the image copied to its volume. This can result in large portion of the volume being unused on the SD cards. You can restore the volume on the SD card using linux based SD formatting utilities. This section describes some options to the WinDisk32 utility that we have tested with the ROM bootloader on devices supported in Processor SDK.
-
-
-**SDcard.org Formatter Utility**
-
-
-K2G and AM437x users, can use the formatting utility provided by SDCard.org for booting an SD card on TI evaluation platforms. This utility formats the SD cards in a way by which it retains the original size and also in a format recognized by the ROM bootloader.
-
-.. note:: This utility is not compatible with AM335x and AM57xx devices due the FAT format restrictions in the ROM bootloader on those devices.
-
-You can follow the instructions provide below:
-
-1. Download `SD Card Formatter 4.0 for SD/SDHC/SDXC <https://www.sdcard.org/downloads/formatter_4/>`_ from the internet.
-
-2. Insert the SD card into a USB based or similar SD card reader/writer on the host Windows system.
-
-3. Run the SD Card Formatter 4.0 for SD/SDHC/SDXC Portable executable. The executable should automatically detect the SD card plugged via reader as a new 'removable disk' and populate the drive corresponding to the removable disk. Else you will need to manually point it to the new disk.
-
-.. Image:: /images/SDFormatter_screenshot.png
-
-4. Choose default settings (as shown above)if it is new SD card and Click on 'Format'. For previously used SD cards, you can choose "FULL" by clicking on Options menu to erase and format the SD card.
-
-5. You should see a pop up window that indicates progress of the formatting tool. The Quick format option usually takes a few seconds. The following message will be displayed when the formatting is completed.
-
-.. Image:: /images/SDF_Format_complete.png
-
-6. Copy the MLO (boot loader) to the formatted SD Card.
-
-7. Rename application boot binary as "app" and copy it to SD Card.
-
-8. You can now insert the SD card in the TI evaluation platform and boot the platform in SD boot.
-
-.. Note:: Bootmode switches are set for MMC/SD boot. See the `Hardware User's Guide <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_release_specific.html#supported-platforms-and-versions/>`_ for the evaluation platform for details.
-
-
-**HP USB Disk Storage Format Tool v2.0.6 (works with AM335x and AM437x devices)**
-
-
-For AM335x and AM437x users, you can opt to use HP USB Disk Storage Format Tool v2.0.6. This allows users to format the SD cards without modifying its volume and also uses a FAT32 format that is recognized by the ROM bootloader. However this utility may use FAT12 format for smaller volume(<4GB) SD cards.
-
-You can follow the instructions provide below:
-
-1. Download `HP USB Disk Storage Format Tool v2.0.6 Portable <https://www.google.co.in/search?q=HP+USB+Disk+Storage+Format+Tool+v2.0.6&hl=en&source=hp&gbv=2&gs_sm=e&gs_upl=1235l14547l0l16813l14l12l1l0l0l0l297l2500l0.4.7l11l0&safe=active&oq=HP+USB+Disk+Storage+Format+Tool+v2.0.6&aq=f&aqi=g3&aql=&gws_rd=ssl/>`_ from the internet.
-
-2. Choose a SD card and a USB based or similar SD card reader/writer. Plug it to a Windows host system.
-
-3. Run the HP USB Disk Storage Format Tool v2.0.6 Portable executable. The executable should automatically detect the SD card plugged via reader as a new 'removable disk'. Else point it to the new disk.
-
-4. Choose FAT32 if the SD card size is greater that 4GB. Else FAT should be good to go.
-
-5. Click "Format."
-
-6. Copy the MLO (boot loader) to the formatted SD Card.
-
-7. Rename application binary as "app" and copy it to SD Card.
-
-8. Make sure that TI evaluation platform bootmode switches are set for MMC/SD boot. See the `Hardware User's Guide <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_release_specific.html#supported-platforms-and-versions/>`_  for the evaluation platform for details.
-
-9. Attach the SD card to IDK MMC/SD Card slot and switch on TI evaluation platform.
-
-
-**Use the SD card creation script on Linux platform (works with all platforms)**
-
-
-This method works with all the platforms. However, this method requires the PDK installation on Linux and using the SD card creation script provided in the installer. Please refer to the `Linux SD Card Creation Guide <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#linux-sd-card-creation-guide>`_ for details.
-
-|
-
-.. rubric:: Safely eject the SD card from the computer
-   :name: safely-eject-the-sd-card-from-the-computer
-
-| Here's an example using Windows 7:
-
-.. Image:: /images/Win7_eject_disk.png
-
-.. Image:: /images/Win7_eject_disk_detail.png
-
-.. Image:: /images/Win7_device_can_be_safely_removed.png
-
-|
-
-.. note::
-   Once SD card is made bootable with Win32 disk imager, it contains sample
-   “MLO” and “app” which can be used on the target platform.
-
-|
-
-Boot from SD Card
--------------------
-
-To boot from SD card, simply plug in the SD card to the EVM and power on
-the board. If you used the examples provided in the Processor SDK RTOS
-installer, you will see
-
--  AM335x/AM437x:
-
-.. Image:: /images/AM437x-SD-Card-Example.png
-
--  AM57x:
-
-.. Image:: /images/AM57x-SD-Card-Example.png
-
diff --git a/source/rtos/Development_Tools/_PSDK_RTOS_Top_level_Makefile.rst b/source/rtos/Development_Tools/_PSDK_RTOS_Top_level_Makefile.rst
deleted file mode 100644
index 71d8fbc57..000000000
--- a/source/rtos/Development_Tools/_PSDK_RTOS_Top_level_Makefile.rst
+++ /dev/null
@@ -1,319 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Building_The_SDK#Top-Level_Makefile
-
-.. rubric:: Overview
-   :name: overview
-
-The Processor SDK comes with pre-built libraries for everything you need
-to start writing an application. However, you may want to customize and
-rebuild from source. Inside the SDK there is a top-level Makefile that
-can be used to build some of the sub-components found within the SDK.
-Prior to calling this Makefile, run the provided script/batch file to
-setup your host environment variables. For components not covered by
-this top-level Makefile, please see guides within the respective
-component for build instructions.
-
-The Makefile and environment setup script are found in the RTOS SDK
-directory:
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/
-
-The default SDK Install Path is ``C:\ti`` for Windows and
-``/home/[user]/ti`` for Linux.
-
-The pre-requisite compilers are provided in Code Compose Studio, see the
-`CCS installation section of the Getting Started
-Guide <index_overview.html#code-composer-studio>`__.
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-If you have installed the SDK and/or CCS in non-default locations follow
-the steps outlined in the article
-`Processor SDK RTOS Install In Custom Path <index_how_to_guides.html#update-environment-when-installing-to-a-custom-path>`__
-to build the SDK from the toplevel Makefile.
-
-.. raw:: html
-
-   </div>
-
-|
-
-.. rubric:: Setup Environment
-   :name: setup-environment
-
-.. rubric:: Command
-   :name: command
-
-The SDK build environment can be configured on Windows and Linux by
-running an environment setup script located in the top-level RTOS SDK
-folder.
-
-.. rubric:: Windows
-   :name: windows
-
-From the RTOS SDK directory, enter
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]> setupenv.bat
-
-which will configure the Windows command shell environment for the
-installed RTOS SDK.
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-
--  You must re-run this batch file any time you open a new terminal.
--  Script also sets CCS installation path using TOOLS_INSTALL_PATH
-   variable so set the variable if you are not using default CCS install
-   path
-
-.. raw:: html
-
-   </div>
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]>setupenv.bat
-     Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-     REQUIRED for xdc release build
-     Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
-     Optional parameter not configured : DOXYGEN_INSTALL_PATH
-     REQUIRED for xdc release build
-     Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
-     **************************************************************************
-     Environment Configuration:
-         PDK Directory             : /ti/PDK_AM~3/packages/
-         CGTOOL INSTALL Directory  : C:/ti/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-         TOOLCHAIN A15 Directory   : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-         TOOLCHAIN A8 Directory    : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-         TOOLCHAIN A9 Directory    : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-         TOOLCHAIN M4 Directory    : C:/ti/ccsv6/tools/compiler/ti-cgt-arm_[version]
-         FPULIB_PATH               : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-         CROSS_TOOL_PRFX           : arm-none-eabi-
-         XDC_INSTALL_PATH          : C:/ti/xdctools_[version]_core
-         BIOS_INSTALL_PATH         : C:/ti/bios_[version]
-         IPC_INSTALL_PATH          : C:/ti/ipc_[version]
-         EDMA3LLD_BIOS6_INSTALLDIR : C:/ti/edma3_lld_[version]
-         NDK_INSTALL_PATH          : C:/ti/ndk_[version]
-         IMGLIB_INSTALL_PATH       : C:/ti/imglib_c66x_[version]
-         UIA_INSTALL_PATH          : C:/ti/uia_[version]
-         PROC_SDK_INSTALL_PATH     : C:/ti/processor_sdk_rtos_[soc]_[version]
-     **************************************************************************
-     Changing to short name to support directory names containing spaces
-     current directory: C:/ti/processor_sdk_rtos_[soc]_[version]
-     PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-     **************************************************************************
-
-|
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-The warnings of optional parameters not configured can be ignored since
-we are only rebuilding the libraries and not generating a release
-package.
-
-.. raw:: html
-
-   </div>
-
-.. rubric:: Linux
-   :name: linux
-
-From the RTOS SDK directory, enter
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh
-
-which will configure the Linux shell environment for the installed RTOS
-SDK.
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc>]_[version]$ source setupenv.sh
-     Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-     REQUIRED for xdc release build
-     Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
-     Optional parameter not configured : DOXYGEN_INSTALL_PATH
-     REQUIRED for xdc release build
-     Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
-     **************************************************************************
-     Environment Configuration:
-         PDK Directory             : /home/[user]/ti/pdk_[soc]_[version]/packages
-         CGTOOL INSTALL Directory  : /home/[user]/ti/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-         TOOLCHAIN A15 Directory   : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-         TOOLCHAIN A8 Directory    : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-         TOOLCHAIN A9 Directory    : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-         TOOLCHAIN M4 Directory    : /home/[user]/ti/ccsv6/tools/compiler/ti-cgt-arm_[version]
-         FPULIB_PATH               : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-         CROSS_TOOL_PRFX           : arm-none-eabi-
-         XDC_INSTALL_PATH          : /home/[user]/ti/xdctools_[version]_core
-         BIOS_INSTALL_PATH         : /home/[user]/ti/bios_[version]
-         IPC_INSTALL_PATH          : /home/[user]/ti/ipc_[version]
-         EDMA3LLD_BIOS6_INSTALLDIR : /home/[user]/ti/edma3_lld_[version]
-         NDK_INSTALL_PATH          : /home/[user]/ti/ndk_[version]
-         IMGLIB_INSTALL_PATH       : /home/[user]/ti/imglib_c66x_[version]
-         UIA_INSTALL_PATH          : /home/[user]/ti/uia_[version]
-         PROC_SDK_INSTALL_PATH     : /home/[user]/ti/processor_sdk_rtos_[soc]_[version]
-
-     PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-     *******************************************************************************
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-The warnings of optional parameters not configured can be ignored since
-we are only rebuilding the libraries and not generating a release
-package.
-
-.. raw:: html
-
-   </div>
-
-.. rubric:: Top-Level Makefile
-   :name: top-level-makefile
-
-The SDK level makefile can be used to compile SDK sub-components after
-the build environment has been configured. The following sections cover
-the Makefile found in the top-level of the Processor SDK for RTOS.
-
-.. rubric:: Target Types
-   :name: target-types
-
-For each of the targets discussed below the following target type are
-defined:
-
--  **<target>** - This is the build target which will compile the
-   release version of the component
-
--  **<target>_clean** - This target will clean the component
-
-.. rubric:: Top-Level Targets
-   :name: top-level-targets
-
-The Processor SDK for RTOS provides the following targets by default
-which will invoke the corresponding component targets:
-
--  **help** - This will print target information defined in the Makefile
-
--  **all** - This will call the build target for each component defined
-   in the Makefile
-
--  **clean** - This will call the clean target for each component
-   defined in the Makefile
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-Invoking build using "all" option in SDK top level for multicore SOC
-parts can take up to several hours to rebuild as the components need to
-be built for all cores (e.g., A15, C66x, M4). Please rebuild individual
-components in the PDK package for these devices to avoid long build
-times.
-
-.. raw:: html
-
-   </div>
-
-.. rubric:: Common Targets
-   :name: common-targets
-
-The following targets are common to all Processor SDKs for RTOS:
-
--  **pdk** - Builds the Platform Development Kit that includes CSL and
-   low level drivers
-
-.. rubric:: Additional Targets
-   :name: additional-targets
-
-You can find the list of all the targets by invoking **help** target as
-described above. Depending on the capabilities and software available
-for a given device additional targets may also be defined:
-
--  **demo** - Builds demonstrations provided in the SDK
--  **ipc_bios** - Builds the IPC component provided in the SDK
--  **ipc_examples** - Builds the IPC examples provided in the IPC
-   component
-
-|
-
-.. rubric:: Usage Examples
-   :name: usage-examples
-
-The following examples demonstrate how to use the top-level Makefile for
-some common tasks. All of the examples below assume that you are calling
-the Makefile from the top-level of the SDK.
-
-.. rubric:: Windows
-   :name: windows-1
-
--  Build all
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]> gmake
-
--  Clean all
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]> gmake clean
-
-.. rubric:: Linux
-   :name: linux-1
-
--  Build all
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc]_[version]$ make
-
--  Clean all
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc]_[version]$ make clean
-
-|
-
-.. rubric:: Rebuilding Components
-   :name: rebuilding-components
-
-Instructions for rebuilding sub-components can be found in documentation
-within the component. Here are a collection of useful pages:
-
--  `Rebuild
-   IPC <index_Foundational_Components.html#rebuilding-ipc>`__
-   *(Starting in Release 3.0, IPC build has been integrated into the
-   top-level SDK Makefile.)*
-
--  `Rebuild
-   NDK <http://processors.wiki.ti.com/index.php/Rebuilding_The_NDK_Core_Using_Gmake>`__
-
--  `Rebuild PDK <index_how_to_guides.html#rebuild-drivers-from-pdk-directory>`__
-
--  `Rebuild
-   SYS/BIOS <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__
-
-|
-
diff --git a/source/rtos/Device_Drivers.rst b/source/rtos/Device_Drivers.rst
deleted file mode 100644
index 049391de7..000000000
--- a/source/rtos/Device_Drivers.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-######################
-Device Drivers
-######################
-
-.. toctree::
-   :maxdepth: 5
-
-   index_device_drv
-
-
diff --git a/source/rtos/Documentation_Tarball.rst b/source/rtos/Documentation_Tarball.rst
deleted file mode 100644
index ada3c64c3..000000000
--- a/source/rtos/Documentation_Tarball.rst
+++ /dev/null
@@ -1,18 +0,0 @@
-###############################
-Documentation Tarball
-###############################
-
-Please click the link below to download a snapshot of the entire documentation in HTML format.
-
-.. raw:: html
-
-    <a href="processor-sdk-rtos-docs.tar.gz">Download processor-sdk-rtos-docs.tar.gz</a>
-
-Unpack the tarball using the command below:
-
-::
-
-    tar -xzvf processor-sdk-rtos-docs.tar.gz
-
-Then, you can open the landing page (processor-sdk-rtos-docs-[version]/rtos/index.html) in
-a browser to browse the content.
diff --git a/source/rtos/Examples_and_Demonstrations.rst b/source/rtos/Examples_and_Demonstrations.rst
deleted file mode 100644
index b68a704c7..000000000
--- a/source/rtos/Examples_and_Demonstrations.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. _index-examples-demos:
-
-############################
-Examples and Demonstrations
-############################
-
-.. toctree::
-   :maxdepth: 3
-
-   index_examples_demos
diff --git a/source/rtos/Examples_and_Demonstrations/_AUDK2G_AddOn.rst b/source/rtos/Examples_and_Demonstrations/_AUDK2G_AddOn.rst
deleted file mode 100644
index cade04434..000000000
--- a/source/rtos/Examples_and_Demonstrations/_AUDK2G_AddOn.rst
+++ /dev/null
@@ -1,121 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_AUDK2G_AddOn
-
-.. rubric:: Introduction
-   :name: introduction
-
-This page describes the unit test for the Audio Daughter Card for K2G
-(AUDK2G) AddOn provided in the Processor-SDK for RTOS. This unit test
-implemented the audio loopback between the ADC_IN1-4 to DAC_OUT1-4 on
-AUDK2G.
-
-The key functions in this unit test include:
-
--  Use board library to initialize the K2G EVM
--  Setup the PinMux for K2G EVM and the AUDK2G
--  Allocate the data buffers needed
--  Initialize the McASP and EDMA
--  Start the infinite loop for continious loopback
-
-This unit test utilizes other Processor SDK features/components:
-
--  **Board Library** for K2G platform initialization
--  **AUDK2G Library** for PinMux, McASP/EDMA setups
-
-Currently, the following device and EVM are supported:
-
--  K2G, on the K2G EVM with AUDK2G
-
-|
-
-.. rubric:: Requirements
-   :name: requirements
-
-The following materials are required to run this unit test:
-
-Hardware
-
--  K2G EVM
--  Audio Daughter Card (AUDK2G)
-
-Software
-
--  Processor-SDK RTOS (3.2 or greater)
--  Code Composer Studio 6.1.3
-
-|
-
-.. rubric:: How to Build the Unit Test
-   :name: how-to-build-the-unit-test
-
-.. rubric:: K2G EVM
-   :name: k2g-evm
-
-**For Linux:**
-
--  Under pdk_k2g_<version>/packages directory, run the following
-   commands:
-
-::
-
-      source pdksetupenv.sh
-      cd pdk_k2g_<version>/packages/ti/addon/aud/
-      make clean
-      make all
-
--  The OUT file (audioAnalogLoopbackTest.out) for DSP will be built at
-   pdk_k2g_<version>/packages/ti/addon/aud/test/analog/loopback/build/make
-
-**For Windows:**
-
--  Under pdk_k2g_<version>\\packages directory, run the following
-   commands:
-
-::
-
-      pdksetupenv.bat
-      cd pdk_k2g_<version>\packages\ti\addon\aud\
-      gmake clean
-      gmake all
-
--  The OUT file (audioAnalogLoopbackTest.out) for DSP will be built at
-   pdk_k2g_<version>\\packages\\ti\\addon\\aud\\test\\analog\\loopback\\build\\make
-
-.. rubric:: How to Run the Unit Test
-   :name: how-to-run-the-unit-test
-
-The unit test works on the K2G EVM with an AUDK2G connected.
-
-The following section provide detailed steps for K2G EVM
-
--  Follow this link `Processor SDK RTOS Setup CCS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__
-   to get target configuration setup correctly
--  Connect to the on board emulator (J1 on K2G EVM) to your PC USB
--  Plug power adaptor(12V) into the K2G EVM and power on the EVM
--  Launch the target configuration file using "Launch Selected
-   Configuration" from CCS 6.1.3
--  Then "Connect to C66xx_DSP"
--  Load the audioAnalogLoopbackTest.out from
-   pdk_k2g_<version>/packages/ti/addon/aud/test/analog/loopback/build/make
--  Run the program (loaded previously) by pressing F8
--  The program will print out the instructions on how to verify the
-   loopback physically
-
-::
-
-      [C66xx]
-      ******************************************
-            Audio DC Analog Loopback Test
-      ******************************************
-
-      Test Verifies ADC and DAC Channels 0 to 3
-      Test Runs in Audio Loopback Mode
-      Confirm that ADC Input Audio is Played at DAC Channels 0 to 3
-
-      Audio Connection Details
-      **************************************
-      ADC_IN 0 ==> DAC_OUT 0
-      ADC_IN 1 ==> DAC_OUT 1
-      ADC_IN 2 ==> DAC_OUT 2
-      ADC_IN 3 ==> DAC_OUT 3
-      **************************************
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Audio_Benchmark_Starterkit.rst b/source/rtos/Examples_and_Demonstrations/_Audio_Benchmark_Starterkit.rst
deleted file mode 100644
index 1753b5955..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Audio_Benchmark_Starterkit.rst
+++ /dev/null
@@ -1,615 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Audio_Benchmark_Starterkit
-
-Introduction
-============
-
-The Audio Benchmark Starterkit is intended to provide an easy and quick
-way to benchmark key audio functions on C66x and C674x DSP devices. This
-package is intended for users who are new to the TI DSP development
-environment and provides an easy path to compare core audio benchmarks
-to other implementations. For the purposes of benchmarking we have
-selected the following signal processing functions
-
--  Complex Fast Fourier transform (FFT)
--  Real Block FIR filters with 128 samples, 16 coefficients
--  Cascaded Biquad (2 channels, 3 stages) IIR filter for 128 Samples
-
-The package is also a great way to get familiar with benchmarking
-functions on TI DSP with or without TI`s Code Composer Studio
-environment. It also intends to provide guidance on the compiler options
-and code/data memory placement that allows developers to obtain optimal
-performance on TI DSP architecture. The package also demonstrates use of
-signal processing functions from TI C6000 DSPLIB which contains several
-kernels optimized for TI DSP architectures.
-
-Software Features
-=================
-
--  Benchmark applications for core signal processing functions
--  Makefile and CCS Project scripts to build applications
--  SD card bootable binaries [Supported on SOCs that support SD boot]
-
-Directory Structure
-===================
-
-The audio benchmark starterkit is located in the Processor SDK RTOS
-release under the directory path
-
-::
-
-    <SDK_INSTALL_PATH>\processor_sdk_rtos_<soc>_x_xx_xx_xx\demos\audio-benchmark-starterkit
-
-|
-| The directory structure for the audio benchmark starterkit is shown in
-  the image below.
-
-Detailed description of the directory structure is given below:
-.. Image:: /images/Audben_dirStructure.png
-
--  prebuilt-binaries - directory contains prebuilt out files to run the benchmarks.
--  bootimages - SD card boot files to run the benchmarks using SD boot.
--  docs - directory contains ReadMe, Quick start guide and the software manifest for the package.
--  scripts - directory contains .txt script files that is used by BenchmarkProjectCreate
-   script to create CCS projects
--  src
-   -  common - Contains linker command file and logging functions used by all benchmark tests.
-   -  singlePrecision_FFT - Source files for benchmark app for FFT
-   -  singlePrecision_FIR - Source files for benchmark app for FIR
-   -  singlePrecision_IIR - Source files for benchmark app for IIR
-
-Software Dependencies
-=====================
-
--  `Processor SDK RTOS v3.3 and later <index_overview.html#processor-sdk-for-rtos>`__
--  `Code Composer Studio IDE Environment v7 and later <index_overview.html#code-composer-studio>`__
-
-.. note::
-   For correct version of Code Composer Studio to download, please refer
-   to the :ref:`Release Notes <processor-sdk-rtos-release-notes>`
-   corresponding to the Processor SDK RTOS version that you have
-   installed
-
-Supported Hardware
-==================
-
-**Platforms supported in Processor SDK RTOS 3.3 and later**
-
--  `K2G EVM <http://www.ti.com/tool/EVMK2G>`__
--  `AM572x GP EVM <http://www.ti.com/tool/tmdsevm572x>`__
--  `AM571x IDK <http://www.ti.com/tool/TMDXIDK5718>`__
-
-**Platforms planned in Processor SDK RTOS 4.0**
-
--  `OMAPL138/C6748 LCDK <http://www.ti.com/tool/tmdslcdk6748>`__
--  `K2H EVM rev 1.1 and
-   later <http://www2.advantech.com/Support/TI-EVM/EVMK2HX.aspx>`__
--  `K2E EVMs rev 1.0.2.0 and
-   later <https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html>`__
--  `C6678 EVM <http://www.ti.com/tool/tmdsevm6678>`__
--  `C6657 EVM <http://www.ti.com/tool/tmdsevm6657>`__
-
-QuickStart with How-To-Video
-============================
-
-For an easy and visual experience to build and run the benchmark tests,
-we have created a short How to video that demonstrates how the Benchmark
-Starterkit can be built and run on C66x DSP on the K2G EVM which you can
-check out from the link provided below:
-
--  `Demonstration of Audio Benchmark starterkit demo on 66AK2G02 GP
-   EVM <https://training.ti.com/66ak2gx-gp-evm-audio-benchmark-starter-kit-demo>`__
-
-How to Build the Benchmarks
-===========================
-
-The benchmark starterkit is designed to build with makefiles as well as
-with Code Composer Studio (CCS) IDE Environment. Both the approaches
-requires developers to setup the Processor SDK RTOS development
-environment. Developers can use either approach based on their
-familiarity with the chosen build environment. Let us take a closer look
-at both approaches.
-
-Using Makefile
---------------
-
-**Step1 : Setup Processor SDK RTOS build Environment.**
-
-Developers are required to setup the Processor SDK RTOS build
-environment as described in :ref:`Processor SDK RTOS Setup environment <Build-The-SDK-Setup-Environment-label>`
-
-#. **set SDK_INSTALL_PATH = C:\\ti\\<Install directory>**
-#. **setupenv.bat**
-
-.. note::
-   If developers install CCS or Processor SDK RTOS under Custom path then
-   they need to refer to the setup instructions described under
-   :ref:`Setup environment when installing to a custom path <Processor-SDK-RTOS-Install-In-Custom-Path-label>`
-
-|
-**Step2 : Invoke Make from root directory**
-
-The make file in the root director of the audio-starterkit can be used
-to build the entire package. To build the benchmark examples:
-
-#. **cd <PROC_SDK_INSTALL_PATH>/demos/audio-benchmark-starterkit**
-#. **make all**
-
-.. note::
-   The build picks up the SOC information from the SDK setup. Also, in the
-   make environment the benchmark application is built to send benchmark
-   logs to UART console so that there is no dependency on the CCS IDE
-   environment
-
-|
-For Other supported options, please type
-
-**For Windows:**
-
-::
-
-    gmake help
-
-**For Linux :**
-
-::
-
-    make help
-
-All available options are provided below:
-
-.. Image:: /images/Make_help.png
-
-Using CCS Projects
-------------------
-
-The audio benchmark starterkit does not provide pre-canned CCS Projects
-as it is difficult to set up projects to be portable across various
-developer build environments. To create CCS Projects with the
-benchmarks, developers are required to run the BenchmarkProjectCreate
-script provided in the root directory of the starterkit.
-
-**Step1 : Setup Processor SDK RTOS build Environment.**
-
-#. **set SDK_INSTALL_PATH = C:\\ti\\<Install directory>**
-#. **set TOOLS_INSTALL_PATH = C:\\ti\\<CCS Install directory>**
-#. **setupenv.bat**
-
-.. note::
-   CCS by default is installed in the path C:\\ti\\ccsv7 so
-   TOOLS_INSTALL_PATH=C:\\ti
-
-Developers are required to setup the Processor SDK RTOS build
-environment as described in :ref:`Processor SDK RTOS Setup environment <Build-The-SDK-Setup-Environment-label>`
-
-.. note:: If developers install CCS or Processor SDK RTOS under a Custom path
-   then they need to refer to the setup instructions described under :ref:`Setup
-   environment when installing to a custom path
-   <Processor-SDK-RTOS-Install-In-Custom-Path-label>`
-
-|
-
-**Step 2: Run BenchmarkProjectCreate script to generate CCS Projects**
-
-To generate the CCS Projects
-
-#. **cd $PROC_SDK_INSTALL_PATH/demos/audio-benchmark-starterkit**
-#. **BenchmarkProjectCreate [Options]**
-
-The Project create script can be run using the following syntax
-
-::
-
-     BenchmarkProjectCreate.bat <soc> <board> <all>
-
-Description of arguments:
-
--  **soc** - **K2G (Default)** / K2H/ K2E/ C6678/ C6657/ AM572X/ AM571x/
-   OMAPL138
--  **board** - **all (Default)** / <SOC supported EVMs>
--  **module** - **all** / (FFT / FIR / IIR)
-
-::
-
-    Example:
-     a) BenchmarkProjectCreate.bat
-                 - Creates all module projects for the K2G soc for evmK2G platform
-     b) BenchmarkProjectCreate.bat AM572x
-                 - Creates all module projects for AM572x soc for evmAM572x and idkAM572x platform
-     c) BenchmarkProjectCreate.bat C6657 evmC6657
-                 - Creates all modules for C6657 DSP for evmC6657 platform
-     d) BenchmarkProjectCreate.bat K2H evmK2H FFT
-                 - Creates FFT module project for K2H soc for evmK2H
-
-.. note::
-   **Known issue with Processor SDK RTOS 3.3**
-   The BenchmarkProjectCreate script uses text files .txt from scripts
-   folder to generate the CCS projects. The name for the demo folder was
-   updated from "audio-benchmark-kit" to "audio-benchmark-starterkit". This
-   will require CCS users to update the name in the .txt file before
-   generating the scripts.
-
-   For Example if you are using K2G platform locate file
-   Benchmark_FFT_evmK2G_c66ExampleProject.txt,
-   Benchmark_FIR_evmK2G_c66ExampleProject.txt and
-   Benchmark_IIR_evmK2G_c66ExampleProject.txt and update the demo name in
-   the text files from "audio-benchmark-kit" to
-   "audio-benchmark-starterkit"
-
-**Step 3: Import Generated CCS Projects in CCS Workspace**
-
-Launch CCS and Import the CCS Project using the Project->Import Existing
-CCS Project and browse to the audio-benchmark-starterkit folder
-
-.. Image:: /images/CCS_Project_Browse.png
-
-**Step 4: Build Imported CCS Benchmark Projects**
-
-Right click on the Benchmark Project File and Build the project as shown
-below:
-
-.. Image:: /images/Build_Benchmark.png
-
-How to Run the Benchmarks
-=========================
-
-The benchmark examples can be run by loading the built out files with an
-emulator using the CCS Debug functionality or the examples can be run on
-the DSP by creating SD card bootable images using out files. Let us take
-a look at both these approaches.
-
-Using CCS
----------
-
-**Step 1: Connect Emulator and UART to Hardware**
-
--  Refer to the :ref:`Hardware Setup guide <RTOS-SDK-Supported-Platforms>`
-   and connect the onboard or external emulator to the Hardware and Host
-   machine with CCS installed.
-
--  Connect the UART cable from the EVM to the Host machine and configure
-   the Serial console with following settings:
-
-   -  **Baud Rate**: 115200
-   -  **Data Bits**: 8
-   -  **Parity**: None
-   -  **Flow Control**: Off
-
-**Step 2: Create Target configuration and connect to the DSP**
-
-To connect to the SOC, developers need to create a Target configuration
-by following the procedure described in wiki
-:ref:`Create_Target_Configuration_File_for_EVM <Create-Target-Configuration-File-for-EVM-label>`
-
-|
-Instructions specific to supported EVMs:
-
--  `K2G GP EVM CCS
-   Setup <http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup#Connect_without_a_SD_card_boot_image>`__
--  `AM572x GP EVM CCS
-   Setup <http://processors.wiki.ti.com/index.php/AM572x_GP_EVM_Hardware_Setup#Connect_without_a_SD_card_boot_image>`__
-
-.. note::
-   Please refer to :ref:`Hardware User Guide <RTOS-SDK-Supported-Platforms>`
-   corresponding to each supported EVM so setup the boot switches to No
-   boot if available
-
-|
-**Step 3: Loading and Running Benchmark application on the DSP**
-
--  Load the out file using **Run -> Load -> Load Program** and browse to
-   the output binary.
--  After loading the out file, run the benchmark app by Pressing **F8**
-   or **Run -> Resume**
-
-|
-
-Using SD card (Supported only on AM57xx and K2G)
-------------------------------------------------
-
-**Step 1: Run Create SD script to generate SD bootable binaries**
-
-The root directory in the audio-benchmark-starterkit contains a
-create-sd.bat file that will convert the .out files installed int the
-bin folder into SD bootable images which will be installed in the path
-bin/sd_card_files/<EVM>
-
-The syntax to run the create-sd script is as follows:
-
-::
-
-    create-sd.bat <EVM>
-
-**EVM** : refers to evaluation platfom on which the binaries are meant
-to be run
-
-Eg: create-sd evmK2G - Creates SD bootable images for K2G EVM.
-
-**Step 2 : Format and copy the SD card binaries to the SD card**
-
-Create an SD card using the procedure described in :ref:`Creating SD card in Windows <Tools-Create-SD-Card-Windows-label>`
-and :ref:`Create SD card in Linux <Tools-Create-SD-Card-Linux-label>`
-
-Copy the "MLO" and "Singleprecision_<Module>_app" to the boot partition
-on the SD card.
-
-**Step 3: Boot the Benchmark app by configuring SD boot on the EVM**
-
--  Configure the boot switches on the evaluation hardware to SD boot.
--  Insert the SD card in the microSD or SD card slot on the board.
--  Connect the UART on the hardware to the Host and configure the host
-   to **Baud Rate**\ = 115200, **Data Bits**\ = 8 , **Parity**\ = None,
-   **Flow Control**\ = Off
--  Power on the EVM to view the output on the Serial console on the host
-
-Benchmark App output on UART console
-====================================
-
-.. Image:: /images/FFTbenchmark_sdBoot.png
-
-Benchmark Starterkit Implementation
------------------------------------
-
-.. rubric:: Signal Processing functions used in Starterkit
-   :name: signal-processing-functions-used-in-starterkit
-
-.. rubric:: Single Precision FFT: DSPF_sp_fftSPxSP (Mixed Radix Forward
-   FFT )
-   :name: single-precision-fft-dspf_sp_fftspxsp-mixed-radix-forward-fft
-
-The audio benchmark kit uses the FFT implementation(DSPF_sp_fftSPxSP)
-from the `TI DSP
-Library <http://processors.wiki.ti.com/index.php/Software_libraries#DSPLIB>`__.
-The DSPF_sp_fftSPxSP kernel calculates the discrete Fourier transform of
-complex input array ``ptr_x`` using a mixed radix FFT algorithm. The
-result is stored in complex output array ``ptr_y`` in normal order. Each
-complex array contains real and imaginary values at even and odd
-indices, respectively. DSPF_sp_fftSPxSP kernel is implemented in
-assembly to maximize performance, but a natural C implementation is also
-provided. The demonstration app for this kernel includes the required
-bit reversal coefficients, ``brev``, and additional code to calculate
-the twiddle factor coefficients, ``ptr_w``.
-
-|
-
-.. note::
-   -  For implementation details of this FFT computation refer to
-      documentation provided in `Additional resources <index_examples_demos.html#additional-resources>`__
-   -  For Real input sequences, efficient FFT Implementation is described
-      here
-      `Efficient_FFT_Computation_of_Real_Input <http://processors.wiki.ti.com/index.php/Efficient_FFT_Computation_of_Real_Input>`__
-
-.. rubric:: Single Precision FIR: DSPF_sp_fir_cplx (Complex FIR Filter)
-   :name: single-precision-fir-dspf_sp_fir_cplx-complex-fir-filter
-
-The audio benchmark kit uses the FFT implementation(DSPF_sp_fftSPxSP)
-from the `TI DSP
-Library <http://processors.wiki.ti.com/index.php/Software_libraries#DSPLIB>`__.
-The DSPF_sp_fir_cplx kernel performs complex FIR filtering on complex
-input array x with complex coefficient array h. The result is stored in
-complex output array y. For each complex array, real and imaginary
-elements are respectively stored at even and odd index locations.
-
-The API reference and the implementation details can found in the TI
-DSPLIB documentation included in the Processor SDK.
-
-.. rubric:: Single Precision IIR : tisigCascadeBiquadSP_2c_3s_kernel
-   (Cascade Biquad Filter for Multichannel input)
-   :name: single-precision-iir-tisigcascadebiquadsp_2c_3s_kernel-cascade-biquad-filter-for-multichannel-input
-
-The Cascade biquad filtering function in the audio benchmark starterkit
-is an improved biquad infinite impulse response filter `Patent
-US20160112033
-Pending <http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1=20160112033.PGNR.>`__.
-The new filter structure modifies the feedback path in the filter,
-resulting in a significant reduction in execution cycles. One of the
-most-used digital filter forms is the biquad. A biquad is a second order
-(two poles and two zeros) Infinite Impulse Response (IIR) filter. It is
-high enough order to be useful on its own, and because of the
-coefficient sensitivities in higher order filters the biquad is often
-used as the basic building block for more complex filters. For instance,
-a biquad low pass filter has a cutoff slope of 12 dB/octave, useful for
-tone controls; if a 24 dB/octave filter is needed, you can cascade two
-biquads and it will have less coefficient sensitivity problems than a
-single fourth-order design.
-
-For implementation details please check the `USTO
-link <http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1=20160112033.PGNR.>`__
-
-API reference:
-
-::
-
-    int tisigCascadeBiquad32f_2c_3skernel(CascadeBiquad_FilParam *pParam)
-
-where CascadeBiquad_FilParam is defined as
-
-.. code-block:: c
-
-     CascadeBiquad_FilParam {
-          float *restrict pin1;    // Input Data Channel 1
-          float *restrict pin2;    // Input Data Channel 2
-          float  *restrict pOut1;  // Output Data Channel 1
-          float  *restrict pOut2;  // Output Data Channel 1
-          float  *restrict pCoef;  // Filter Coefficients a, b for 3 stages
-          float  *restrict pVar0;  // Filter Variables d0, d1 for 3 stages channel 0
-          float  *restrict pVar1;  // Filter Variables d0, d1 for 3 stages channel 1
-          int      sampleCount;    // Number of samples
-     }  CascadeBiquad_FilParam;
-
-Memory placement of Instruction and Data
-========================================
-
-The best performance of the DSP can be obtained by placing all the data
-and instructions in L2 SRAM. Please refer to the linker command files
-include in the src/common folder to see how the instructions and data
-can be place in DSP internal L2 memory.
-
-.. note::
-   In application use cases where audio data needs to be place in onchip
-   shared memory (OCMC or MSMC) and DDR memory, we recommend that users
-   move data from external memory to L2 for processing using EDMA or enable
-   DSP cache using CSL to optimize performance.
-
-Compiler Optimization Flags
-===========================
-
-All the projects in the Audio Benchmark starterkit are built using C6000
-compiler with -o3 optimization that allows the source code to be
-compiled with highest compiler optimization settings. User can refer to
-the compiler Build settings in the Makefiles or go to Build Settings in
-CCS Project settings to modify the compiler options.
-
-|
-
-.. note::
-   For more Details on recommended C6000 Compiler options refer
-   `C6000_Compiler:_Recommended_Compiler_Options <http://processors.wiki.ti.com/index.php/C6000_Compiler:_Recommended_Compiler_Options>`__
-
-   -  C6000 compiler documentation: `C6000 Compiler v8.x User
-      Guide <http://www.ti.com/lit/ug/sprui04a/sprui04a.pdf>`__
-
-SOC Integration and Optimization
-================================
-
-Configuring device clocks
--------------------------
-
-Every SOC with TI DSP requires users to enable the DSP clocks by setting
-up the PLL and or enabling the DSP through Power Sleep Controller or
-Power and Control (PRCM) module. The way the clocks are set up differs
-depending on the environment setup
-
--  **Development environment with emulator:**\ In this case the SOC
-   clocks are setup using GEL files which are added to the target
-   configuration file. For audio benchmark starterkit, this done using
-   GEL files setup explained in the Hardware Setup section
-
--  **Application Boot from boot media**\ If you are booting application
-   from a boot media like SD/MMC or flash device, the ROM bootloader or
-   a secondary level bootloader performs the clock configuration. For
-   audio starterkit, this initialization is done using board library
-   which is linked to the secondary bootloader and the benchmark tests.
-
-.. note::
-   If the clocks are not configured the DSP will run at speed of the input
-   clock rather than at the device speed grade. Hence if the clocks are not
-   configured correctly the benchmarks will run much slower than
-   anticipated but the cycle count will show the same.
-
-Benchmarking using DSP TSCH/TSCL registers
-==========================================
-
-For C66x+ and C674x members of the C6000 family, there is a pair of
-registers, TSCL and TSCH, which together provide a 64-bit clock value.
-You can create your own clock function to take advantage of these
-registers. Simply add this function to your program and it will override
-the clock function from the library.
-
-The Bench mark test application, use the following functions to capture
-cycle count using the TSCH and TSCL regsiters.
-
-.. code-block:: c
-
-           /* ---------------------------------------------------------------- */
-           /* Initialize timer for clock */
-           TSCL= 0,TSCH=0;
-           /* Compute the overhead of calling _itoll(TSCH, TSCL) twice to get timing info */
-           /* ---------------------------------------------------------------- */
-           t_start = _itoll(TSCH, TSCL);
-           t_stop = _itoll(TSCH, TSCL);
-           t_overhead = t_stop - t_start;
-
-
-           t_start = _itoll(TSCH, TSCL);
-           <Algorithm to be bechmarked>
-           t_stop = _itoll(TSCH, TSCL);
-           t_measured = (t_stop - t_start) - t_overhead;
-
-Benchmark logging
-=================
-
-The Audio benchmarks demonstrates two ways to log benchmark numbers. One
-approach that can be used when code is loaded and run from Code composer
-studio is to use standard printf messages from the standard IO RTS
-libraries and the other approach is to use UART based logging that can
-send the benchmark logs to serial console on the host at the baud rate
-of 115.2 kbps.
-
-All the benchmark test application include a file Benchmark_log.h and
-Benchmark_log.c, that are used to log messages based on the definition
-of macro **IO_CONSOLE**. If IO_CONSOLE is defined the output will be
-directed to CCS console. If it is not defined, the logs are sent to the
-UART console.
-
-Makefiles and scripts that build binaries to boot from SD card will not
-have IO_CONSOLE defined hence the benchmark logs will be directed to the
-UART serial console. In the CCS projects, we define the IO_CONSOLE macro
-so that the output can be observed on the CCS console.
-
-Cache configuration for Code/data sections in SRAM/DDR
-======================================================
-
-The best performance of the DSP can be obtained by placing all the data
-and instructions in L2 SRAM. If developer application use cases places
-audio data in onchip shared memory (OCMC or MSMC) and DDR memory then
-the user will need to enable L1 and L2 cache using CSL API.
-
-To enable and utilize cache in the application, please refer to the
-csl_cacheAux.h file in the pdk_<soc>_x_x_x/packages/ti/csl folder in the
-SDK and link the CSL library for the soc into the application code.
-
-Benchmark results
-=================
-
-+-----------------------+-----------------------+-----------------------+
-| Algorithm\DSP         | C66x DSP              | C674x DSP             |
-| Architecture          |                       |                       |
-+=======================+=======================+=======================+
-| Single Precision FFT  | 1808 cycles           | 2314 cycles           |
-| (256 samples)         |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-| Single Precision FIR  | 2652 cycles           | 4465 cycles           |
-| (128 samples, 16      |                       |                       |
-| coefficients)         |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-| Single Precision IIR  | 8258 cycles           | 12381 cycles          |
-| (1k samples from 2    |                       |                       |
-| channel with 3 stage  |                       |                       |
-| cascade biquad)       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-
-.. note::
-
-   -  All code and data for the benchmark tests is placed in L2 Memory.
-   -  C6000 compiler version used was CGTools v8.1.3
-   -  Bench marks were obtained from C66x DSP on K2G and C674x DSP on
-      OMAPL138 LCDK
-   -  FFT and FIR benchmarks were obtained using the DSPLIB functions.
-
-Support
-=======
-
-For questions, feature requests and bug reports, please use the TI E2E
-Forum provided below:
-
--  `E2E Processor Support
-   <https://e2e.ti.com/support/processors/>`__
-
-Additional resources
-====================
-
-**White papers:**
-
--  `Introduction to TMS320C6000 DSP
-   Optimization <http://www.ti.com/lit/an/sprabf2/sprabf2.pdf>`__
--  `TI DSP
-   Benchmarking <http://www.ti.com/lit/an/sprac13/sprac13.pdf>`__
--  `Optimizing Loops on
-   C66x <http://www.ti.com/lit/an/sprabg7/sprabg7.pdf>`__
--  `TI’s new TMS320C66x fixed and floating-point DSP core conquers the
-   ‘Need for Speed’ <http://www.ti.com/lit/wp/spry147/spry147.pdf>`__
--  `Efficient fixed- and floating-point code execution on the
-   TMS320C674x core delivers faster code development and reduces system
-   cost with improved
-   performance <http://www.ti.com/lit/wp/spry127/spry127.pdf>`__
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Audio_Pre_Processing.rst b/source/rtos/Examples_and_Demonstrations/_Audio_Pre_Processing.rst
deleted file mode 100644
index bca667901..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Audio_Pre_Processing.rst
+++ /dev/null
@@ -1,460 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Audio_Pre-Processing
-
-Introduction
-============
-
-This page describes the audio pre-processing for speech recognition
-framework provided in the Processor-SDK for RTOS. This demo illustrates
-the integration of Beamforming (BF), Adaptive Spectral Noise Reduction
-(ASNR), Multiple Source Selection (MSS) and Dynamic Range Compression
-(DRC) components and provides a framework for application development.
-
-.. Image:: /images/Aud_pre_processing_arch.png
-
-The key functions in this use case include:
-
--  Read 7 canned audio input files from hard drive into buffers in DDR
-   using GEL function
--  Generate 12 virtual mics using BF (Beamforming) (30° apart)
--  Apply ASNR (Adaptive Spectral Noise Reduction) on each virtual mic
--  Use MSS (Multiple Source Selection) to select the best virtual mic
-   from the 12 virtual mics
--  Do DRC (Dynamic Range Compression) on the best virtual mic
--  Display performance data
--  Write one processed audio channel from buffer in DDR to hard drive
-   using GEL function
-
-This demo utilizes other Processor SDK features/components:
-
--  **SYS/BIOS** application utilizing TI-RTOS features for
-   DSP-C66x/C674x core
--  **UIA** for instrumentation logging
-
-The audio components are available in AER and VOLIB packages, which are
-optimized for C66x cores, so this demo not available for all devices.
-Currently, the following devices and EVMs are supported:
-
--  AM57x, on the AM572x GP EVM
--  K2G, on the K2G EVM. See TIDEP-0088
-   (http://www.ti.com/tool/TIDEP-0088) for details
--  OMAP-L137, on the OMAP-L137 EVM. See TIDEP-0099
-   (http://www.ti.com/tool/TIDEP-0099) for details
-
-|
-
-Requirements
-============
-
-The following materials are required to run this demonstration:
-
-Hardware
-
--  TI EVMs (see list above)
--  CMB for K2G and OMAP-L137, if using circular microphone
--  Blackhawk USB560 JTAG Emulator (BH-USB-560m)
-
-Software
-
--  Processor-SDK RTOS (4.0 or greater)
--  Code Composer Studio
--  AER 17.0.0.0 (C64P) (http://www.ti.com/tool/telecomlib)
--  VOLIB 2.1.0.1(C64P for OMAP-L137, C66 for K2G and AM572x)
-   (http://www.ti.com/tool/telecomlib)
-
-|
-
-Software Design
-===============
-
-More about processing algorithms
---------------------------------
-
-The application will use AER & VOLIB APIs for its noise reduction
-processing needs. The following steps are performed for noise reduction:
-
--  Use 7 canned audio inputs to generate 12 virtual mics using
-   BF(Beamforming) (30° apart)
--  Apply ASNR(Adaptive Spectral Noise Reduction) on each virtual mic
--  Use MSS(Multiple Source Selection)to select the best virtual mic from
-   the 12 virtual mics
--  Do VAD(Voice Activity Detection) on the best virtual mic
--  Write 1 processed audio channel into the buffer in DDR
-
-Framework for Audio Pre-processing
-----------------------------------
-
-The current framework is based on SYS/BIOS. The following are the
-overall steps:
-
--  The CLK object in SYS/BIOS will be configured to generate a Software
-   Interrupt(SWI) every 10 ms
--  The SWI will prepare the audio frame buffer pointers for further
-   processing
--  The SWI will also send a semaphore to wake up the main thread
--  When woke up, the main thread will perform the BF, ASNR, MSS and DRC
--  The main thread will also output the final processing audio frame to
-   the DDR
--  After completed the audio frame processing, the main thread will wait
-   on semaphore for next audio frames to come
-
-|
-
-File Based Demo
-===============
-
-How to Build the Demo
----------------------
-
-.. note::
-   In order to make the following build procedure to work, AER and VOLIB
-   have to be installed at the same location as the Processor SDK RTOS
-   and make sure the AER 17.0.0.0 (C64P) is installed at aer_c64Px_obj_17_0_0_0
-
-
-AM572x GP EVM
-^^^^^^^^^^^^^
-
-**For Linux:**
-
--  Under processor_sdk_rtos_am57xx_4_xx_xx_xx directory, run the
-   following commands:
-
-::
-
-      source ./setupenv.sh
-      make audio_preproc_clean
-      make audio_preproc
-      the OUT files for DSP1 will be built at
-         processor_sdk_rtos_am57xx_4_xx_xx_xx/demos/audio-preprocessing/file_demo_bios/am572x/build
-
-**For Windows:**
-
--  Under processor_sdk_rtos_am57xx_4_00_xx_xx directory, run the
-   following commands:
-
-::
-
-      setupenv.bat
-      gmake audio_preproc_clean
-      gmake audio_preproc
-      the OUT files for DSP1 will be built at
-         processor_sdk_rtos_am57xx_4_xx_xx_xx\demos\audio-preprocessing\file_demo_bios\am572x\build
-
-K2G EVM
-^^^^^^^
-
-**For Linux:**
-
--  Under processor_sdk_rtos_k2g_4_xx_xx_xx directory, run the following
-   commands:
-
-::
-
-      source ./setupenv.sh
-      make audio_preproc_clean
-      make audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_k2g_4_xx_xx_xx/demos/audio-preprocessing/file_demo_bios/k2g/build
-
-**For Windows:**
-
--  Under processor_sdk_rtos_k2g_4_00_xx_xx directory, run the following
-   commands:
-
-::
-
-      setupenv.bat
-      gmake audio_preproc_clean
-      gmake audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_k2g_4_xx_xx_xx\demos\audio-preprocessing\file_demo_bios\k2g\build
-
-OMAP-L137 EVM
-^^^^^^^^^^^^^
-
-**For Linux:**
-
--  Under processor_sdk_rtos_omapl137_4_xx_xx_xx directory, run the
-   following commands:
-
-::
-
-      source ./setupenv.sh
-      make audio_preproc_clean
-      make audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_omapl137_4_xx_xx_xx/demos/audio-preprocessing/file_demo_bios/omapl137/build
-
-**For Windows:**
-
--  Under processor_sdk_rtos_omapl137_4_xx_xx_xx directory, run the
-   following commands:
-
-::
-
-      setupenv.bat
-      gmake audio_preproc_clean
-      gmake audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_omapl137_4_xx_xx_xx\demos\audio-preprocessing\file_demo_bios\omapl137\build
-
-How to Run the Demo
--------------------
-
-The demo along with the audio input files will be loaded onto the target
-using JTAG. After executing, the output file can be read from target.
-Play both input and output audio files to compare effect of audio
-pre-processing.
-
-The following sections provide detailed steps for each EVM.
-
-AM572x GP EVM
-^^^^^^^^^^^^^
-
--  Follow this link :ref:`Processor-SDK-RTOS-Setup-CCS-label`
-   to get target configuration setup correctly.
--  Then in CCS tools --> Gel file to load the modified gel file --
-   audio-preprocessing/file_demo_bios/am572x/files_io_7.gel
--  Connect the Blackhawk USB 560M JTAG to P4 on AM572x GP EVM
--  Plug power adaptor(12V) into the AM572x GP EVM (Do not press the
-   Power Button(S1) yet)
--  Launch the target configuration created in step 1 using "Launch
-   Selected Configuration" from CCS 6.1.3
--  Press the Power Button(S1) and "Connect to CortexA15_0" immediately
-   (Due to the EVM will be auto power off in 10 secs)
--  Then "Connect to C66xx_DSP1"
--  Load the AM572x_bf.out from
-   audio-preprocessing\\file_demo_bios\\am572x\\build
--  Execute GEL function Scripts-->Microphone Load
-   Functions-->BFMicLoadAll to load all 7 microphone input files
-   (audio-preprocessing\\common\\t8\\y16L7g3m7090_x.pcm) into external
-   memory buffers
--  Run the program (loaded previously) by pressing F8
--  The program will print out the statistics and “EOF reached” when the
-   program completes processing
--  Execute GEL function Scripts-->Microphone Save
-   Functions-->BFSaveOutput to save the processed audio output from
-   external memory buffer to a file
-   (audio-preprocessing\common\t8\fileOutput7.bin)
-
-K2G EVM
-^^^^^^^
-
--  Follow this link :ref:`Processor-SDK-RTOS-Setup-CCS-label`
-   to get target configuration setup correctly.
--  Then in CCS tools --> Gel file to load the modified gel file --
-   audio-preprocessing/file_demo_bios/k2g/files_io_7.gel
--  Connect to the on board emulator (J1 on K2G EVM) to your PC USB
--  Plug power adaptor(12V) into the K2G EVM and power on the EVM
--  Launch the target configuration created in step 1 using "Launch
-   Selected Configuration" from CCS 6.1.3
--  Then "Connect to C66xx_DSP"
--  Load the K2G_bf.out from audio-preprocessing\\file_demo_bios\\k2g\\build
--  Execute GEL function Scripts-->Microphone Load
-   Functions-->BFMicLoadAll to load all 7 microphone input files
-   ((audio-preprocessing\\common\\t8\\y16L7g3m7090_x.pcm)) into external
-   memory buffers
--  Run the program (loaded previously) by pressing F8
--  The program will print out the statistics and “EOF reached” when the
-   program completes processing
--  Execute GEL function Scripts-->Microphone Save
-   Functions-->BFSaveOutput to save the processed audio output from
-   external memory buffer to a file
-   (audio-preprocessing\\common\\t8\\fileOutput7.bin)
-
-OMAP-L137 EVM
-^^^^^^^^^^^^^
-
--  Follow this link :ref:`Processor-SDK-RTOS-Setup-CCS-label`
-   to get target configuration setup correctly.
--  Then in CCS tools --> Gel file to load the modified gel file --
-   audio-preprocessing/file_demo_bios/k2g/files_io_7.gel
--  Connect to the on board emulator (J201 on OMAP-L137 EVM) to your PC
-   USB
--  Plug power adaptor(5V) into the OMAP-L137 EVM and power on the EVM
--  Launch the target configuration created in step 1 using "Launch
-   Selected Configuration" from CCS 6.1.3
--  Then "Connect to C674x_0"
--  Load the DA830_bf.out from
-   audio-preprocessing\\file_demo_bios\\omapl137\\build
--  Execute GEL function Scripts-->Microphone Load
-   Functions-->BFMicLoadAll to load all 7 microphone input files
-   ((audio-preprocessing\\common\\t8\\y16L7g3m7090_x.pcm)) into external
-   memory buffers
--  Run the program (loaded previously) by pressing F8
--  The program will print out the statistics and “EOF reached” when the
-   program completes processing
--  Execute GEL function Scripts-->Microphone Save
-   Functions-->BFSaveOutput to save the processed audio output from
-   external memory buffer to a file
-   (audio-preprocessing\\common\\t8\\fileOutput7.bin)
-
-|
-
-|
-
-Circular Microphone Board Demo
-==============================
-
-How to Build the Demo
----------------------
-
-.. note::
-   In order to make the following build procedure to work, AER and VOLIB
-   have to be installed at the same location as the Processor SDK RTOS
-   and make sure the AER 17.0.0.0 (C64P) is installed at aer_c64Px_obj_17_0_0_0
-
-K2G EVM
-^^^^^^^
-
-**For Linux:**
-
--  Under processor_sdk_rtos_k2g_4_xx_xx_xx directory, run the following
-   commands:
-
-::
-
-      source ./setupenv.sh
-      make audio_preproc_clean
-      make audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_k2g_4_xx_xx_xx/demos/audio-preprocessing/realtime_demo_bios/k2g/build
-
-**For Windows:**
-
--  Under processor_sdk_rtos_k2g_4_00_xx_xx directory, run the following
-   commands:
-
-::
-
-      setupenv.bat
-      gmake audio_preproc_clean
-      gmake audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_k2g_4_xx_xx_xx\demos\audio-preprocessing\realtime_demo_bios\k2g\build
-
-OMAP-L137 EVM
-^^^^^^^^^^^^^
-
-**For Linux:**
-
--  Under processor_sdk_rtos_omapl137_4_xx_xx_xx directory, run the
-   following commands:
-
-::
-
-      source ./setupenv.sh
-      make audio_preproc_clean
-      make audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_omapl137_4_xx_xx_xx/demos/audio-preprocessing/realtime_demo_bios/omapl137/make
-
-**For Windows:**
-
--  Under processor_sdk_rtos_omapl137_4_00_xx_xx directory, run the
-   following commands:
-
-::
-
-      setupenv.bat
-      gmake audio_preproc_clean
-      gmake audio_preproc
-      the OUT files for DSP will be built at
-         processor_sdk_rtos_omapl137_4_xx_xx_xx\demos\audio-preprocessing\realtime_demo_bios\omapl137\make
-
-How to Run the Demo
--------------------
-
-The demo works with the real time audio input from CMB. After processing
-is complete, the audio output will be sent to the line-out(left channel)
-of the K2G EVM on-board audio codec. For the purpose of comparison, the
-unprocessed center microphone (mic 8) will be sent out to the line-out
-(right channel) of the K2G EVM on-board audio codec.
-
-The following sections provide detailed steps for each EVM.
-
-K2G EVM (using CCS)
-^^^^^^^^^^^^^^^^^^^
-
--  Follow this link :ref:`Processor-SDK-RTOS-Setup-CCS-label`
-   to get target configuration setup correctly.
--  Connect to the on board emulator (J1 on K2G EVM) to your PC USB
--  Plug power adaptor(12V) into the K2G EVM and power on the EVM
--  Launch the target configuration created in step 1 using "Launch
-   Selected Configuration" from CCS 6.1.3
--  Then "Connect to C66xx_DSP"
--  Load the K2G_bf_rt.out from
-   audio-preprocessing\\realtime_demo_bios\\k2g\\build
--  Run the program (loaded previously) by pressing F8
--  The program will run the real time demo forever, taking the input
-   from CMB and output to the on-board line-out
-
-OMAP-L137 EVM (using CCS)
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  Follow this link :ref:`Processor-SDK-RTOS-Setup-CCS-label`
-   to get target configuration setup correctly.
--  Connect to the on board emulator (J201 on OMAP-L137 EVM) to your PC
-   USB
--  Plug power adaptor(5V) into the OMAP-L137 EVM and power on the EVM
--  Launch the target configuration created in step 1 using "Launch
-   Selected Configuration" from CCS 6.1.3
--  Then "Connect to C674X_0"
--  Load the OMAPL137_bf_rt.out from
-   audio-preprocessing\\realtime_demo_bios\\omapl137\\make
--  Run the program (loaded previously) by pressing F8
--  The program will run the real time demo forever, taking the input
-   from CMB and output to the on-board line-out
-
-K2G EVM (Boot from SD card)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  Copy "app" and "MLO" from
-   audio-preprocessing\\realtime_demo_bios\\k2g\\pre-built\\mmcsd on Windows
-   or audio-preprocessing/realtime_demo_bios/k2g/pre-built/mmcsd on
-   Linux to the root directory of a formatted micro SD card
--  Plug in the micro SD card into uSD Card slot on K2G EVM
--  Connect "USB TO SOC UART0" on K2G EVM to a PC USB port via USB cable
--  Launch a terminal emulator like Tera Term and open the local COM port
-   corresponding to the UART0 (Set it to 115200 bps, 8 bit, none parity,
-   one bit stop, no flow control)
--  Plug power adapter (12V) into the K2G EVM and power on the EVM and
-   Power on the K2G EVM
--  There will be some information displayed on the SOC UART0
--  The program will run the real time demo forever, taking the input
-   from CMB and output to the on-board line-out
-
-|
-
-How to Read the Input/output Audio Files
-========================================
-
-Both the input/output audio files are in raw PCM format (\*.pcm or
-\*.bin) 16 bit per sample, big endian, mono, at 16Khz. They can be
-imported either by Adobe Audition or Audacity as the raw audio data.
-
-Import Raw Audio Data File using Adobe Audition
------------------------------------------------
-
--  Launch the Adobe Audition CS5.5
--  File --> Import --> Raw Data...
--  The following dialog will pop up
-
-.. Image:: /images/Aud_pre_processing_import.png
-
--  Select the raw audio file and input the correct parameters
--  Click OK
-
-Before and After Comparison
----------------------------
-
--  Before audio pre-processing (t8/y16L7g3m7090_1.pcm)
-
-.. Image:: /images/Aud_pre_processing_before.png
-
--  After audio pre-processing (t8/fileOutput.bin)
-
-.. Image:: /images/Aud_pre_processing_after.png
-
-|
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Bare_Metal_Examples.rst b/source/rtos/Examples_and_Demonstrations/_Bare_Metal_Examples.rst
deleted file mode 100644
index dec7ab0cd..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Bare_Metal_Examples.rst
+++ /dev/null
@@ -1,1108 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_Bare_Metal_Examples
-
-Overview
-========
-
-The bare-metal examples gets user started with development of code
-without an operating system. These are simple examples that does not get
-into details of software components provided in the SDK. Consequently,
-make sure there are no SD cards installed on the EVM with an OS prior to
-exploring the following examples.
-
-If you face any problems with CCS or JTAG, try these
-`troubleshooting steps <index_how_to_guides.html#troubleshooting>`__.
-
-
-ARM Cortex-A53
-===============
-In this article, we take a look at creating bare-metal hello world examples for the Cortex-A53 core in CCS. We will be using the AM654x device as an example.
-
-.. Note:: For future Device Support Package releases, the Hello World examples will be added to CCS as an out-of-box experience.
-
-1. Start CCS and create a workspace for
-generating the project.
-
-2. Configure the CCS Tools discovery path
-to allow CCS to use the code generation tools supplied with Processor-SDK-RTOS.
-
-	- Select the menu Window->Preferences
-	- On the left-hand side of the Preferences window, select Code Composer Studio->Build->Compilers
-	- On the right-hand side of the Preferences window, click the "Add" button. Select the Processor-SDK-RTOS root install folder, then click "Apply and Close".
-
-3. Navigate to File -> New ->
-CCS Project.
-
-4. Select Target as AM65x - Cortex A53 and GPEVM_AM65x as
-shown in the image below.
-
-5. Select **Cortex A setting** in the options below and provide a name for the project. Use the default advanced settings
-for the project. Select **GNU v7.2.1 (Linaro aarch64)** (or higher) for the Compiler Version. Under Tool-chain, for the Linker Command file, select the file (PDK INSTALL PATH)/packages/ti/build/am65xx/**linker_a53.lds**.
-
-Under Project templates and examples, select **Empty Project (with main.c).**
-
-Click Finish after you are done to allow CCS to auto generate the
-project from the template.
-
-
-.. Image:: /images/AM65x_Create_CCS_Project.png
-
-
-6. The generated CCS project contains source file **main.c**, ARM assembly code **startup_ARMCA53.S** and a linker command file **AM65X.lds**.
-Remove startup_ARMCA53.S and AM65X.lds from the project.
-
-
-7. Add the following linker command file to the project.
-::
-
-	(PDK INSTALL PATH)/packages/ti/build/am65xx/linker_a53.lds
-
-
-|
-
-8. Modify main.c to include the
-following::
-
-	/* Header files */
-	#include <stdint.h>
-	#include "stdio.h"
-
-	int main(void)
-	{
-		printf("Hello World\n");
-		while(1);
-	}
-
-9. Navigate to Project Properties -> CCS Build -> GNU Linker and add "Entry" to the "Set start address" field.
-
-
-10. Navigate to CCS Build -> GNU Linker -> Libraries and add the
-following libraries.
-::
-
-	ti.csl.init.aa53fg
-	ti.csl.aa53fg
-	rdimon
-	stdc++
-	gcc
-	c
-	m
-
-11. Add the following library search
-path.
-::
-
-	(PDK INSTALL PATH)/ti/csl/lib/am65xx/a53/release
-
-
-12. Save all changes, and right click on the project and select Build Project to
-build the project and generate hello_world.out.
-
-13. Launch the target configuration using your emulator to connect to the AM65x EVM as
-described in the :ref:`Processor-SDK-RTOS-Getting-Started-Guide-label`.
-
-14. Right click on **DMSC_Cortex_M3_0** and click connect to target.
-After connecting to the M3, right click on **CortexA53_0_0** and connect to it.
-
-15. Load and run hello_world.out example file on the Cortex-A53.
-You should see a Hello_world string displayed in the CCS console window.
-
-.. Image:: /images/AM65x_CCS_Hello_World.PNG
-
-ARM Cortex-A15
-==============
-
-In this article, we take a look at creating bare-metal hello world
-examples for Cortex A15 core using pre-built templates in CCS. As a
-sample we will use the AM572x device to describe the steps but the same
-steps can be used for create hello world examples for Cortex A15 cores
-in the Keystone 2 family of devices.
-
-.. note::
-
-   -  Only major difference between A15 examples for AM572x and Keystone 2
-      is that the Keystone 2 device contain MSMC memory instead of OCMC
-      memory as the shared memory.
-   -  For K2G devices, the hello world template will be created with the
-      .lds file that specifies MSMC and DDR memory sections. For K2E and
-      K2H, the CCS template doesn`t populate the .lds file. K2H & K2E users
-      can choose to use 66AK2G02.lds located at ccsv6\ccs_base\arm\include
-      as reference to add .lds file to their hello world projects.
-
-
-1. Start CCS and create a work space for generating the project.
-
-2. Click on File menu option and select New--> CCS Project.
-
-3. Select Target as AM572x -Cortex A15 and GPEVM_AM572x as shown in the
-image
-
-4. Select **Cortex A setting** in the options below and provide name of
-the project as "hello_world" and use default Advanced settings for the
-project. If the Default settings uses "TI ARM compiler 5.x.x" switch to
-**GNU Linaro 4.8.4** (or higher) tool chain for A15 and check the build
-**little** endian **ELF** binary for the A15 core. Under Project
-templates and examples, select **Basic Examples-> Hello World**
-
-Click Finish after you are done to allow CCS to auto generate the
-project from the template **Basic Examples-> Hello World**.
-
-.. Image:: /images/NewCCSProject_Hello_world.png
-
-5. The generated CCS project contains source file **main.c**, ARM
-assembly code **startup_ARMCA15.S** and a linker command file
-**AM572x.lds**. Please modify the main.c file by adding the following
-highlighted code lines and save main.c file.
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-      /*
-      * hello.c
-      */
-      #include <stdio.h>
-     
-      int main(void) {
-     
-          printf("Hello_world\n");
-          return 0;
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. note::
-   For Keystone2 users, the startup_ARMCA15.S and .lds file is not auto
-   populated by CCS. To add these file, right click the project and add
-   files and locate the 66AK2Gxx.lds and startup_ARMCA15.S under the file
-   path ccsvX/ccs_base/arm/include and add them to the project
-
-
-6. Ensure that CCSv6 generated linker command file **AM572x.lds**
-contains the following Memory configurations.
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-     MEMORY
-     {
-        OCMC_RAM1 :  o = 0x40300000,  l = 0x00080000  /* 512kB L3 OCMC RAM1 */
-        OCMC_RAM2 :  o = 0x40400000,  l = 0x00100000  /* 1MB L3 OCMC RAM2 */
-        OCMC_RAM3 :  o = 0x40500000,  l = 0x00100000  /* 1MB L3 OCMC RAM3 */
-        DDR0 :       o = 0x80000000,  l = 0x40000000  /* 1GB external DDR Bank 0 */
-        DDR1 :       o = 0xC0000000,  l = 0x40000000  /* 1GB external DDR Bank 1 */
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. note::
-   For Keystone 2 devices, replace all the OCMC_RAM# regions in the lds
-   file and replace it with MSMC memory section as shown below. Refer to
-   66AK2G02.lds file in ccs installation under directory path
-   ccsv6\ccs_base\arm\include
-
-::
-
-       MSMC  :      o=0x0c000000,    l = 0x00600000  /* 6MB Muticore shared memory */
-
-.. note::
-   The .lds file expects users to provide STACKSIZE and HEAPSIZE from
-   linker settings. To provide these settings got to Build Settings GNU
-   Linker add the following to the Symbols section. Keystone II devices
-   require this to be done explicitly in the linker settings
-
-::
-
-    STACKSIZE=10000
-    HEAPSIZE=400
-
-7. Right click on the project and select Build Project, to build the
-project and generate hello_world.out.
-
-8. Launch target configuration using your emulator to connect to AM572X
-EVM as described in the :ref:`Processor-SDK-RTOS-Getting-Started-Guide-label`.
-
-9. Right click **CortexA15_0** and select connect target.
-
-10. Initialize DDR configuration. On CCS --> Scripts --> DDR
-configurations --> AM572_DDR3_532MHz_config
-
-11. Load and run hello_world.out example file. You should see
-**Hello_world** string displayed on CCS console window.
-
-.. Image:: /images/HelloWorldOutput.jpg
-
-.. note::
-
-   -  If the example does not load correctly in the first attempt, reload
-      and **ensure ARM core starts at main**.
-   -  If the ARM loads correctly but you don`t see any output then check to
-      see if the GNU linker is linking to Semihosting library (librdimon)
-      in the linker setting. If it is not linked go to GNU linker settings
-      in CCS project and add **"rdimon"** to the libraries that are linked
-
-|
-
-ARM Cortex-A9
-=============
-
-1. Start CCSv6 and create a work space for generating the project.
-
-.. note::
-   CCSv6.1.1 doesn`t contain a hello world project template for Cortex A9
-   core using GNU Linaro 4.8.x tool chain. Due to code compatibility of
-   Cortex A8 and cortex A9 platforms, We recommend that you create a
-   project for Cortex A8 platform like AM335x using the GNU Linaro tool
-   chain and then use the code to test hello world application on the
-   Cortex A9 on the AM437x platform. If you wish to use TI ARM compiler
-   5.2.x, then you can use the default hello world template in CCSv6 for
-   the Cortex A9 on AM437x
-
-2. Click on File menu option and select New--> CCS Project. Steps assume
-that user is using GN Linaro tool chain for Cortex A9.
-
-3. Select Target as AM33xx -Cortex A8 and appropriate target Board
-setting as shown in the image
-
-4. Select **Cortex A8** setting in the options below and provide name of
-the project as "hello_world_a9" and use default Advanced settings for
-the project. If the Default settings uses "TI ARM compiler 5.x.x" switch
-to **GNU Linaro 4.8.4** (or higher) tool chain for A9 and check the
-build **little** endian **ELF** binary for the A9 core. Click Finish
-after you are done to allow CCS to auto generate the project from the
-template **Basic Examples-> Hello World**.
-
-.. Image:: /images/Bare-Metal_A9_templateselect.jpg
-
-5. The generated CCS project contains source file **main.c**, ARM
-assembly code **startup_ARMCA8.S** and a linker command file
-**AM335x.lds**. The startup file does some basic setup and there is no
-difference between A8 and A9, so it can be used directly on A9 target.
-Ensure the main.c file contains the following code
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-      /*
-      * hello.c
-      */
-      #include <stdio.h>
-     
-      int main(void) {
-     
-          printf("Hello_world\n");
-          return 0;
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-6. Ensure that CCSv6 generates the linker command file **AM335x.lds**.
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-     MEMORY
-     {
-        SRAM :     o = 0x402F0400,  l = 0x0000FC00  /* 64kB internal SRAM */
-        L3OCMC0 :  o = 0x40300000,  l = 0x00010000  /* 64kB L3 OCMC SRAM */
-        M3SHUMEM : o = 0x44D00000,  l = 0x00004000  /* 16kB M3 Shared Unified Code Space */
-        M3SHDMEM : o = 0x44D80000,  l = 0x00002000  /* 8kB M3 Shared Data Memory */
-        DDR0 :     o = 0x80000000,  l = 0x40000000  /* 1GB external DDR Bank 0 */
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. note::
-   An optional step is to modify the section definition in AM437x.lds file
-   if you wish to introduce more sections or partition the existing
-   sections. If you renamed the startup file from startup_ARMCA8.S to
-   startup_ARMCA9.S in your project, then the linker command file needs to
-   be updated as well for code section placement: from startup_ARMCA8.o
-   (.text) to startup_ARMCA9.o (.text)
-
-
-7. Now build the project to generate hello_world.out file.
-
-8. Launch target configurations using your emulator to connect to AM335X
-EVM as described in the :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`.
-
-9. Right click CortexA9 and connect target. The on target functionality
-in the GEL will initialize the clocks and DDR.
-
-10. Load and run hello_world_a9.out file. You should see **Hello
-World!** string displayed on CCS console window.
-
-.. Image:: /images/Hello_world_a9.jpg
-
-.. note::
-   If the example does not load correctly in the first attempt, reload and
-   **ensure ARM core starts at main**.
-
-
-ARM Cortex-A8
-=============
-
-1. Start CCSv6 and create a work space for generating the project.
-
-2. Click on File menu option and select New--> CCS Project.
-
-3. Select Target as AM33xx -Cortex A8 and appropriate target Board
-setting as shown in the image
-
-4. Select **Cortex A8** setting in the options below and provide name of
-the project as "hello_world_a8" and use default Advanced settings for
-the project. If the Default settings uses "TI ARM compiler 5.x.x" switch
-to **GNU Linaro 4.8.4** (or higher) tool chain for A8 and check the
-build **little** endian **ELF** binary for the A8 core. Click Finish
-after you are done to allow CCS to auto generate the project from the
-template **Basic Examples-> Hello World**.
-
-.. Image:: /images/Bare-Metal_A8_templateselect.jpg
-
-5. The generated CCS project contains source file **hello.c**, ARM
-assembly code **startup_ARMCA8.S** and a linker command file
-**AM335x.lds**. Ensure the main.c file contains the following code
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-      /*
-      * hello.c
-      */
-      #include <stdio.h>
-     
-      int main(void) {
-     
-          printf("Hello_world\n");
-          return 0;
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-6. Ensure that CCSv6 generates the linker command file **AM335x.lds**.
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-     MEMORY
-     {
-        SRAM :     o = 0x402F0400,  l = 0x0000FC00  /* 64kB internal SRAM */
-        L3OCMC0 :  o = 0x40300000,  l = 0x00010000  /* 64kB L3 OCMC SRAM */
-        M3SHUMEM : o = 0x44D00000,  l = 0x00004000  /* 16kB M3 Shared Unified Code Space */
-        M3SHDMEM : o = 0x44D80000,  l = 0x00002000  /* 8kB M3 Shared Data Memory */
-        DDR0 :     o = 0x80000000,  l = 0x40000000  /* 1GB external DDR Bank 0 */
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. note::
-   An optional step is to modify the section definition in AM335x.lds file
-   if you wish to introduce more sections or partition the existing
-   sections.
-
-7. Now build the project to generate hello_world_a8.out file.
-
-8. Launch target configurations using your emulator to connect to AM335X
-EVM as described in the :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`.
-
-9. Right click CortexA8 and select connect target. The on target
-functionality in the GEL will initialize the clocks and DDR.
-
-10. Load and run hello_world_a8.out file. You should see **Hello
-World!** string displayed on CCS console window.
-
-.. Image:: /images/Hello_world_a8.jpg
-
-.. note::
-   If the example does not load correctly in the first attempt, reload and
-   **ensure ARM core starts at main**.
-
-|
-
-ARM Cortex-R5
-=============
-
-In this article, we take a look at creating bare-metal hello world examples for the Cortex-R5 core in CCS. We will be using the AM654x device as an example.
-
-.. Note:: For future Device Support Package releases, the Hello World examples will be added to CCS as an out-of-box experience.
-
-1. Start CCS and create a workspace for
-generating the project.
-
-2. Navigate to File -> New ->
-CCS Project.
-
-3. Select Target as AM65x - Cortex R5 and GPEVM_AM65x as
-shown in the image below.
-
-4. Select the **Cortex R** tab and provide a name for the project. Select **TI v16.9.4.LTS** (or higher) for the Compiler Version.
-Under Tool-chain, set the Device Endianness to **little**, and for the Linker Command file, select **linker_r5.lds** located in the folder (PDK INSTALL PATH)/packages/ti/build/am65xx/.
-
-.. Note:: Please refer to the Release Notes for the recommended Compiler version.
-
-Under Project templates and examples, select **Basic Examples -> Hello World**
-
-Click Finish after you are done to allow CCS to auto generate the
-project from the template.
-
-.. Image:: /images/AM65x_Create_CCS_Project_R5.png
-
-5. The generated CCS project contains source file **hello.c**,
-and linker command file **linker_r5.lds**.
-
-6. Navigate to CCS Build -> ARM Linker -> File Search Path and
-add the following libraries.
-::
-
-	ti.csl.aer5f
-	ti.csl.init.aer5f
-	libc.a
-
-7. Add the following library
-search path.
-::
-
-	(PDK INSTALL PATH)/ti/csl/lib/am65xx/r5f/release
-
-
-8. Save all changes, and right click on the project and select Build Project to
-build the project and generate hello_world.out.
-
-9. Launch the target configuration using your emulator to connect to the AM65x EVM as
-described in the :ref:`Processor-SDK-RTOS-Getting-Started-Guide-label`.
-
-10. Right click on **DMSC_Cortex_M3_0** and click connect to target.
-After connecting to the M3, right click on **MCU_PULSAR_Cortex_R5_0** and connect to it.
-
-11. Load and run hello_world.out example file on the Cortex-R5.
-You should see a Hello_world string displayed in the CCS console window.
-
-.. Image:: /images/AM65x_CCS_Hello_World_R5.PNG
-
-|
-
-ARM Cortex-M4
-==============
-
-1. Start CCSv6 and create a work space for generating the project.
-
-2. Click on File menu option and select New--> CCS Project.
-
-3. Select Target as AM572x -Cortex M4 and GPEVM_AM572x as shown in the
-image
-
-4. Select **Cortex M** setting in the options below and provide name of
-the project as "hello_world_m4" and use default Advanced settings for
-the project. Click Finish after you are done to allow CCS to auto
-generate the project from the template **Basic Examples-> Hello World**.
-The Default settings uses "TI ARM compiler 5.x.x" tool chain for cortex
-M4 and sets the build for **little** endian **ELF** binary for the M4
-core.
-
-.. Image:: /images/Bare-Metal_M4_templateselect.jpg
-
-5. The generated CCS project contains only one source file **hello.c**.
-Ensure the main.c file contains the following code
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-      /*
-      * hello.c
-      */
-      #include <stdio.h>
-     
-      int main(void) {
-     
-          printf("Hello_world\n");
-          return 0;
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-6. CCSv6 includes a default linker command file(AM57xx_CM4.cmd) for the
-M4 (IPU) core which will place code into appropriate device memory. The
-linker command file has the following memory sections.
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-    MEMORY
-    {
-        IRAM:      o = 0x00000000 l = 0x00001000   /* 4kB internal SRAM */
-        OCMC_RAM1: o = 0x40300000 l = 0x00080000   /* 512kB L3 OCMC SRAM1 */
-        OCMC_RAM2: o = 0x40400000 l = 0x00100000   /* 1MB L3 OCMC SRAM2 */
-        OCMC_RAM3: o = 0x40500000 l = 0x00100000   /* 1MB L3 OCMC SRAM3 */
-        DDR0:      o = 0x80000000 l = 0x40000000   /* 1GB external DDR Bank 0 */
-    }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-The linker command file is designed to place code in OCMC memory with
-interrupt vectors and .intc_txt generated by the compiler being place in
-device internal memory.
-
-.. note::
-
-   -  Please note that if the device GEL files are setting up MMU for the
-      core then the code will not load correctly on the core and will cause
-      a CPU exception. We recommend that you modify the linker command file
-      appropriately to match the MMU settings in the GEL file. The linker
-      command file in all CCS releases prior to CCS 6.1.3 don`t account for
-      this MMU Setting in AM57xx GEL files. Please modify the OCMC
-      addresses to the logical address set in the GEL file
-   -  An optional step is to modify the section definition in
-      AM57xx_CM4.cmd file if you wish to introduce/partition existing
-      sections or place the code in different memory section.
-
-7. Now build the project to generate hello_world_m4.out.
-
-8. Launch target configurations using your emulator to connect to AM572X
-EVM as described in the :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-
-9. In order to wake up the M4 core from A15, Go to Menu option
-Scripts->AM572x_Multicore_Initialization->IPU1SSClkEnable_API. Refer to
-the
-`Processor_SDK_RTOS_Setup_CCS <index_how_to_guides.html#connect-to-am57x-target-cores>`__.
-
-You should see the following log in the Console
-
-::
-
-     CortexA15_0: GEL Output: --->>> IPU1SS Initialization is in progress ... <<<---
-     CortexA15_0: GEL Output: --->>> IPU1SS Initialization is DONE! <<<---
-
-11. Select and Connect to Cortex_M4_IPU1_C0. Load and run
-Hello_Example_m4.out file. You should see **Hello World** string
-displayed on console window.
-
-.. Image:: /images/Hello_world_m4.jpg
-
-.. note::
-
-   If the example does not load correctly in the first attempt, reload and
-   **ensure ARM core starts at main**.
-
-|
-
-ARM9
-====
-
-In this article, we take a look at creating bare-metal hello world examples for the ARM9 core using pre-built templates in CCS.
-As a sample we will use the OMAP-L138 device to describe the steps.
-
-1. Start CCS and create a workspace for generating the project.
-
-2. Click on File menu option and select New--> CCS Project.
-
-3. Select Target as OMAP-L1x --> ARM9 and appropriate target board as shown in the image below.
-
-.. Image:: /images/omapl13x_arm9_hello_nonos_ccs.png
-
-
-4. In the ARM9 tab, provide a name for
-the project, such as "hello_world_arm9" and use the default settings for
-the project as shown in the image below. Ensure OMAPL138.cmd is selected for the linker command file.
-
-.. Image:: /images/omapl13x_arm9_hello_nonos_ccs2.png
-
-5. Click Finish
-after you are done to allow CCS to auto generate the project from the
-template **Basic Examples-> Hello World**.
-
-6. The generated CCS project contains source file **main.c**, and a linker command file
-**OMAPL138.cmd**. Ensure the main.c file contains the following code.
-
-.. code:: c
-
-      /*
-      * hello.c
-      */
-      #include <stdio.h>
-     
-      int main(void) {
-     
-          printf("Hello_world\n");
-          return 0;
-     }
-
-
-7. Ensure that CCS generates the linker command file **OMAPL138.cmd** as shown below.
-
-.. code:: c
-
-	MEMORY
-	{
-	#ifdef DSP_CORE      /* DSP exclusive memory regions */
-
-		DSPL2ROM     o = 0x00700000  l = 0x00100000  /* 1MB L2 DSP local ROM */
-		DSPL2RAM     o = 0x00800000  l = 0x00040000  /* 256kB L2 DSP local RAM */
-		DSPL1PRAM    o = 0x00E00000  l = 0x00008000  /* 32kB L1 DSP local Program RAM */
-		DSPL1DRAM    o = 0x00F00000  l = 0x00008000  /* 32kB L1 DSP local Data RAM */
-
-	#endif
-
-		SHDSPL2ROM   o = 0x11700000  l = 0x00100000  /* 1MB L2 Shared Internal ROM */
-		SHDSPL2RAM   o = 0x11800000  l = 0x00040000  /* 256kB L2 Shared Internal RAM */
-		SHDSPL1PRAM  o = 0x11E00000  l = 0x00008000  /* 32kB L1 Shared Internal Program RAM */
-		SHDSPL1DRAM  o = 0x11F00000  l = 0x00008000  /* 32kB L1 Shared Internal Data RAM */
-		EMIFACS0     o = 0x40000000  l = 0x20000000  /* 512MB SDRAM Data (CS0) */
-		EMIFACS2     o = 0x60000000  l = 0x02000000  /* 32MB Async Data (CS2) */
-		EMIFACS3     o = 0x62000000  l = 0x02000000  /* 32MB Async Data (CS3) */
-		EMIFACS4     o = 0x64000000  l = 0x02000000  /* 32MB Async Data (CS4) */
-		EMIFACS5     o = 0x66000000  l = 0x02000000  /* 32MB Async Data (CS5) */
-		SHRAM        o = 0x80000000  l = 0x00020000  /* 128kB Shared RAM */
-		DDR2         o = 0xC0000000  l = 0x20000000  /* 512MB DDR2 Data */
-
-	#ifndef DSP_CORE     /* ARM exclusive memory regions */
-
-		ARMROM       o = 0xFFFD0000  l = 0x00010000  /* 64kB ARM local ROM */
-		ARMRAM       o = 0xFFFF0000  l = 0x00002000  /* 8kB ARM local RAM */
-
-	#endif
-	}
-
-	SECTIONS
-	{
-		.text          >  SHRAM
-		.stack         >  SHRAM
-		.bss           >  SHRAM
-		.cio           >  SHRAM
-		.const         >  SHRAM
-		.data          >  SHRAM
-		.switch        >  SHRAM
-		.sysmem        >  SHRAM
-		.far           >  SHRAM
-		.args          >  SHRAM
-		.ppinfo        >  SHRAM
-		.ppdata        >  SHRAM
-
-		/* TI-ABI or COFF sections */
-		.pinit         >  SHRAM
-		.cinit         >  SHRAM
-
-		/* EABI sections */
-		.binit         >  SHRAM
-		.init_array    >  SHRAM
-		.neardata      >  SHRAM
-		.fardata       >  SHRAM
-		.rodata        >  SHRAM
-		.c6xabi.exidx  >  SHRAM
-		.c6xabi.extab  >  SHRAM
-	}
-
-
-8. Now build the project to generate hello_world.out file.
-
-9. Launch target configurations using your emulator to connect to the OMAP-L138
-as described in the :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`.
-
-10. Right click on ARM9_0 and connect to target. The on target functionality
-in the GEL will initialize the clocks and DDR.
-
-11. Load and run hello_world_arm9.out file. You should see **Hello
-World!** string displayed on CCS console window.
-
-|
-
-DSP C66x
-========
-
-In this article, we take a look at creating bare-metal hello world
-examples for C66x core using pre-built templates in CCS. As a sample we
-will use the AM572x device to describe the steps but the same steps can
-be used for create hello world examples for C66x cores in the Keystone 2
-family of devices.
-
-.. note::
-   Only major difference C66x examples for AM572x and Keystone 2 is that
-   the Keystone 2 device contain MSMC memory instead of OCMC memory as the
-   shared on chip memory.
-
-1. Start CCSv6 and create a work space for generating the project.
-
-2. Click on File menu option and select New--> CCS Project.
-
-3. Select Target as AM572x -C66xx and GPEVM_AM572x as shown in the image
-
-4. Select **C66XX [C6000]** DSP setting in the options below and provide
-name of the project as "hello_world_dsp" and use default Advanced
-settings for the project. Click Finish after you are done to allow CCS
-to auto generate the project from the template **Basic Examples-> Hello
-World**. The Default settings uses "TI CG Tools compiler 8.x.x" tool
-chain for C66x and sets the build for **little** endian **ELF** binary
-for the C66x core.
-
-.. Image:: /images/Bare-Metal_C66x_templateselect.jpg
-
-5. The generated CCS project contains only one source file **hello.c**.
-Ensure the main.c file contains the following code
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-      /*
-      * hello.c
-      */
-      #include <stdio.h>
-     
-      int main(void) {
-     
-          printf("Hello_world\n");
-          return 0;
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-6. CCSv6 includes a default linker command file(AM57xx_C66.cmd) for the
-C66x DSP core which will place code into appropriate device memory. The
-linker command file has the following memory sections.
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-    MEMORY
-    {
-        IRAM_MEM:  o = 0x00800000 l = 0x00008000   /* 32kB internal SRAM */
-        OCMC_RAM1: o = 0x40300000 l = 0x00080000   /* 512kB L3 OCMC SRAM1 */
-        OCMC_RAM2: o = 0x40400000 l = 0x00100000   /* 1MB L3 OCMC SRAM2 */
-        OCMC_RAM3: o = 0x40500000 l = 0x00100000   /* 1MB L3 OCMC SRAM3 */
-        DDR0:      o = 0x80000000 l = 0x40000000   /* 1GB external DDR Bank 0 */
-    }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-The linker command file is designed to place code in OCMC memory.
-
-.. note::
-   For Keystone 2 devices, replace all the OCMC_RAM# regions in the lds
-   file and replace it with MSMC memory section as shown below.
-
-
-::
-
-       MSMC  :      o=0x0c000000,    l = 0x00600000  /* 6MB Muticore shared memory */
-
-.. note::
-   An optional step is to modify the section definition in linker command
-   file if you wish to introduce/partition existing sections or place the
-   code in different memory section.
-
-
-7. Now build the project to generate hello_world_dsp.out.
-
-8. Launch target configurations using your emulator to connect to AM572X
-EVM as described in the :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-
-9. In order to wake up the DSP1 core from A15, Go to Menu option
-Scripts->AM572x_Multicore_Initialization->DSP1SSClkEnable_API. Refer to
-the
-`Processor_SDK_RTOS_Setup_CCS <index_how_to_guides.html#connect-to-am57x-target-cores>`__.
-
-You should see the following log in the Console
-
-::
-
-     CortexA15_0: GEL Output: --->>> DSP1SS Initialization is in progress ... <<<---
-     CortexA15_0: GEL Output: DEBUG: Clock is active ...
-     CortexA15_0: GEL Output: DEBUG: Checking for data integrity in DSPSS L2RAM ...
-     CortexA15_0: GEL Output: DEBUG: Data integrity check in GEM L2RAM is sucessful!
-     CortexA15_0: GEL Output: --->>> DSP1SS Initialization is DONE! <<<---
-
-10. Select and Connect to C66x_DSP1. Load and run hello_world_dsp.out
-file. You should see **Hello World** string displayed on console window.
-
-.. Image:: /images/Hello_world_dsp.jpg
-
-|
-
-DSP C674x
-=========
-
-In this article, we take a look at creating bare-metal hello world
-examples for C674x core using pre-built templates in CCS. As a sample we
-will use the C6748 LCDK device to describe the steps but the same steps
-can be used for create hello world examples for C674x cores in the
-OMAPL13x/C647x/DA8x family of devices.
-
-.. note::
-   All the C674x DSP cores on in OMAPL13x/C674x/DA8x have the same memory
-   map so modification are limited to selecting the correct platform when
-   generating the project
-
-
-1. Start CCS and create a work space for generating the project.
-
-2. Click on File menu option and select New--> CCS Project.
-
-3. Select Target as OMAPLx -C674xx and LCDK674x as shown in the image
-
-4. Select **C67XX [C6000]** DSP setting in the options below and provide
-name of the project as "hello_world_lcdk674x" and use default Advanced
-settings for the project. Click Finish after you are done to allow CCS
-to auto generate the project from the template **Basic Examples-> Hello
-World**. The Default settings uses "TI CG Tools compiler 8.x.x" tool
-chain for C674x and sets the build for **little** endian **ELF** binary
-for the C674x core.
-
-.. Image:: /images/Baremetal_helloWorld_ProjectCreate_step1.png
-
-5. The generated CCS project contains only one source file **hello.c**.
-Ensure the main.c file contains the following code
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-      /*
-      * hello.c
-      */
-      #include <stdio.h>
-     
-      int main(void) {
-     
-          printf("Hello_world\n");
-          return 0;
-     }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-6. CCS includes a default linker command file(C6748.cmd) for the C674x
-DSP core which will place code into appropriate device memory. The
-linker command file has the following memory sections.
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-    MEMORY
-    {
-        DSPL2ROM     o = 0x00700000  l = 0x00100000   /* 1MB L2 Internal ROM */
-        DSPL2RAM     o = 0x00800000  l = 0x00040000   /* 256kB L2 Internal RAM */
-        DSPL1PRAM    o = 0x00E00000  l = 0x00008000   /* 32kB L1 Internal Program RAM */
-        DSPL1DRAM    o = 0x00F00000  l = 0x00008000   /* 32kB L1 Internal Data RAM */
-        SHDSPL2ROM   o = 0x11700000  l = 0x00100000   /* 1MB L2 Shared Internal ROM */
-        SHDSPL2RAM   o = 0x11800000  l = 0x00040000   /* 256kB L2 Shared Internal RAM */
-        SHDSPL1PRAM  o = 0x11E00000  l = 0x00008000   /* 32kB L1 Shared Internal Program RAM */
-        SHDSPL1DRAM  o = 0x11F00000  l = 0x00008000   /* 32kB L1 Shared Internal Data RAM */
-        EMIFACS0     o = 0x40000000  l = 0x20000000   /* 512MB SDRAM Data (CS0) */
-        EMIFACS2     o = 0x60000000  l = 0x02000000   /* 32MB Async Data (CS2) */
-        EMIFACS3     o = 0x62000000  l = 0x02000000   /* 32MB Async Data (CS3) */
-        EMIFACS4     o = 0x64000000  l = 0x02000000   /* 32MB Async Data (CS4) */
-        EMIFACS5     o = 0x66000000  l = 0x02000000   /* 32MB Async Data (CS5) */
-        SHRAM        o = 0x80000000  l = 0x00020000   /* 128kB Shared RAM */
-        DDR2         o = 0xC0000000  l = 0x20000000   /* 512MB DDR2 Data */
-    }
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-The linker command file is designed to place code in OCMC memory.
-
-.. note::
-   For OMAPL13x/C674x devices, the linker command file places code in the
-   SHRAM memory section as shown below.
-
-::
-
-       SECTIONS
-      {
-       .text          >  SHRAM
-       .stack         >  SHRAM
-       .bss           >  SHRAM
-        .......
-      }
-
-.. note::
-   An optional step is to modify the section definition in linker command
-   file if you wish to introduce/partition existing sections or place the
-   code in different memory section.
-
-7. Now build the project by right clicking on the Project and selecting
-"Build Project" to generate hello_world_lcdk674x.out.
-
-8. Launch target configurations using your emulator to connect to
-OMAPLx/C674x LCDK as described in the :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`.
-
-9. Developers on OMAPL137/C6747/C6748 can
-connect directly to the DSP. For OMAPL138 device, you will need to
-connect to the ARM as this is ARM master boot device and ARM needs to
-power up the DSP. You should see the following log in the console.
-
-::
-
-    C674X_0: Output:   Target Connected.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    Memory Map Cleared.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    Memory Map Setup Complete.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    PSC Enable Complete.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    PLL0 init done for Core:300MHz, EMIFA:25MHz
-    C674X_0: Output:    DDR initialization is in progress....
-    C674X_0: Output:    PLL1 init done for DDR:150MHz
-    C674X_0: Output:    Using DDR2 settings
-    C674X_0: Output:    DDR2 init for 150 MHz is done
-    C674X_0: Output:    ---------------------------------------------
-
-|
-
-11. Select and Connect to C674x. Load and run hello_world_dsp.out file.
-You should see **Hello World** string displayed on console window.
-
-.. Image:: /images/Hello_world_dsp674x.png
-
-|
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Big_Data_IPC_Examples.rst b/source/rtos/Examples_and_Demonstrations/_Big_Data_IPC_Examples.rst
deleted file mode 100644
index 06deab7dc..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Big_Data_IPC_Examples.rst
+++ /dev/null
@@ -1,472 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_Big_Data_IPC_Examples
-
-Introduction
-============
-
-High Performance Computing applications and other Data intensive
-applications often require passing of Big data buffers between the
-multi-core processors in an SOC.
-
-The Big Data IPC examples are created mainly to show exchange of big
-data buffers between cores and is part of the Processor SDK RTOS
-package.
-
-Currently the example named "simple_buffer_example", captures the
-details of exchange of big buffers with both host A15 core and a DSP
-cores.
-
-Architecture Overview
-=====================
-
-The following block diagram shows the various functional blocks used in
-the example on the cores running TI-RTOS/BIOS.
-
-.. Image:: /images/Big_Data_IPC_RTOS_Software_blocks.png
-
-For the small message IPC, sharedRegion and Heap, the modules in the
-Standard TI IPC package are used.
-
-The BigDataXlat module, which is part of the example code, provides a
-high level abstraction to take care of Address translation and Cache
-sync on the big data buffers.
-
-Simple Buffer example: Program Sequence
-=======================================
-
-This section describes the program sequence captured in the example.
-
-The main aim of the overall program is to show the exchange of big data
-buffers. The sequence is described in words here to sort of walk through
-the main application code.
-
-Initially, the host sends first message with shared memory init
-information followed by two more dummy messages to slave core ( all
-three messages sent in sequence without waiting for reply).
-
-The shared memory region init message conveys the details about the
-shared memory expected to hold the big data buffers.
-
-Independently, the slave processor receives messages and sends back
-reply back for each of the messages to the host.
-
-Then the host receives one message from the slave and sends a message
-with Big data buffer allocated from the Big data heap and filled with an
-incrementing pattern. (This process is repeated with 10 Big data Buffer
-messages). Each of these Messages are received by slave and the values
-in the buffers are updated with a modified incrementing pattern and sent
-back to the host.
-
-Note the Slave and Host processors checks the expected incrementing
-pattern for errors.
-
-At this point only 7 Big data buffer messages would have been received.
-Then the host sends two dummy messages plus one shutdown message to the
-slave core when receiving the remaining three Big data buffer messages.
-Totally 10 Big data buffers are exchanged between the cores. The slave
-core on receiving the shutdown message, shuts itself down and
-reinitializes itself for future runs.
-
-Then the host receives back the remaining returned messages before
-shutting down.
-
-.. note::
-   The size of the big data buffer is configurable compile time by
-   changing value of the define BIGDATA_SIZE in shared/AppCommon.h
-
-Host Linux example
-==================
-
-.. note::
-   Host linux example is only available starting from Processor SDK
-   4.0.0 release for AM57xx platform
-
-Under the host_linux directory the simple_buffer_example is implemented
-for Host A15 running Linux and DSP core running TI-RTOS.
-
-Architecture Updates for Linux
-------------------------------
-
-The following block diagram shows the various functional blocks used in
-the example on the host running linux.
-
-.. Image:: /images/Big_DATA_IPC_Linux_Software_blocks.png
-
-The SharedRegion and HeapMem modules are not currently supported for
-Linux in the TI Standard IPC package.
-
-The example provides these modules with same/similar API implemented for
-Linux with some limitations.
-
-The CMEM APIs provide user space allocation of contiguous memory for the
-Big data buffers.
-
-How to Run the Example
-----------------------
-
-The Processor SDK Linux release includes the pre-built binaries for the
-host_linux example as part of the tisdk-rootfs-image filesystem.
-
-Step 1 : To run the demo, the first step is to make sure there is no
-other default applications using the same resources. For example, the
-following command is needed to disable the default OpenCL applications.
-
-::
-
-       systemctl stop ti-mct-daemon.service
-
-Step 2: Switch the firmware running in the DSP. This can be done by
-using the following steps. Unbind dsp
-
-::
-
-       echo 40800000.dsp > /sys/bus/platform/drivers/omap-rproc/unbind
-
-.. note::
-   May need to unbind all the other cores as well to avoid issues.
-
-Update firmware symbolic link
-
-::
-
-       ln -sf /usr/bin/simple_buffer_example/release/server_dsp.xe66 /lib/firmware/dra7-dsp1-fw.xe66
-
-Bind dsp
-
-::
-
-       echo 40800000.dsp > /sys/bus/platform/drivers/omap-rproc/bind
-
-Step 3: Now the Host side application can be run using the following
-command
-
-::
-
-       /usr/bin/simple_buffer_example/release/app_host
-
-The DSP side log can be checked by typing the following command to dump
-the trace.
-
-::
-
-       cat /sys/kernel/debug/remoteproc/remoteproc2/trace0
-
-Here is a sample log.
-
-::
-
-    root@am57xx-evm:~# /usr/bin/simple_buffer_example/release/app_host DSP1
-    --> main:
-    [523682.897761] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
-    [523682.903751] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
-    [523682.911797] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
-    --> Main_main:
-    --> App_create:
-    App_create: Host is ready
-    <-- App_create:
-    --> App_exec:
-    CMEM_init success
-    CMEM_getPool success
-    CMEM_allocPool success: Allocated buffer 0xaa641000
-    SharedRegion_setup success
-    App_taskFxn: SR_1, base 0xaa641000, len=1000000
-    HeapMem_setup success
-    HeapMem_create success
-    App_taskFxn: SR_1 heap, totalSize=16777216,totalFreeSize=16777216,largestFreeSize=16777216
-    App_taskFxn: SR_1 heap, buf=0x0xaa641080,size=16777216
-    App_exec: sending message 1
-    Shared memory phys Addr ffffffffa0000000
-    App_exec: sending message 2
-    App_exec: sending message 3
-    App_exec: message received 1
-    App_exec: Preparing message 4
-    App_exec: Sending message 4
-    App_exec: message received 2
-    App_exec: Preparing message 5
-    App_exec: Sending message 5
-    App_exec: message received 3
-    App_exec: Preparing message 6
-    App_exec: Sending message 6
-    App_exec: message received 4
-    App_exec: Preparing message 7
-    App_exec: Sending message 7
-    App_exec: message received 5
-    App_exec: Preparing message 8
-    App_exec: Sending message 8
-    App_exec: message received 6
-    App_exec: Preparing message 9
-    App_exec: Sending message 9
-    App_exec: message received 7
-    App_exec: Preparing message 10
-    App_exec: Sending message 10
-    App_exec: message received 8
-    App_exec: Preparing message 11
-    App_exec: Sending message 11
-    App_exec: message received 9
-    App_exec: Preparing message 12
-    App_exec: Sending message 12
-    App_exec: message received 10
-    App_exec: Preparing message 13
-    App_exec: Sending message 13
-    App_exec: message received 11
-    App_exec: Preparing message 14
-    App_exec: Sending message 14
-    App_exec: message received 12
-    App_exec: Preparing message 15
-    App_exec: Sending message 15
-    App_exec: message received 13
-    App_exec: Preparing message 16
-    App_exec: Sending message 16
-    App_exec: message received: 14
-    App_exec: message received: 15
-    App_exec: message received: 16
-    App_exec: Data check clean
-    <-- App_exec: 0
-    --> App_delete:
-    <-- App_delete:
-    <-- Main_main:
-
-     Host: Test Passed
-    <-- main:
-    root@am57xx-evm:~#
-
-    root@am57xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc2/trace0
-    [      0.000] 18 Resource entries at 0x95000000
-    [      0.000] [t=0x0002122e] xdc.runtime.Main: --> main:
-    [      0.000] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
-    [      0.000] [t=0x003c5d7b] xdc.runtime.Main: NameMap_sendMessage: HOST 53, port=61
-    [      0.000] [t=0x003d5186] xdc.runtime.Main: --> smain:
-    [      0.000] [t=0x003e8259] Server: Server_create: server is ready
-    [      0.000] [t=0x003ecc97] Server: <-- Server_create: 0
-    [      0.000] [t=0x003f04a4] Server: --> Server_exec:
-    [     51.571] [t=0x00000008:a56e6a9a] Server: Message received...1
-    [     51.571] [t=0x00000008:a56f9b77] Server: Shared region entry configured...
-    [     51.571] [t=0x00000008:a5700cb1] Server: Server_exec: processed id 1, cmd=0x1
-    [     51.571] [t=0x00000008:a570aea5] Server: Message received...2
-    [     51.571] [t=0x00000008:a57119fd] Server: Server_exec: processed id 2, cmd=0x0
-    [     51.571] [t=0x00000008:a571b1e9] Server: Message received...3
-    [     51.571] [t=0x00000008:a5721eac] Server: Server_exec: processed id 3, cmd=0x0
-    [     51.571] [t=0x00000008:a5755f6b] Server: Message received...4
-    [     51.573] [t=0x00000008:a583e61b] Server: Server_exec: processed id 4, cmd=0x2
-    [     51.573] [t=0x00000008:a584a087] Server: Message received...5
-    [     51.574] [t=0x00000008:a592c2cc] Server: Server_exec: processed id 5, cmd=0x2
-    [     51.574] [t=0x00000008:a5937d8c] Server: Message received...6
-    [     51.575] [t=0x00000008:a5a19aeb] Server: Server_exec: processed id 6, cmd=0x2
-    [     51.575] [t=0x00000008:a5a2543d] Server: Message received...7
-    [     51.577] [t=0x00000008:a5b07d15] Server: Server_exec: processed id 7, cmd=0x2
-    [     51.577] [t=0x00000008:a5b137c0] Server: Message received...8
-    [     51.578] [t=0x00000008:a5bf5d83] Server: Server_exec: processed id 8, cmd=0x2
-    [     51.578] [t=0x00000008:a5c019cc] Server: Message received...9
-    [     51.579] [t=0x00000008:a5ce3dca] Server: Server_exec: processed id 9, cmd=0x2
-    [     51.579] [t=0x00000008:a5cef75e] Server: Message received...10
-    [     51.581] [t=0x00000008:a5dd247a] Server: Server_exec: processed id 10, cmd=0x2
-    [     51.581] [t=0x00000008:a5dde2d9] Server: Message received...11
-    [     51.582] [t=0x00000008:a5ec04df] Server: Server_exec: processed id 11, cmd=0x2
-    [     51.582] [t=0x00000008:a5ecc1a3] Server: Message received...12
-    [     51.583] [t=0x00000008:a5fae91c] Server: Server_exec: processed id 12, cmd=0x2
-    [     51.583] [t=0x00000008:a5fba4c6] Server: Message received...13
-    [     51.585] [t=0x00000008:a609d1c1] Server: Server_exec: processed id 13, cmd=0x2
-    [     51.585] [t=0x00000008:a60a8dd4] Server: Message received...14
-    [     51.585] [t=0x00000008:a60af96e] Server: Server_exec: processed id 14, cmd=0x0
-    [     51.585] [t=0x00000008:a60b9229] Server: Message received...15
-    [     51.585] [t=0x00000008:a60bffd3] Server: Server_exec: processed id 15, cmd=0x0
-    [     51.585] [t=0x00000008:a60e179b] Server: Message received...16
-    [     51.585] [t=0x00000008:a60e9727] Server: Server_exec: processed id 16, cmd=0x2000000
-    [     51.585] [t=0x00000008:a60f3fb7] Server: Server_exec: Data check clean
-    [     51.585] [t=0x00000008:a60fb280] Server: <-- Server_exec: 0
-    [     51.585] [t=0x00000008:a6101708] xdc.runtime.Main: DSP: Test Passed
-    [     51.585] [t=0x00000008:a6109170] Server: --> Server_delete:
-    [     51.585] [t=0x00000008:a6114fa2] Server: <-- Server_delete: 0
-    [     51.586] [t=0x00000008:a6127d48] Server: Server_create: server is ready
-    [     51.586] [t=0x00000008:a612ff93] Server: <-- Server_create: 0
-    [     51.586] [t=0x00000008:a613620c] Server: --> Server_exec:
-    root@am57xx-evm:~#
-
-|
-
-
-How to Re-Build the example
----------------------------
-
-Also source code for the example is included in the Processor SDK Linux
-release. Once installed the source files can be found in the directory
-example-applications/big-data-ipc-demo-linux_<version>.
-
-Prerequisites: Also need to have the Processor SDK RTOS release
-installed to build the DSP side RTOS image. See the instruction in :ref:`RTOS
-SDK Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-
-The example can be rebuilt by using the following commands.
-
-::
-
-       export TI_RTOS_PATH=<TI_RTOS_PROC_SDK_INSTALL_DIR>
-       make big-data-ipc-demo
-
-(e.g)
-
-::
-
-       export TI_RTOS_PATH=$HOME/ti
-       make big-data-ipc-demo
-
-The test binaries can be installed into the default filesystem using the
-command.
-
-::
-
-       make big-data-ipc-demo_install
-
-.. note::
-   Rules.make file can be edited to change the DESTDIR where the
-   binaries will be installed.
-
-Source files
-^^^^^^^^^^^^
-
-The source files for the example are located at
-
-::
-
-       <processor-sdk_linux-<platform>-<version>/example-applications/big-data-ipc-demo-linux-<version>/host_linux/simple_buffer_example.
-
-The host directory and dsp directory has the corresponding sources.
-The shared folder contains some common sources.
-The main sequence for big data IPC can be followed by looking at
-host/App.c and dsp/Server.c.
-|
-
-Memory layout details
-^^^^^^^^^^^^^^^^^^^^^
-
-The DSP side memory layout can be found in the file
-host_linux/simple_buffer_example/shared/<platform>/config.bld.
-Also note the addition of the following section in
-host_linux/simple_buffer_example/shared/<platform>/rsc_table_dsp.h.
-Please note the reserved carve-out in the DSP resource table
-
-.. note::
-   Make sure this matches what is configured in the linux device tree
-
-#. define DSP_CMEM_IOBUFS 0xA0000000
-#. define PHYS_CMEM_IOBUFS 0xA0000000
-#. define DSP_CMEM_IOBUFS_SIZE (SZ_1M \* 192)
-
-The CMEM area allocated from this region is used for the big data
-buffers.
-
-Host RTOS example
-=================
-
-Under the host_bios directory the simple_buffer_example is implemented
-for Host A15 and DSP both running TI RTOS/BIOS.
-
-How to Run the Example
-----------------------
-
-The Processor SDK RTOS release include the pre-built binaries for the
-host_bios example under:
-
-::
-
-       processor_sdk_<platform>_<version>/demos/bigdataipc/prebuilt-binaries/<board-name>/simple_buffer_example/release/
-
-Also for the platforms that support boot through SDcard, pre-built boot
-image or 'app' bootable through SBL is located under:
-
-::
-
-       processor_sdk_<platform>_<version>/demos/bigdataipc/prebuilt-binaries/bootimages/host_bios/simple_buffer_example/<board-name>/app
-
-AM57xx & K2G boards
-^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: Pre-requisites
-   :name: pre-requisites
-
-1. Create a bootable SDCard using the procedure here: :ref:`Creating SD card in Windows <Tools-Create-SD-Card-Windows-label>`
-or
-:ref:`Create SD card in Linux <Tools-Create-SD-Card-Linux-label>`
-
-2. Connect the UART on the hardware to the Host.
-( Configure the terminal/console to Baud Rate= 115200, Data Bits= 8 ,
-Parity= None, Flow Control= Off )
-
-.. rubric:: Procedure
-   :name: procedure
-
--  Copy/overwrite the pre-built boot image 'app' corresponding to the
-   board to a bootable SD Card
--  Insert the SD card into the board
--  Boot/Reboot the board
-
-The application will be loaded and run automatically and the "Host: Test
-Passed" message will be printed to the UART console.
-
-.. Image:: /images/BigDataIPC_Rtos_Demo.png
-
-K2H, K2K, K2L, K2E Boards
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The prebuilt elf binaries of Host and DSP images can be loaded through
-CCS to the appropriate cores and run.
-
-How to Re-Build the Example
----------------------------
-
-The bigdata ipc examples can be built from the Processor SDK top level
-directory using the following steps
-
-.. rubric:: 1. Build environment setup
-   :name: build-environment-setup
-
-.. rubric:: Linux host
-   :name: linux-host
-
-::
-
-       cd  <processor_sdk_<platform>_<version>
-       export SDK_INSTALL_PATH=<Base directory where Processor SDK is installed>
-       source setupenv.sh
-
-.. rubric:: Windows host
-   :name: windows-host
-
-::
-
-       cd  <processor_sdk_<platform>_<version>
-       set SDK_INSTALL_PATH=<Base directory where Processor SDK is installed>
-       setupenv.bat
-
-.. rubric:: 2. Build
-   :name: build
-
-::
-
-       make bigdataipc_examples
-
-This creates the elf binaries for both the host and DSP cores.
-And the binaries can be installed using
-
-::
-
-       make bigdataipc_examples_install
-
-(NOTE: The above command installs the elf binaries under the
-prebuilt-binaries location mentioned above.
-Need to convert the prebuilt elf binaries into bootable images refer
-to :ref:`Processor SDK RTOS Boot <FC-Boot-label>`)
-
-.. rubric:: Source files
-   :name: source-files-1
-
-The source files for the example are located at
-
-::
-
-       <processor_sdk_<platform>_<version>/demos/bigdataipc/host_bios/simple_buffer_example.
-
-The host directory and dsp directory has the corresponding sources.
-The shared folder contains some common sources.
-The main sequence for big data IPC can be followed by looking at
-host/App.c and dsp/Server.c.
-
diff --git a/source/rtos/Examples_and_Demonstrations/_CMB_AddOn.rst b/source/rtos/Examples_and_Demonstrations/_CMB_AddOn.rst
deleted file mode 100644
index 47e3975ec..000000000
--- a/source/rtos/Examples_and_Demonstrations/_CMB_AddOn.rst
+++ /dev/null
@@ -1,173 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_CMB_AddOn
-
-.. rubric:: Introduction
-   :name: introduction
-
-This page describes the Circular Microphone Board (CMB) Addon library
-and the unit test provided in the Processor-SDK for RTOS.
-
-The key functions in the CMB Addon library include:
-
--  Initialize the board connects to the CMB
--  Initialize/configure the McASP, EDMA, I2C and GPIO
--  Set up the CMB and on-board audio codec to the correct sample rate
-   and format
-
-The unit test demo utilizes other Processor SDK features/components:
-
--  **SYS/BIOS** application utilizing TI-RTOS features for DSP-C66x core
--  **UIA** for instrumentation logging
-
-Currently, the following devices and EVMs are supported:
-
--  K2G, on the K2G EVM. See TIDEP-0088
-   (http://www.ti.com/tool/TIDEP-0088) for details
--  OMAP-L137, on the OMAP-L137 EVM. See TIDEP-0099
-   ((http://www.ti.com/tool/TIDEP-0099)) for details
-
-.. rubric:: Requirements
-   :name: requirements
-
-The following materials are required to run this add-on unit test:
-
-Hardware
-
--  TI EVMs (see list above)
--  Circular Microphone Array Board (CMB)
--  OMAP-L137 Prototype Board (for OMAP-L137 EVM only)
-
-Software
-
--  Processor-SDK RTOS (4.0 or greater)
--  Code Composer Studio 6.1.3 and up
-
-.. rubric:: Software Design
-   :name: software-design
-
-.. rubric:: Framework for Unit Test
-   :name: framework-for-unit-test
-
-The current framework is based on SYS/BIOS. The following are the
-overall steps:
-
--  The McASP/EDMA will generate interrupt every 10ms (approximately)
--  The EDMA ISR will prepare the audio frame buffer pointers (McASP/EDMA
-   RX buffer) for further processing
--  The EDMA ISR will also send a semaphore to wake up the main task
--  When woke up, the main thread will perform the audio de-interleaving
-   to separate the channels
--  The main thread will also output two of eight channels to McASP/EDMA
-   TX buffer
--  The McASP/EDMA will send the TX buffer to the on-board audio codec
-
-.. rubric:: How to Build the CMB Library and Unit Test
-   :name: how-to-build-the-cmb-library-and-unit-test
-
-.. rubric:: K2G EVM
-   :name: k2g-evm
-
-**For Linux:**
-
--  Under pdk_k2g_1_x_x/packages directory, run the following commands:
-
-::
-
-      source ./pdksetupenv.sh
-      make cmb_clean
-      make cmb
-      the libraries will be in
-         pdk_k2g_1_x_x/packages/ti/addon/cmb/lib/k2g/c66/release
-      the OUT file (audioAnalogLoopbackTest.out) for DSP will be built at
-         pdk_k2g_1_x_x/packages/ti/addon/cmb/test/evmK2G/analog/loopback/build/make
-
-**For Windows:**
-
--  Under pdk_k2g_1_x_x/packages directory, run the following commands:
-
-::
-
-      pdksetupenv.bat
-      gmake cmb_clean
-      gmake cmb
-      the libraries will be in
-         pdk_k2g_1_x_x\packages\ti\addon\cmb\lib\k2g\c66\release
-      the OUT file (audioAnalogLoopbackTest.out) for DSP will be built at
-         pdk_k2g_1_x_x\packages\ti\addon\cmb\test\evmK2G\analog\loopback\build\make
-
-.. rubric:: OMAP-L137 EVM
-   :name: omap-l137-evm
-
-**For Linux:**
-
--  Under pdk_omapl137_1_x_x/packages directory, run the following
-   commands:
-
-::
-
-      source ./pdksetupenv.sh
-      make cmb_clean
-      make cmb
-      the libraries will be in
-         pdk_omapl137_1_x_x/packages/ti/addon/cmb/lib/omapl137/c674/release
-      the OUT file (audioAnalogLoopbackTest.out) for DSP will be built at
-         pdk_omapl137_1_x_x/packages/ti/addon/cmb/test/evmOMAPL137/analog/loopback/build/make
-
-**For Windows:**
-
--  Under pdk_omapl137_1_x_x\packages directory, run the following
-   commands:
-
-::
-
-      pdksetupenv.bat
-      gmake cmb_clean
-      gmake cmb
-      the libraries will be in
-         pdk_omapl137_1_x_x\packages\ti\addon\cmb\lib\omapl137\c674\release
-      the OUT file (audioAnalogLoopbackTest.out) for DSP will be built at
-         pdk_omapl137_1_x_x\packages\ti\addon\cmb\test\evmOMAPL137\analog\loopback\build\make
-
-.. rubric:: How to Run the Unit Test
-   :name: how-to-run-the-unit-test
-
-The unit test will be loaded onto the target using JTAG. After running
-the unit test, the 2 out of 8 input audio channels from CMB will be
-output to the line-out of the on-board audio codec.
-
-The following sections provide detailed steps for each EVM.
-
-.. rubric:: K2G EVM
-   :name: k2g-evm-1
-
--  Follow this link :ref:`Processor-SDK-RTOS-Setup-CCS-label`
-   to get target configuration setup correctly.
--  Connect to the on board emulator (J1 on K2G EVM) to your PC USB
--  Plug power adaptor(12V) into the K2G EVM and power on the EVM
--  Launch the ccxml created above using "Launch Selected Configuration"
-   from CCS 6.1.3
--  Then "Connect to C66xx_DSP"
--  Load the audioAnalogLoopbackTest.out from
-   pdk_k2g_1_x_x/packages/ti/addon/cmb/test/evmK2G/analog/loopback/build/make
--  Run the program (loaded previously) by pressing F8
--  The program will run the unit test forever, taking the input from CMB
-   and output to the on-board line-out
-
-.. rubric:: OMAP-L137 EVM
-   :name: omap-l137-evm-1
-
--  Follow this link :ref:`Processor-SDK-RTOS-Setup-CCS-label`
-   to get target configuration setup correctly.
--  Connect to the on board emulator (J201 on OMAP-L137 EVM) to your PC
-   USB
--  Plug power adaptor(5V) into the OMAP-L137 EVM and power on the EVM
--  Launch the ccxml created above using "Launch Selected Configuration"
-   from CCS 6.1.3
--  Then "Connect to C674X_0"
--  Load the audioAnalogLoopbackTest.out from
-   pdk_omapl137_1_x_x/packages/ti/addon/cmb/test/evmOMAPL137/analog/loopback/build/make
--  Run the program (loaded previously) by pressing F8
--  The program will run the unit test forever, taking the input from CMB
-   and output to the on-board line-out
-
-|
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Can_Eth_Gateway_Demo.rst b/source/rtos/Examples_and_Demonstrations/_Can_Eth_Gateway_Demo.rst
deleted file mode 100644
index e5f0cd724..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Can_Eth_Gateway_Demo.rst
+++ /dev/null
@@ -1,378 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_CAN_Eth_Gateway_Demo
-
-Overview
-========
-
-Gateway is one of the major use-cases in the modern cars. Performance
-requirements for Gateway applications are ever increasing due to advanced
-connected car architecture having multiple domain controllers. The CAN - Ethernet
-gateway demo showcases P2P (Protocol to Protocol) translation i.e. translating data
-and control information between incompatible networks like Ethernet and CAN for
-communication on AM65xx device. The demo enables full duplex
-routing between CAN and Ethernet (CAN to Ethernet & Ethernet to CAN).
-The gateway demo shows handling of high bandwidth data traffic on Cortex-R5 with
-low CPU load and latency for bridging application leaving cortex A53 free
-for application processing.
-
-Architecture Overview
-=====================
-
-The following block diagram shows the various functional blocks & the data flow
-used in the gateway application. As shown in the diagram the PC Ethernet
-applications are used for transmitting & receiving the Ethernet frames from/to
-PC, similarly for CAN message reception & transmission, any compatible CAN tool
-can be used.
-
-.. Image:: /images/can-eth-gateway.png
-   :height: 1000px
-   :width: 1500px
-   :scale: 50 %
-   :alt: can-to-eth data flow
-   :align: center
-
-Software Features
-=================
-
--  Routing application for CAN to Eth and Eth to CAN.
--  Network APIs for creating TCP/IP applications.
--  CPU load benchmark utils.
-
-Directory Structure
-===================
-
-The CAN_ETH Gateway demo is located in the Processor SDK RTOS
-release under the directory path
-
-::
-
-    [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gateway-demos/can-eth-gateway
-
-Detailed description of the directory structure is given below:
-
--  output - directory contains prebuilt out file and PC tools executables.
--  build - directory contains makefiles and SYSBIOS configuration, linker files for build
--  pctools - directory contains Ethernet PC tools
--  src - Source files for gateway application, utils and network APIs.
-
-.. note::
-
-    * Only Linux PC tools pre-built binaries are provided. For Windows, user needs
-      to build it locally.
-
-Components Used
-===============
-
-RTOS Components:
-
--  SYSBIOS
--  XDC
--  NDK
-
-Processor SDK RTOS Drivers:
-
--  EMAC
--  NIMU
--  UART
--  Board
--  OSAL
--  CSL
--  udma
--  sciclient
-
-Building the Demo
-=================
-
-The demo application is built using makefile. Also the demo is available pre-built
-for Processor SDK RTOS version 5.3.0.0 or higher.
-
-You must first set up your development environment. Refer to
-the `Processor SDK RTOS Building <index_overview.html#building-the-sdk>`__ page for
-information on setting up your build environment.
-
-The following are steps to clean the demo:
-
-::
-
-     cd [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gateway-demos/can-eth-gateway/build
-     make clean BOARD=am65xx_idk
-
-The following are steps to compile the demo:
-
-::
-
-     cd [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gateway-demos/can-eth-gateway/build
-     make all BOARD=am65xx_idk
-
-Host Applications
-==================
-
-The PC tools for Ethernet reception and transmission are located under pctools
-directory. These tools can be built for Linux and Windows.
-::
-
-     cd [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gateway-demos/can-eth-gateway/pctools
-     make all
-
-Running the Demo
-================
-
-You will need the following:
-
-+-----------------------+-------+
-| EVM's supported       | Bare  |
-|                       | metal |
-+=======================+=======+
-|  AM65xx EVM/IDK       |  No   |
-+-----------------------+-------+
-
-Tools
------
-#. CAN Receiver/Transmitter - PC tool to receive and transmit the CAN messages.
-#. LAN Cable (preferably CAT6)
-#. Gigabit switch connection - as mentioned in the known issues demo does not work
-   with 100Mbps mode. The gigabit connection is needed to AM65xx EVM.
-
-    .. note::
-
-        * PCAN - PC CAN Emulation tool is used for testing CAN_ETH Gateway demo.
-        * Refer section PCAN Tool Set up for more details.
-        * For receiving and transmitting data over Ethernet, use/run "eth_rx.out" and "eth_tx.out" utilities on host PC.
-        * Above utilities are available at "[SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gateway-demos/can-eth-gateway/pctools".
-
-Set up
-------
-
-#. Code Composer Studio to load and run the demo. Refer to :ref:`Processor
-   SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>` for
-   installing CCS.
-#. AM65xx_EVM board with attached LAN cable and CAN tool.
-#. USB cable for JTAG and serial terminal (micro USB port)
-#. Configure PC running Ethernet PC tools with below static IP
-    * IP Address = "192.168.1.20"
-    * Subnet mask = "255.255.255.0"
-    * Default Gateway = "192.168.1.1"
-
-
-    .. note::
-
-        You can enable DHCP for AM65xx board if PC is connected to network and static
-        IP configuration is not feasible. Set enableStaticIP flag to 1 in
-
-     ::
-
-        [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gateway-demos/can-eth-gateway/build/am65xx/nimuExample_r5.cfg
-
-AM65x EVM/IDK Board Set up
-----------------------------
-
-#. Adding Termination Resistors to the MCAN Interface
-
-    Reason for change
-        * The IDK Application board has two MCAN ports. The termination for the MCAN ports is not installed by default. If the termination is needed on the board, the following steps can be followed to add it.
-
-    Items Needed
-        * Two 120 ohm resistors in 0603 package
-
-    Modification
-        * Carefully remove the IDK application board by removing the four screws and gently separating the board from the connectors.
-        * On the top of the board, solder a 120 ohm resistor to the footprint for R252.
-
-        .. Image:: /images/am65x_evm_idk_board_changes_for_mcan_interface1.png
-          :height: 500px
-          :width: 800px
-          :scale: 50 %
-          :alt: can-to-eth data flow
-          :align: center
-
-        * On the bottom of the board, solder a 120 ohm resistor to the footprint for R130.
-
-        .. Image:: /images/am65x_evm_idk_board_changes_for_mcan_interface2.png
-          :height: 500px
-          :width: 800px
-          :scale: 50 %
-          :alt: can-to-eth data flow
-          :align: center
-
-        * Reinstall the IDK Application board and return the screws.
-
-PCAN Tool Set up
-----------------
-
-CAN FD adapter PCAN-USB FD allows the connection of CAN FD and CAN networks to a computer via USB.
-   Product details: https://www.peak-system.com/PCAN-USB-FD.365.0.html?&L=1
-
-#. Prerequisite (PC Setup):
-    * Download and install PCAN driver from: https://www.peak-system.com/quick/DrvSetup
-    * Download and install PCAN driver from: https://www.peak-system.com/quick/DrvSetup
-    * Download PCAN-View from: https://www.peak-system.com/fileadmin/media/files/pcanview.zip
-    * PCAN-View is a GUI based tool used to configure bit-rate of the PCAN tool. It provides a convenient was to see sent and received messages. It also provides an option to enable tracing of CAN messages along with timestamp
-    * Please refer to PCAN-USB FD manual for more details
-
-.. note::
-
-    Please check licensing information & terms of usage of PCAN-USB product and make sure it
-    adheres your organizations policy before downloading the drivers.
-
-#. PCAN Setup:
-    * Once driver is installed, connect PCAN to PC. It should be auto detected as ‘PCAN-USB FD’ in ‘Device Manager’. If it is not auto detected then re-install the PCAN driver
-    * Once it is detected in Device Manager, open PCAN-View and follow below steps
-        * Click on ‘Connect’ from ‘CAN’ menu (as shown in below figure)
-            * Popped up window shall show connected PCAN hardware. Select that device.
-            * Tick in the checkbox shown next to ‘Data Bit rate’
-                * This will enable Bit
-            * Select ‘Nominal Bit Rate’ as ‘1 MBits/s’
-            * Select ‘Data Bit Rate’ as ‘5 MBits/s’
-                * Bit rates may vary from use-case to use-case.
-            * Click on Ok button.
-
-            .. Image:: /images/pcan_view_device_selection.png
-               :height: 500px
-               :width: 500px
-               :scale: 50 %
-               :alt: can-to-eth data flow
-               :align: center
-
-        * Create and send message at period of 2sec
-            * Click on ‘New Message’ under ‘Transmit’ menu
-            * Tick the check box present next to ‘CAN FD’
-            * Tick the check box present next to ‘Bit Rate Switch’
-            * Give below parameters /inputs:
-                * ID as hex ‘004’
-                * Length as ‘64’
-                * Cycle Time as ‘2000’
-                * Data: as use-case needs
-
-            .. Image:: /images/CanEth_PCANViewTransmitMessageConfig.png
-               :height: 500px
-               :width: 600px
-               :scale: 50 %
-               :alt: can-to-eth data flow
-               :align: center
-
-#. Creating Bit Rate Configurations:
-    * Example for creating 5 Mbps bit rate configuration for ‘Data Bit Rate’(shown in below diagram)
-        * Click on ‘Connect’ under ‘CAN’ menu
-        * Tick in the checkbox shown next to ‘Data Bit rate’
-        * Click on Play button present below ‘Data Bit rate’ and then ‘Manage Bit rates’
-        * Click on ‘Data’ in newly popped window
-        * Select clock frequency as 80 MHz
-        * Click on ‘Add’ button
-        * Give caption as ‘5 MBits/s’
-        * Program ‘Prescalar’, ‘tseg1’, ‘tseg2’, ‘Sync Jump Width’ as ‘1’, ‘12’, ‘3’, ‘1’ respectively.
-        * Bit Rate text box shall show ‘5 Mbit/s’ after programming above values.
-        * Click on ‘Ok’ and then again on ‘Ok’
-
-    .. Image:: /images/CanEth_PCANViewBitRateConfig.png
-      :height: 500px
-      :width: 800px
-      :scale: 50 %
-      :alt: can-to-eth data flow
-      :align: center
-
-
-#. CAN Bus Connections:
-    * CAN_H of all the nodes on the bus shall be connected together
-    * Similarly CAN_L of all the nodes on the bus shall be connected together
-    * Please refer to ‘PCAN-USB FD manual’ for more details about connections.
-
-Load and run the demo
--------------------------
-
-#. Connect the USB cable from your computer to the AM65xx_EVM's JTAG port
-#. Power on the AM65xx_EVM board. Ensure that no boot mode is entered (do
-   not have SD card loaded or QSPI flashed)
-#. Open up a serial terminal for UART communication (Refer to :ref:`Processor
-   SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`, setup
-   EVM hardware)
-#. Open CCS and launch target config file for AM65xx_EVM (Refer to
-   `Processor SDK RTOS Setup CCS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__ for setting up CCS)
-#. Connect to MCU_PULSAR_Cortex_R5_0
-#. Load the System firmware as specified in SCICLIENT documentation
-#. Load and launch the demo executable:
-
-    ::
-
-     [PDK Install Path]/packages/ti/binary/gatewayapp/bin/am65xx_idk/gatewayapp_mcu1_0_release.xer5f
-
-#. The application print will be displayed on the CCS and UART console. The UART console used depends on the core in which the application is run.
-#. Confirm the network connectivity of PC with board.
-   ping 192.168.1.4
-
-CAN to ETH
-^^^^^^^^^^
-#. Connect the CAN PC tool.
-#. Start the Ethernet receive application
-
-    ::
-
-       ./eth_tx.exe[or eth_tx.out] 192.168.1.4
-
-#. Start CAN message transmission from the CAN tool with below information
-    * ID as hex ‘004’
-    * Length as ‘64’
-    * Cycle Time as ‘2000’
-    * Data can be any user specified data
-
-ETH to CAN
-^^^^^^^^^^
-
-#. Connect the CAN PC tool.
-#. Start the Ethernet transmit application
-
-    ::
-
-       ./eth_rx.exe[or eth_rx.out] --ip 192.168.1.4 [--port <portNum>] [--framerate <frames per seconds>]
-
-        port and framerate are optional
-
-#. Once Ethernet transmit application starts sending data out, CAN PC tool shall receive a CAN FD message with ID hex ‘009’
-
-Terminal Screen-shot
-====================
-
-Below is a terminal output after one simulation:
-
-::
-
-    Board_init success
-
-    GatewayApp: BOARD IP address I/F 1: 192.168.1.14
-
-    GatewayApp: Starting GATEWAY Tasks...
-    Gateway Tx: Server listening (port=1000) !!!
-
-    GatewayApp: Network Tx socket open done..
-    Gateway Tx: Server listening (port=2000) !!!
-
-    GatewayApp: Network Rx socket open done..
-    GatewayApp: CrossBar/Interrupt Configuration done.
-    GatewayApp: MCANSS Revision ID:
-    GatewayApp: scheme:0x1
-    GatewayApp: Business Unit:0x2
-    GatewayApp: Module ID:0x8e0
-    GatewayApp: RTL Revision:0x5
-    GatewayApp: Major Revision:0x1
-    GatewayApp: Custom Revision:0x0
-    GatewayApp: Minor Revision:0x1
-    GatewayApp: CAN-FD operation is enabled through E-Fuse.
-    GatewayApp: Endianess Value: 0x87654321
-
-    GatewayApp: MCAN Transmitter app started..
-
-    Received 0 Transmitted 0
-    LOAD: CPU: 0.6% HWI: 0.1%, SWI:0.1%
-    LOAD: TSK: Gateway Tx: 0.1%
-    MISC: 0.3%
-
-    GatewayApp: CAN stats - Received 500 Transmitted 500
-    LOAD: CPU: 6.6% HWI: 0.5%, SWI:0.1%
-    LOAD: TSK: Gateway Rx: 1.6%
-    LOAD: TSK: Gateway Tx: 0.6%
-    MISC: 3.8%
-
-Known issues & limitations
---------------------------
-#. Polling mode is not supported in the Gateway application.
-#. Re-transmission of failed CAN message is not supported.
-#. Ethernet 100Mbps is not supported. Gigabit only supported.
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Gravity_Simulator_Demo.rst b/source/rtos/Examples_and_Demonstrations/_Gravity_Simulator_Demo.rst
deleted file mode 100644
index 232ae5466..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Gravity_Simulator_Demo.rst
+++ /dev/null
@@ -1,132 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Gravity_Simulator_Demo
-
-Overview
-========
-
-This demo showcases a simple video display with Processor SDK RTOS. This
-demo uses Gravit, a GPL-licensed open-sourced library, to simulate
-gravity of particles in space.
-
-Version Details
-===============
-
-Latest version: 1.0.0
-
-Supported platforms: idkAM572x
-
-Available in: Processor SDK RTOS 4.0.0.4
-
-Components Used
-===============
-
-Open Sourced Libraries:
-
--  Gravit
-
-RTOS Components:
-
--  SYSBIOS
--  XDC
-
-Processor SDK RTOS Drivers:
-
--  VPS
--  PM
--  I2C
--  UART
--  Board
--  OSAL
--  CSL
-
-Building the Demo
-=================
-
-The demo is available pre-built for Processor SDK RTOS version 4.0.0.4
-or higher. You must first set up your development environment. Refer to
-the `Processor SDK RTOS Building <index_overview.html#building-the-sdk>`__ page for
-information on setting up your build environment.
-
-The following are steps to clean the demo:
-
-::
-
-     cd [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gravit
-     make clean BOARD=idkAM572x
-
-The following are steps to compile the demo:
-
-::
-
-     cd [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gravit
-     make BOARD=idkAM572x
-
-Running the Demo
-================
-
-You will need the following:
-
-#. Code Composer Studio to load and run the demo. Refer to :ref:`Processor
-   SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>` for
-   installing CCS.
-#. idkAM572x board with attached LCD screen
-#. USB cable for JTAG and serial terminal (micro USB port)
-
-To load and run the demo:
-
-#. Connect the USB cable from your computer to the idkAM572x's JTAG port
-#. Power on the idkAM572x board. Ensure that no boot mode is entered (do
-   not have SD card loaded or QSPI flashed)
-#. Open up a serial terminal for UART communication (Refer to :ref:`Processor
-   SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`, setup
-   EVM hardware)
-#. Open CCS and launch target config file for idkAM572x (Refer to
-   `Processor SDK RTOS Setup CCS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__ for setting up CCS)
-#. Connect to CortexA15_0
-#. Load and launch the demo executable:
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/demos/gravit/bin/idkAM572x/gravit_a15_0_release.xa15fg
-
-Terminal Screenshot
-===================
-
--  When launched, you will be prompt for number of particles to
-   simulate. Enter a value up to 1000.
--  Use w-a-s-d for display rotation
--  Use i-j-k-l for display translation
--  Press Esc to end current simulation and display accumulated
-   statistics
--  Frames per second (FPS) and floating point operations per second
-   (FLOPS) are displayed on the terminal
-
-Below is a screenshot of the terminal after one simulation:
-
-.. Image:: /images/Gravit-screenshot_version_01_00_00.png
-
-Display Output
-==============
-
--  Particles are set to rotate around a gravity center positioned at the
-   center of the LCD screen
--  Particles are represented with 3D coordinates, projected to a 2D LCD
-   screen. The projection is simplified such that the camera (or the
-   viewer) does not change display angles.
-
-Below is an example display of a 500-particle simulation:
-
-.. Image:: /images/Gravit-displayshot_version_01_00_00.jpg
-
-Useful References
-=================
-
-Main Gravit website: https://gravit.slowchop.com/
-
-Gravit github: https://github.com/gak/gravit
-
-Physics algorithm behind gravit, Barnes-hut:
-`https://en.wikipedia.org/wiki/Barnes-Hut_simulation <https://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation>`__
-
-Bresenham's line algorithm:
-`https://en.wikipedia.org/wiki/Bresenham's_line_algorithm <https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm>`__
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Image_Processing_Demo.rst b/source/rtos/Examples_and_Demonstrations/_Image_Processing_Demo.rst
deleted file mode 100644
index 349f5a23c..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Image_Processing_Demo.rst
+++ /dev/null
@@ -1,436 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Image_Processing_Demo
-
-Introduction
-============
-
-This page describes the image processing demo provided in the
-Processor-SDK for RTOS. This demo illustrates the integration of key
-components in the SDK and provides a framework for application
-development.
-
-The use case implemented is the transfer of image data from/to DDR and
-internal memory. Typically, images are large and need to be stored in
-external memory. Key functions include
-
--  Operates on different segments of the same image in different cores
--  Operates across multiple cores executing different algorithms on the
-   same image data
--  Transfers input/output image to a medium (SD card or external system)
--  Utilize IPC to communicate between cores to perform an image
-   processing task parallel
-
-This demo utilizes many SDK features/components:
-
--  **Multi-core** application utilizing ARM-A15 and DSP-C66x cores
--  **IMGLIB** for optimized C66x image processing
--  **IPC** for interprocessor communication
--  **NDK** application utilizing NDK for internet access
--  **UIA** for instrumentation logging
-
-This demo is not available for all devices. Currently, the following
-devices and EVM are supported:
-
--  AM57x, on the AM572x GP EVM
--  C665x, on the C665x EVM
--  C667x, on the C667x EVM
--  K2H, on the K2H EVM
-
-.. note::
-   For AM572x EVM, only the SD card boot option (via SBL) is current supported.
-
-.. note::
-   This demo has been only verified with the Google Chrome along with the 100Mbit router with DHCP
-
-
-Requirements
-============
-
-The following materials are required to run this demonstration:
-
-Hardware
-
--  TI EVM (see list above)
--  Local Area Network with DHCP support
--  JTAG Emulator (on board or external)
-
-Software
-
--  Processor-SDK RTOS
--  Code Composer Studio
-
-|
-
-Software Design
-===============
-
-More about processing algorithms
---------------------------------
-
-The application will use IMGLIB APIs for its core image processing
-needs. The following steps are performed for edge detection:
-
--  Split input image into multiple overlapping slices
--  If it is a RGB image, separate out the Luma component (Y) for
-   processing (See `YCbCr <http://en.wikipedia.org/wiki/Ycbcr>`__ for
-   further details)
--  Run `Sobel operator <http://en.wikipedia.org/wiki/Sobel_operator>`__
-   (IMG_sobel_3x3_8) to get the gradient image of each slices
--  Run the thresholding operation ( IMG_thr_le2min_8) on the slices to
-   get the edges
--  Combine the slices to get the final output
-
-Framework for multicore
------------------------
-
-The current framework for multicore is IPC (Message Queue). The
-following are the overall steps (the master and threads will be run on
-one or more cores):
-
--  The master thread will preprocess the input image to make a gray
-   scale or luma image
--  The master thread signal each slave thread to start processing and
-   wait for processing complete signal from all slave threads
--  The slave threads run edge detection function to generate output edge
-   image of the slice
--  Then the slave threads signal master thread indicating the processing
-   completed
--  Once master thread receives completion signal from all threads it
-   proceeds with further user interface processing
-
-|
-
-How to Build the Demo
----------------------
-
-AM572x GP EVM
-^^^^^^^^^^^^^
-
-**For Linux:**
-
--  Under ~/ti/processor_sdk_rtos_am57xx_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      source ./setupenv.sh
-      make demo_clean
-      make demo
-      the OUT files for A15, DSP1 and DSP2 will be built at
-         ~/ti/processor_sdk_rtos_am57xx_x_0x_xx_xx/demos/image_processing/ipc/evmam572x/host/build,
-         ~/ti/processor_sdk_rtos_am57xx_x_0x_xx_xx/demos/image_processing/ipc/evmam572x/dsp1/build, and
-         ~/ti/processor_sdk_rtos_am57xx_x_0x_xx_xx/demos/image_processing/ipc/evmam572x/dsp2/build respectively
-
-**For Windows:**
-
--  Under C:\\ti\\processor_sdk_rtos_am57xx_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      setupenv.bat
-      gmake demo_clean
-      gmake demo
-      the OUT files for A15, DSP1 and DSP2 will be built at
-         C:\ti\processor_sdk_rtos_am57xx_x_0x_xx_xx\demos\image_processing\ipc\evmam572x\host\build,
-         C:\ti\processor_sdk_rtos_am57xx_x_0x_xx_xx\demos\image_processing\ipc\evmam572x\dsp1\build, and
-         C:\ti\processor_sdk_rtos_am57xx_x_0x_xx_xx\demos\image_processing\ipc\evmam572x\dsp2\build respectively
-
-C6657 EVM
-^^^^^^^^^
-
-**For Linux:**
-
--  Under ~/ti/processor_sdk_rtos_c665x_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      source ./setupenv.sh
-      make demo_clean
-      make demo
-      the OUT files for DSPs will be built at
-         ~/ti/processor_sdk_rtos_c665x_x_0x_xx_xx/demos/image_processing/ipc/evmc6657l/master/build,
-         ~/ti/processor_sdk_rtos_c665x_x_0x_xx_xx/demos/image_processing/ipc/evmc6657l/slave/build respectively
-
-**For Windows:**
-
--  Under C:\\ti\\processor_sdk_rtos_c665x_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      setupenv.bat
-      gmake demo_clean
-      gmake demo
-      the OUT files for DSPs will be built at
-         C:\ti\processor_sdk_rtos_c665x_x_0x_xx_xx\demos\image_processing\ipc\evmc6657l\master\build,
-         C:\ti\processor_sdk_rtos_c665x_x_0x_xx_xx\demos\image_processing\ipc\evmc6657l\slave\build respectively
-
-C6678 EVM
-^^^^^^^^^
-
-**For Linux:**
-
--  Under ~/ti/processor_sdk_rtos_c667x_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      source ./setupenv.sh
-      make demo_clean
-      make demo
-      the OUT files for DSPs will be built at
-         ~/ti/processor_sdk_rtos_c667x_x_0x_xx_xx/demos/image_processing/ipc/evmc6678l/master/build,
-         ~/ti/processor_sdk_rtos_c667x_x_0x_xx_xx/demos/image_processing/ipc/evmc6678l/slave/build respectively
-
-**For Windows:**
-
--  Under C:\\ti\\processor_sdk_rtos_c667x_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      setupenv.bat
-      gmake demo_clean
-      gmake demo
-      the OUT files for DSPs will be built at
-         C:\ti\processor_sdk_rtos_c667x_x_0x_xx_xx\demos\image_processing\ipc\evmc6678l\master\build,
-         C:\ti\processor_sdk_rtos_c667x_x_0x_xx_xx\demos\image_processing\ipc\evmc6678l\slave\build respectively
-
-K2H EVM
-^^^^^^^
-
-**For Linux:**
-
--  Under ~/ti/processor_sdk_rtos_k2hk_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      source ./setupenv.sh
-      make demo_clean
-      make demo
-      the OUT files for A15, DSPs will be built at
-         ~/ti/processor_sdk_rtos_k2hk_x_0x_xx_xx/demos/image_processing/ipc/evmk2hk/master/build,
-         ~/ti/processor_sdk_rtos_k2hk_x_0x_xx_xx/demos/image_processing/ipc/evmk2hk/slave/build respectively
-
-**For Windows:**
-
--  Under C:\\ti\\processor_sdk_rtos_k2hk_x_0x_xx_xx directory, run the
-   following commands:
-
-::
-
-      setupenv.bat
-      gmake demo_clean
-      gmake demo
-      the OUT files for A15, DSPs will be built at
-         C:\ti\processor_sdk_rtos_k2hk_x_0x_xx_xx\demos\image_processing\ipc\evmk2hk\master\build,
-         C:\ti\processor_sdk_rtos_k2hk_x_0x_xx_xx\demos\image_processing\ipc\evmk2hk\slave\build respectively
-
-|
-
-How to Run the Demo
--------------------
-
-AM572x GP EVM (Using CCS)
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The CCS is used to load the program and run on ARM-A15 (HOST), C66x Core
-1 (DSP1) and C66x Core 2 (DSP2) by following the steps below:
-
--  Launch CCS and connect to AM572 GP EVM using proper target
-   configuration
--  Connect to CortexA15_0 (Host) [Push "Power" button right before
-   connect to CortexA15_0]
-
-.. Image:: /images/Am572x_connect_a15.jpg
-
--  Connect to C66xx_DSP1
-
-.. Image:: /images/Am572x_connect_dsp1.jpg
-
--  Connect to C66xx_DSP2
-
-.. Image:: /images/Am572x_connect_dsp2.jpg
-
--  Load image_processing_evmam572x_dsp1.out to C66xx_DSP1 using JTAG
-
-.. Image:: /images/Am572x_load_dsp1.jpg
-
--  Run image_processing_evmam572x_dsp1.out on C66xx_DSP1
--  Load image_processing_evmam572x_dsp2.out to C66xx_DSP2 using JTAG
-
-.. Image:: /images/Am572x_load_dsp2.jpg
-
--  Run image_processing_evmam572x_dsp2.out on C66xx_DSP2
--  Loaded image_processing_evmam572x_host.out to CortexA15_0
-
-.. Image:: /images/Am572x_load_host.jpg
-
--  Run image_processing_evmc6678l_master.out on CortexA15_0
--  The HOST will display the IP address on CCS CIO
-
-.. Image:: /images/Am572x_cio.jpg
-
--  Users can use internet browser to access this IP address
--  The Image Processing Demo page will be displayed
--  Provide values for the "Number of Cores" and "Select Image to
-   Process" fields
-
-.. Image:: /images/Am572x_web_1.jpg
-
-The HOST will read the image via NDK, partition it according to the
-number of cores, send the messages to DSP cores (Slaves) via IPC
-MessageQ. The DSP cores will start processing the partitioned images
-concurrently. The resulting output image will be stored in DDR and the
-HOST will be notified by DSP cores via IPC MessageQ. Subsequently, the
-HOST will write the input and output images to the Image Processing Demo
-page using NDK.
-
-.. Image:: /images/Am572x_web_2.jpg
-
-|
-
-AM572x GP EVM (Using SBL)
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The SBL is used to load the program from SD card and run on ARM-A15
-(HOST), C66x Core 1 (DSP1) and C66x Core 2 (DSP2) by following the steps
-below:
-
--  Copy "app" and "MLO" from
-   processor_sdk_rtos_am57xx_x_0x_00_0x\\prebuilt-sdcards\\evmAM572x\\sd_card_files
-   on Windows or
-   processor_sdk_rtos_am57xx_x_0x_00_0x/prebuilt-sdcards/evmAM572x/sd_card_files
-   on Linux to the root directory of a formatted micro SD card
--  Plug in the micro SD card into uSD slot on AM572x GP EVM
--  Connect "Serial Debug" on AM572x GP EVM to a PC USB port via a
-   "Serial to USB" cable
--  Launch a terminal emulator like Tera Term and open the local COM port
-   corresponding to the "Serial Debug" (Set it to 115200 bps, 8 bit,
-   none parity, one bit stop, no flow control)
--  Plug power adapter (12V) into the AM572x GP EVM (DC-In) and power on
-   the EVM
--  There the IP address will be displayed on the "Serial Debug"
--  Users can use internet browser to access this IP address
--  The Image Processing Demo page will be displayed
--  Provide values for the "Number of Cores" and "Select Image to
-   Process" fields
-
-.. Image:: /images/Am572x_web_1.jpg
-
-The HOST will read the image via NDK, partition it according to the
-number of cores, send the messages to DSP cores (Slaves) via IPC
-MessageQ. The DSP cores will start processing the partitioned images
-concurrently. The resulting output image will be stored in DDR and the
-HOST will be notified by DSP cores via IPC MessageQ. Subsequently, the
-HOST will write the input and output images to the Image Processing Demo
-page using NDK.
-
-.. Image:: /images/Am572x_web_2.jpg
-
-C6678 EVM or C6657 EVM
-^^^^^^^^^^^^^^^^^^^^^^
-
-CCS is used to load the program and Core 0 will be configured as the
-host. The following steps show C667x but a similar process applies for
-C665x.
-
--  Launch CCS and connect to C6678 EVM using proper target configuration
--  Connect to C66x Core 0 (Host)
-
-.. Image:: /images/C6678_connect_core0.jpg
-
--  Loaded image_processing_evmc6678l_master.out to C66x Core 0
-
-.. Image:: /images/C6678_load_master.jpg
-
--  Run image_processing_evmc6678l_master.out on C66xx_0
--  Group C66x Core 1-N into a group (Group 1, Slave)
--  Connect to Group 1
-
-.. Image:: /images/C6678_connect_group1.jpg
-
--  Load image_processing_evmc6678l_slave.out to Group 1 using JTAG
-
-.. Image:: /images/C6678_load_slave.jpg
-
--  Run image_processing_evmc6678l_slave.out on Group 1
--  The HOST will display the IP address on CCS CIO
-
-.. Image:: /images/C6678_cio.jpg
-
--  Users can use internet browser to access this IP address
--  The Image Processing Demo page will be displayed
--  Provide values for the "Number of Cores" and "Select Image to
-   Process" fields
-
-.. Image:: /images/Demo_web_page_1.jpg
-
-The HOST will read the image via NDK, partition it according to the
-number of cores, send the messages to DSP cores (Slaves) via IPC
-MessageQ. The DSP cores will start processing the partitioned images
-concurrently. The resulting output image will be stored in DDR and the
-HOST will be notified by DSP cores via IPC MessageQ. Subsequently, the
-HOST will write the input and output images to the Image Processing Demo
-page using NDK.
-
-.. Image:: /images/Demo_web_page_2.jpg
-
-K2H EVM
-^^^^^^^
-
-CCS is used to load the program and arm_A15_0 will be configured as the
-master and C66xx_0 - C66xx_7 will be configured as slaves.
-
--  Launch CCS and connect to K2H EVM using proper target configuration
--  Connect to arm_A15_0 (Host)
-
-.. Image:: /images/K2h_connect_a15.jpg
-
--  Group C66xx_0 to C66xx_7 into a group (Group 1, Slaves)
-
-.. Image:: /images/K2h_from_group1.jpg
-
--  Connect to Group 1
-
-.. Image:: /images/K2h_connect_group1.jpg
-
--  Load image_processing_evmk2hk_slave.out to Group 1 using JTAG
-
-.. Image:: /images/K2h_load_group1.jpg
-
--  Run image_processing_evmk2hk_slave.out on Group 1
-
-.. Image:: /images/K2h_run_group1.jpg
-
--  Loaded image_processing_evmk2hk_master_arm.out to arm_A15_0
-
-.. Image:: /images/K2h_load_a15.jpg
-
--  Run image_processing_evmk2hk_master_arm.out on arm_A15_0
-
-.. Image:: /images/K2h_run_a15.jpg
-
--  The HOST will display the IP address on CCS CIO
-
-.. Image:: /images/K2h_cio.jpg
-
--  Users can use internet browser to access this IP address
--  The Image Processing Demo page will be displayed
--  Provide values for the "Number of Cores" and "Select Image to
-   Process" fields
-
-.. Image:: /images/K2h_web_1.jpg
-
-The HOST will read the image via NDK, partition it according to the
-number of cores, send the messages to DSP cores (Slaves) via IPC
-MessageQ. The DSP cores will start processing the partitioned images
-concurrently. The resulting output image will be stored in DDR and the
-HOST will be notified by DSP cores via IPC MessageQ. Subsequently, the
-HOST will write the input and output images to the Image Processing Demo
-page using NDK.
-
-.. Image:: /images/K2h_web_2.jpg
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Interrupt_Latency_Benchmark.rst b/source/rtos/Examples_and_Demonstrations/_Interrupt_Latency_Benchmark.rst
deleted file mode 100644
index dd871bfaa..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Interrupt_Latency_Benchmark.rst
+++ /dev/null
@@ -1,166 +0,0 @@
-.. http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_examples_demos.html#interrupt-latency-benchmark
-
-Introduction
-============
-
-This page describes the interrupt latency benchmark provided in the
-Processor-SDK for RTOS. This benchmark gives several options for
-different types of load configurations.
-
-This benchmark runs on:
-
--  AM572x (A15)
-
-The sections below provide details of the application as well as build
-and run instructions.
-
-Requirements
-============
-
-The following materials are required to run this demonstration:
-
-Hardware
-
--  TI EVM (see list above)
--  Micro USB cable (provided in EVM kit)
-
-Software
-
--  Processor-SDK RTOS
--  Code Composer Studio
-
-Software Design
-===============
-
-The purpose of this benchmark is to measure the worst case interrupt
-latency under load. This load is achieved by simultaneously running
-a modified version of the Dhrystone benchmark.
-
-Dhrystone
----------
-
-The Dhrystone code is modified to run continuously. Instead of testing
-the host system for DMIPS, Dhrystone threads are created repeatedly
-until the benchmark completes. Essentially, once a Dhrystone thread
-finishes, it is created again. Additionally, the user can specify the
-number of Dhrystone threads to be created.
-
-Interrupt Latency Benchmark
----------------------------
-
-Several design choices were made when creating the interrupt latency
-benchmark.
-
--  The benchmark task is set to core 0
-    * Core 0 is the A15_0 core,
-      and is the primary core for the benchmark. The benchmark is forced to
-      operate only on this core, no matter the load. This is achieved by setting
-      the affinity of the task parameter to 0
--  The benchmark task needs to have a higher priority than the Dhrystone threads
-    * If the Dhrystone threads have a priority level that is greater
-      than or equal to the benchmark task priority, then the scheduler will schedule
-      the two to execute one after another. Thus, the benchmark task will not run
-      while the Dhrystone thread is running, but the timer will continue to fire.
-      As a result, the benchmark task is stalled and returns invalid data when it
-      resumes
--  Results are printed to the UART
-    * A UART-based menu has been implemented on the main UART
-
-How to Build the Demo
-=====================
-
-Processor-SDK RTOS
-------------------
-
-To build the project, navigate to the benchmark’s directory and
-run "gmake clean" and then "gmake all" on windows, or "make
-clean" and "make all" on Linux.
-
-::
-
-     <PROC_SDK_INSTALL_PATH>/benchmarks/interrupt_latency
-
-
-
-
-How to Run the Demo
-===================
-
-After building the benchmark, locate the binary under the relevant
-device directory in the interrupt latency benchmark's bin/ directory.
-Additionally, power on the board, connect the micro-USB cable to the
-UART port, and begin a UART console.
-
-::
-
-    <PROC_SDK_INSTALL_PATH>/benchmarks/interrupt_latency/bin/<soc>/
-
-
-CCS
----
-
-To run the benchmark on AM572xx using CCS, use the following steps.
-
-#. Using CCS, launch the target configuration for the EVM CCS-Target
-   Configurations (http://software-dl.ti.com/ccs/esd/documents/ccs_custom_target_config.html)
-#. In the CCS debug view, create a sync group (http://software-dl.ti.com/ccs/esd/documents/ccs_smp-debug.html)
-   with the A15 cores
-#. For each core, connect to it and load the binary. The A15_0
-   core should halt at main while the SMP linked cores will begin
-   auto-running upon load
-#. Once all cores have been loaded, run them all
-#. The output will be sent to the UART console in real time
-#. You must manually halt the cores to end the benchmark
-
-.. note::
-   -  If running in non-SMP mode, do not create a sync group. Only
-      load and run the binary on the A15_0 core
-
-Secondary Bootloader (SBL)
---------------------------
-
-To run the benchmark on a micro-SD card, follow the
-corresponding steps for AM57x (http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#am57x)
-
-.. note::
-   -  The binary is the same format as a .out file
-
-Known Issues and Limitations
-============================
-
-When running the benchmark, keep in mind the following
-issues which are still being fixed.
-
-#. The cause for several outliers in the data is being
-   investigated
-
-Results
-=======
-
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   |           AM572x           | SMP Disabled          | SMP Disabled          | SMP Disabled          | SMP Enabled           | SMP Enabled           | SMP Enabled           |
-   |                            | Dhrystone Disabled    | Dhrystone Enabled     | Dhrystone Enabled     | Dhrystone Disabled    | Dhrystone Enabled     | Dhrystone Enabled     |
-   |                            |                       | One Dhry Thread       | Two Dhry Threads      |                       | One Dhry Thread       | Two Dhry Threads      |
-   +============================+=======================+=======================+=======================+=======================+=======================+=======================+
-   | **HW Interrupt Latency**   |                       |                       |                       |                       |                       |                       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Average Max**            |        0.602 us       |        0.576 us       |        0.579 us       |        1.159 us       |        1.150 us       |        1.063 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Average Min**            |        0.572 us       |        0.572 us       |        0.572 us       |        1.121 us       |        1.102 us       |        1.040 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Absolute Max**           |        1.510 us       |        1.354 us       |        1.354 us       |        2.916 us       |        2.916 us       |        3.385 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Absolute Min**           |        0.572 us       |        0.572 us       |        0.572 us       |        1.041 us       |        0.885 us       |        0.885 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Semaphore Wake Latency** |                       |                       |                       |                       |                       |                       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Average Max**            |        1.281 us       |        1.329 us       |        1.281 us       |        2.645 us       |        2.665 us       |        2.812 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Average Min**            |        1.249 us       |        1.250 us       |        1.250 us       |        2.581 us       |        2.551 us       |        2.657 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Absolute Max**           |        2.968 us       |        2.812 us       |        2.812 us       |        5.625 us       |        5.468 us       |        7.500 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-   | **Absolute Min**           |        1.093 us       |        1.250 us       |        1.250 us       |        2.343 us       |        2.343 us       |        2.343 us       |
-   +----------------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Jailhouse_Hypervisor.rst b/source/rtos/Examples_and_Demonstrations/_Jailhouse_Hypervisor.rst
deleted file mode 100644
index c818437de..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Jailhouse_Hypervisor.rst
+++ /dev/null
@@ -1,1170 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_Jailhouse_Hypervisor
-
-.. rubric:: Overview
-   :name: overview
-
-Jailhouse is a static partitioning hypervisor that runs bare metal
-binaries. It cooperates closely with Linux. Jailhouse doesn't emulate
-resources that don't exist. It just splits existing hardware resources
-into isolated compartments called "cells" that are wholly dedicated to
-guest software programs called "inmates". One of these cells runs the
-Linux OS and is known as the "root cell". Other cells borrow CPUs and
-devices from the root cell as they are created.
-
-|
-.. Image:: /images/Jailhouse.png
-
-*The picture above shows the jailhouse on a system a) before the
-jailhouse is enabled; b) after the jailhouse is enabled; c) after a cell
-is created.
-*
-
-|
-
-Jailhouse consists of three parts: kernel module, hypervisor firmware
-and tools, which a user uses to enable the hypervisor, create a cell,
-load inmate binary, run and stop it. Jailhouse is an example of
-Asynchronous Multiprocessing (AMP) architecture. When we boot Linux on
-AM57XX-EVM, which has 2 ARM cores, Linux uses the both cores. After we
-enable hypervisor it moves Linux to the root-cell. The root cell still
-uses the both ARM cores. When we create a new cell, hypervisor calls
-cpu_down() for the ARM1 core, leaving for Linux ARM0 only. The new cell
-will use the ARM1 core and hardware resources dedicated for this cell in
-the cell configuration file.
-
-|
-
-Jailhouse is an open source project, which can be found on
-https://github.com/siemens/jailhouse.
-
-|
-
-.. rubric:: Demo
-   :name: demo
-
-| Processor Linux SDK delivers Jailhouse’s prebuilt binaries. You may
-  try it immediately after installation. This section assumes that you
-  have already installed PSDK, and have Linux booted on the AM572X-EVM
-  or AM572x-IDK.
-
-| **NOTE:** *to use Jailhouse hypervisor*
-
-| *1) set u-boot environment variable optargs*: setenv optargs
-  vmalloc=512M
-
-*2) use \ **am572x-evm-jailhouse.dtb** for AM572x-EVM
-or \ **am572x-idk-jailhouse.dtb** for AM572x-IDK
-*
-
-|
-
-.. rubric:: Pre-built components
-   :name: pre-built-components
-
-| As it was mentioned in the previous section, Jailhouse consists of
-  following components, which are prebuilt and copied to the target
-  filesystem:
-
-#. jailhouse.ko kernel module located at
-   /lib/modules/4.9.28-<gitid>/extra/driver directory;
-#. jailhouse.bin - hypervisor itself located at /lib/firmware directory;
-#. Jailhouse management tools are located at
-   /usr/local/libexec/jailhouse and /usr/sbin directories;
-
-In order to create the root-cell and an inmate cell we need to provide
-cell configuration files. Those configuration files and example binaries
-are located at /usr/share/jailhouse/examples directory:
-
-::
-
-    root@am57xx-evm:/usr/share/jailhouse/examples# ls -1
-    am572x-rtos-icss.cell
-    am572x-rtos-pruss.cell
-    am57xx-evm-ti-app.cell
-    am57xx-evm.cell
-    am57xx-pdk-leddiag.cell
-    icss_emac.bin
-    led_test.bin
-    linux-loader.bin
-    pruss.bin
-    ti-app.bin
-
-where
-
--  **am57xx-evm.cell** - root cell configuration file;
--  **ti-app.bin** and **am57xx-evm-ti-app.cell** - bare metal inmate and
-   its cell configuration;
--  **led_test.bin** and **am57xx-pdk-leddiag.cell** - PDK led_test
-   inmate example and its cell configuration (led_test.bin can be run on
-   AM572x-EVM only);
--  **pruss.bin** and **am572x-rtos-pruss.cell** - TI-RTOS PRUSS inmate
-   examples and its cell configuration (pruss.bin can be run on
-   AM572x-IDK only);
--  **icss_emac.bin** and **am572x-rtos-icss.cell** - TI-RTOS ICSS-EMAC
-   inmate example and its cell configuration (icss_emac.bin can be run
-   on AM572x-IDK only);
--  **linux-loader.bin** - loader required to run inmates, which start
-   address is not 0x0;
-
-|
-
-.. rubric:: Running the Demo on AM572x-EVM
-   :name: running-the-demo-on-am572x-evm
-
-.. rubric:: Running bare-metal ti-app.bin
-   :name: running-bare-metal-ti-app.bin
-
-Here are the steps to run the demo:
-
--  Boot the Linux
--  Insert jailhouse.ko kernel module
-
-::
-
-    root@am57xx-evm:~# modprobe jailhouse
-
--  Enable the hypervisor using am57xx-evm.cell root-cell configuration
-   file
-
-::
-
-    root@am57xx-evm:~# jailhouse enable /usr/share/jailhouse/examples/am57xx-evm.cell
-    Initializing Jailhouse hypervisor v0.6 on CPU 1
-    Code location: 0xf0000030
-    Page pool usage after early setup: mem 30/4073, remap 32/131072
-    Initializing processors:
-     CPU 1... OK
-     CPU 0... OK
-    Page pool usage after late setup: mem 39/4073, remap 38/131072
-    Activating hypervisor
-    [ 4155.880217] The Jailhouse is opening.
-
--  Create a cell for the inmate
-
-::
-
-    root@am57xx-evm:~# jailhouse cell create /usr/share/jailhouse/examples/am57xx-evm-ti-app.cell
-    [ 5270.449687] CPU1: shutdown
-    [ 5270.453221] NOHZ: local_softirq_pending 20
-    Created cell "AM57XX-EVM-timer8-demo"
-    Page pool usage after cell creation: mem 51/4073, remap 38/131072
-    [ 5270.487970] Created Jailhouse cell "AM57XX-EVM-timer8-demo"
-
--  Load the ti-app.bin inmate binary
-
-::
-
-    root@am57xx-evm:~# jailhouse cell load 1 /usr/share/jailhouse/examples/ti-app.bin
-    Cell "AM57XX-EVM-timer8-demo" can be loaded
-
--  Start the binary
-
-::
-
-    root@am57xx-evm:~# jailhouse cell start 1
-    Hey, I'm working !!!!!!!!!!!
-    timer id 4fff2b01
-    timer value fffffc17; irq status 00000002; raw 00000002
-    min 00000017; avr 0000001b; max 000002c1
-    min 00000017; avr 0000001b; max 000000f3
-    min 00000017; avr 0000001b; max 000002c8
-    min 00000017; avr 0000001b; max 00000148
-    min 00000017; avr 0000001b; max 000002d4
-    min 00000017; avr 0000001b; max 00000158
-
-**NOTE**: *becase all of the components: root-cell, hypervisor and demo
-inmate use the same UART, there is a conflict. Once the inmate started
-to use the UART, Linux stops getting any input from console. To
-workaround this and continue to control the hypervisor, you may telnet
-to the EVM and issue all commands from the telnet shell. Hypervisor
-still will use Linux console to print it sdebug messages*
-
--  Stop the binary
-
-::
-
-    root@am57xx-evm:~# jailhouse cell shutdown 1
-
-**NOTE**: *You may restore Linux console by killing the "/bin/login --"
-process from telnet session.*
-
--  destroy cell
-
-::
-
-    root@am57xx-evm:~# jailhouse cell destroy 1
-    Closing cell "AM57XX-EVM-timer8-demo"
-    Page pool usage after cell destruction: mem 39/4073, remap 38/131072
-    [ 6201.111168] Destroyed Jailhouse cell "AM57XX-EVM-timer8-demo"
-
--  disable hypervisor
-
-::
-
-    root@am57xx-evm:~# jailhouse disable
-    Shutting down hypervisor
-     Releasing CPU 0
-     Releasing CPU 1
-    [ 6248.149728] The Jailhouse was closed.
-
-**NOTES**:
-
-You may shutdown and start the same binary multiple times. Every time
-you start the binary, it starts from the beginning.
-
-If you have different binaries which use the same cell resources, you
-may reuse the created cell to run them. You need just shutdown the cell,
-load another binary and start it. If you need to run different binaries
-that requires different resources, you need to shutdown the running
-cell, destroy it, create a new one with required resources, load a new
-binary and start it.
-
-.. rubric:: Running PDK led_test.bin example
-   :name: running-pdk-led_test.bin-example
-
-After you enable hyprevisor, create a pdk cell  
-
-::
-
-    root@am57xx-evm:~# jailhouse cell create /usr/share/jailhouse/examples/am57xx-pdk-leddiag.cell
-    [  312.419978] CPU1: shutdown
-    Created cell "AM57XX-EVM-PDK-LED"
-    Page pool usage after cell creation: mem 54/4075, remap 38/131072
-    [  312.470723] Created Jailhouse cell "AM57XX-EVM-PDK-LED"
-    root@am57xx-evm:~#
-
-| load the led_test.bin binary
-
-::
-
-    root@am57xx-evm:~# jailhouse cell load 1 /usr/share/jailhouse/examples/led_test.bin
-    Cell "AM57XX-EVM-PDK-LED" can be loaded
-
-and start it
-
-::
-
-    root@am57xx-evm:~# jailhouse cell start 1
-    Started cell "AM57XX-EVM-PDK-LED"
-    root@am57xx-e
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: r
-
-    Blinking again
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: y
-    Received: y
-
-    Test PASSED!
-
-You may see blinking leds, press "r" to repeat the test.
-
-| **NOTE:**
-| This example just demonstrates hypervisor's ability to run binaries
-  that were built outside of jailhouse source tree. This and other RTOS
-  examples were ported for this purpose. Look to RTOS SDK documentation
-  for description of the examples functionality.  
-
-.. rubric:: Running the Demo on AM572x-IDK
-   :name: running-the-demo-on-am572x-idk
-
-Two TI-RTOS example applications were ported for Jailhouse hypervisor:
-pruss.bin and icss_emac.bin. In contrast to led_test.bin, which has its
-own startup code, linker script and was linked to start from address
-0x0, the pruss.bin and icss_emac.bin used the TI-RTOS building
-infrustructure as much as possible. Therefore they are linked to EVM's
-DDR address space (starting from 0x80000000 ) and their entry points are
-not 0x0. To support loading and running such applicaiton a special
-command shell be used.
-
-To run the pruss.bin applicaton enable the hypervisor the same way as
-for other examples.
-
-::
-
-    cd /usr/share/jailhouse/examples/
-    root@am57xx-evm:/usr/share/jailhouse/examples# modprobe jailhouse
-    root@am57xx-evm:/usr/share/jailhouse/examples# jailhouse enable ./am57xx-evm.cell
-
-    Initializing Jailhouse hypervisor  on CPU 0
-    Code location: 0xf0000030
-    Page pool usage after early setup: mem 30/4075, remap 32/131072
-    Initializing processors:
-     CPU 0... OK
-     CPU 1... OK
-    Page pool usage after late setup: mem 39/4075, remap 38/131072
-    Activating hypervisor
-    [  710.008555] The Jailhouse is opening.
-
-Create a cell for pruss.bin
-
-::
-
-    root@am57xx-evm:/usr/share/jailhouse/examples# jailhouse cell create ./am572x-rtos-pruss.cell
-    [  745.067783] CPU1: shutdown
-    Created cell "AM572X-IDK-PRUSS"
-    Page pool usage after cell creation: mem 54/4075, remap 38/131072
-    [  745.107324] Created Jailhouse cell "AM572X-IDK-PRUSS"
-    root@am57xx-evm:/usr/share/jailhouse/examples#
-
-Use cell load command to load several required components:
-
-::
-
-    root@am57xx-evm:/usr/share/jailhouse/examples# jailhouse cell load 1 linux-loader.bin -a 0 -s "kernel=0x80005128" -a 0x100 pruss.bin -a 0x80000000
-    Cell "AM572X-IDK-PRUSS" can be loaded
-
-where
-
--  linux-loader.bin is a small application provided and built by
-   jailhouse source tree. As you can see (-a 0) it is loaded to virtual
-   address 0x0;
--  "-s "kernel=0x80005128" -a 0x100" - is the linux_loader argument
-   loaded as string to virtual address 0x100, which instructs the
-   linux-loader to branch to the pruss.bin 0x80005128 entry point;
--  pruss.bin itself, loaded to the virtual address 0x80000000 - the
-   address where this application is lined to;
-
-|
-| After loading run the inmate as usual:
-
-::
-
-    root@am57xx-evm:/usr/share/jailhouse/examples# jailhouse cell start 1
-    Started cell "AM572X-IDK-PRUSS"
-    root@am57xx-evm:/usr/share/jailhouse/examples# passed verify constant tbl entry for instance 1: pruNum: 0
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 0
-    eventwait: got the INTC event from PRU, count: 1
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 0
-    eventwait: got the INTC event from PRU, count: 2
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 0
-    eventwait: got the INTC event from PRU, count: 3
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 0
-    eventwait: got the INTC event from PRU, count: 4
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 0
-    eventwait: got the INTC event from PRU, count: 5
-    eventwait: waiting for the INTC event from PRU
-    Testing for instance: 1, pru num: 0 is complete
-    passed verify constant tbl entry for instance 1: pruNum: 1
-    sending the INTC event to the PRU for instance: 1 , pru num: 1
-    eventwait: got the INTC event from PRU, count: 1
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 1
-    eventwait: got the INTC event from PRU, count: 2
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 1
-    eventwait: got the INTC event from PRU, count: 3
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 1
-    eventwait: got the INTC event from PRU, count: 4
-    eventwait: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 1 , pru num: 1
-    eventwait: got the INTC event from PRU, count: 5
-    Testing for instance: 1, pru num: 1 is complete
-    passed verify constant tbl entry for instance 2: pruNum: 0
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 0
-    eventwait2: got the INTC event from PRU, count: 1
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 0
-    eventwait2: got the INTC event from PRU, count: 2
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 0
-    eventwait2: got the INTC event from PRU, count: 3
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 0
-    eventwait2: got the INTC event from PRU, count: 4
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 0
-    eventwait2: got the INTC event from PRU, count: 5
-    eventwait2: waiting for the INTC event from PRU
-    Testing for instance: 2, pru num: 0 is complete
-    passed verify constant tbl entry for instance 2: pruNum: 1
-    sending the INTC event to the PRU for instance: 2 , pru num: 1
-    eventwait2: got the INTC event from PRU, count: 1
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 1
-    eventwait2: got the INTC event from PRU, count: 2
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 1
-    eventwait2: got the INTC event from PRU, count: 3
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 1
-    eventwait2: got the INTC event from PRU, count: 4
-    eventwait2: waiting for the INTC event from PRU
-    sending the INTC event to the PRU for instance: 2 , pru num: 1
-    eventwait2: got the INTC event from PRU, count: 5
-    Testing for instance: 2, pru num: 1 is complete
-    All tests have passed
-
-|
-| You may run the **icss_emac.bin** in similar way using appropriate
-  cell configuration. **Note that icss_emac has different entry point -
-  0x80000000**.
-
-.. rubric:: Jailhouse Performance on AM5728
-   :name: jailhouse-performance-on-am5728
-
-To verify the real-time performance of Jailhouse Sitara AM5728 was setup
-to run Linux on one of the ARM Cortex A15 cores, and a TI-RTOS inmate on
-the other A15 core. A test was run to measure interrupt latency. Poll
-mode driver based application performance of an inmate should be
-identical to a system without virtualizationion in a static partitioning
-system like Jailhouse. Anything interrupt based is required to share the
-interrupt controller (GIC) which will introduce some interference from
-Linux to the real-time application. The measurements shown below over a
-million interrupts clearly shows the interference, and captures the
-upper bound at 8.8us. For the first run of interrupt latency test an
-unloaded Linux running on core 0 is in the first column. In the second
-column Linux on core 0 is running STREAM. STREAM is an external memory
-access benchmark that fully utilizes the number of outstanding reads and
-writes to memory. It is scalable from individual processors to clusters
-supercomputers, here it is used at the processor level. It was chosen as
-representative of a worst case memory access behaviour of a Linux based
-application on a Cortex A15, essentially with a memory access profile
-like an optimized memorytomemory copy. In AM5728 the two Cortex A15
-cores share L2 cache and access to the rest of the SoC, which the STREAM
-benchmark running on core 0 stresses while core 1 access GIC registers
-to respond to the interrupt.
-
-|
-
-.. table::  **Interrupt latency of a bare metal inmate (core 1)**
-
-   +-----------------------+-----------------------+-----------------------+
-   |                       | Unloaded Linux on     | Linux Running STREAM  |
-   |                       | core 0                | benchmark on core 0   |
-   +=======================+=======================+=======================+
-   | | Interrutp count     | 99.3756%              | 33.9323%              |
-   | | Bucket 1.6 us - 3.2 |                       |                       |
-   |   us                  |                       |                       |
-   +-----------------------+-----------------------+-----------------------+
-   | | Interrutp count     | 0.6244%               | 66.0632%              |
-   | | Bucket 3.2 us - 6.4 |                       |                       |
-   |   us                  |                       |                       |
-   +-----------------------+-----------------------+-----------------------+
-   | | Interrutp count     | none                  | 0.0045%               |
-   | | Bucket 6.4 us -     |                       |                       |
-   |   12.8 us             |                       |                       |
-   +-----------------------+-----------------------+-----------------------+
-   | Minimum interrupt     | 2.2 microseconds      | 1.8 microseconds      |
-   | latency               |                       |                       |
-   +-----------------------+-----------------------+-----------------------+
-   | Maximim interrupt     | 5.0 microseconds      | 8.8 microseconds      |
-   | latency               |                       |                       |
-   +-----------------------+-----------------------+-----------------------+
-
-|
-
-|
-
-.. rubric:: Building Jailhouse from Sources
-   :name: building-jailhouse-from-sources
-
-Jailhouse sources are located at
-$TI_SDK_PATH/board-support/extra-drivers/jailhouse-0.7 directory. The
-directory contains the following subdirectories:
-
--  **Documentation**
--  **ci** - configuration files for different platforms. ***Copy the
-   jailhouse-config-am57xx-evm.h file into hypervisor/include/jailhouse
-   directory and rename it to config.h***
--  **configs** - cell configuration files.
--  **driver** - jailhouse.ko kernel module code
--  **hypervisor** - hypervisor code
--  **inmates** - inmates demos. It also contains code for ti_app inmate
-   example.
--  **scripts**
--  **tools** - jailhouse management utility
-
-The top level SDK Makefile has the *jailhouse_clean*, *jailhouse* and
-*jailhouse_install* targets which can be used to clean, build and
-install jailhouse to the target file system.
-
-|
-
-.. rubric:: Building and Running the Ethercat Slave Demo
-   :name: building-and-running-the-ethercat-slave-demo
-
-To build and run the Ethercat Slave Demo, you need to install the
-PSDK-RT, PRSDK and PRU-ICSS-ETHERCAT-SLAVE builds. We assume that you
-already have the first two SDKs installed. The PRU-ICSS-ETHERCAT-SLAVE
-can be downloaded from
-http://software-dl.ti.com/processor-industrial-sw/esd/PRU-ICSS-ETHERCAT-SLAVE/01_00_05_00/index_FDS.html.
-
-Once you have this SDK installed you may build Ethercat slave
-components.
-
-If the am572x-ethercat.cell is not installed on target filesystem yet,
-build it from PSDK-RT top level makefile "make jailhouse" and copy it
-to target under /usr/share/jailhouse/examples.
-
-To build the ethercat_slave_demo.bin:
-
--  Modify the IA_SDK_HOME at
-   ~/ti/processor_sdk_rtos_am57xx_[version]/demos/jailhouse-inmate/rtos/ethercat_slave_demo/Makefile
-   to point to the install directory of PRU-ICSS-ETHERCAT-SLAVE.
--  At
-   ~/ti/processor_sdk_rtos_am57xx_[version]/demos/jailhouse-inmate/makefile:
-   add ethercat_slave_demo\* entries as pruss-test/icss-emac-test to the
-   end of the makefile
-
-::
-
-    ethercat_slave_demo:
-        $(MAKE) -C ./rtos/ethercat_slave_demo
-
-    ethercat_slave_demo_clean:
-        $(MAKE) -C ./rtos/ethercat_slave_demo clean
-
-    ethercat_slave_demo_install:
-        $(MAKE) -C ./rtos/ethercat_slave_demo install
-
--  cd ~/ti/processor_sdk_rtos_am57xx_[version]/
--  source setupenv.sh
--  cd ~/ti/processor_sdk_rtos_am57xx_[version]/demos/jailhouse-inmate
--  source setenv.sh
--  make ethercat_slave_demo
-
-After the steps above, copy ethercat_slave_demo.bin to target under
-/usr/share/jailhouse/examples.
-
-To run the inmate refer to the instructions for `**Running the Demo on
-AM572x-IDK** <#Running_the_Demo_on_AM572x-IDK>`__ . Be aware that the
-inmate start address is 0x80000000. So, you need to use it as a
-parameter at the "jailhouse cell load" command:
-
-::
-
-    jailhouse cell load 1 linux-loader.bin -a 0 -s "kernel=0x80000000" -a 0x100 ethercat_slave_demo.bin -a 0x80000000
-
-|
-| Procedure to check two-way communication between the slave inmate and
-  the master station:
-
--  Refer to
-   http://processors.wiki.ti.com/index.php/PRU_ICSS_EtherCAT#Running_EtherCAT_Slave_Application
-   to setup Ethercat master.
--  Master: Online write [data] to RxPDO 32Bit Output. After this, the
-   slave should report the corresponding value via Board_setDigOutput.
-   The value can be checked with “devmem2 0xeef00000” also.
--  Slave: devmem2 0xeef00004 b [data]. After this, Master should display
-   the corresponding value in TXPDO 32Bit Input.
-
-|
-
-.. rubric:: Jailhouse Internals
-   :name: jailhouse-internals
-
-This section gives some Jailhouse details and required kernel
-modifications.
-
-.. rubric:: Linux Kernel Modifications
-   :name: linux-kernel-modifications
-
-In order to run hypervisor itself and inmates Jailhouse requires
-additional nodes in kernel dtb. See the am572x-evm-jailhouse.dts and
-am572x-idk-jailhouse.dts. They add required nodes or modify existing
-nodes of the default am57xx-evm-reva3.dts and am57xx-idk.dts DTS files.
-
-.. rubric:: Memory Reservation
-   :name: memory-reservation
-
-Linux kernel has to reserve some memory for jailhouse hypervisor and for
-inmate. This memory has to be reserver statically. In this release we
-reserved 16MB of physical memory for hypervisor and 16MB for inmates.
-
-::
-
-    / {
-
-        reserved-memory {
-            jailhouse: jailhouse@ef000000 {
-                reg = <0x0 0xef000000 0x0 0x1000000>;
-                no-map;
-                status = "okay";
-            };
-
-            jh_inmate: jh_inmate@ee000000 {
-                reg = <0x0 0xee000000 0x0 0x1000000>;
-                no-map;
-                status = "okay";
-            };
-        };
-    };
-
-.. rubric:: Hardware Modules Reservation
-   :name: hardware-modules-reservation
-
-Linux kernel enables all SOC HW modules which are required for its
-configuration. Appropriate drivers configure required clocks and
-initialize HW registers. For all unused IPs clocks are not configured.
-Also kernel power management can put a module into the sleep mode. A
-jailhouse inmate doesn't share the same hardware module with Linux
-kernel (except debug UART). But the inmate doesn't configure required
-clocks and doesn't deal with power domains. So, we still relay on Linux
-kernel (at least at the current release) to configure clocks to inmate
-HW modules. If we want to use some hardware modules for an inmate, we
-have to tell kernel about this in advance.
-
-The following nodes disable using of the timer8 and uart9 by kernel.
-Also this restricts kernel to put those IPs to sleep mode.
-
-::
-
-    &timer8 {
-        status = "disabled";
-        ti,no-idle;
-    };
-
-    &uart9 {
-        status = "disabled";
-        ti,no-idle;
-    };
-
-You may see other nodes in the jailhouse DTSes which reserve other IPs
-to be used for inmates. Thus IDK's DTS disables nodes, which IPs are
-used for icss_emac and pruss inmates.
-
-.. rubric:: GIC Interrupt Inputs Reservation
-   :name: gic-interrupt-inputs-reservation
-
-Interrupt lines from hardware modules don't go to ARM interrupt
-controller (GIC) directly. They go to a crossbar register, which selects
-a GIC distributor input. The selection is done dynamically by Linux
-kernel. Linux keeps track of all used and unused GIC inputs. If a
-jailhouse inmate has to use an interrupt, it has to configure the
-crossbar register by itself. To prevent conflicts between the Linux
-crossbar manager and the inmate, and give to the inmate some unused GIC
-input lines, which it can use, we need to reserve some of them in the
-kernel dts.
-
-This can be done by adding GIC input numbers to the "ti,irqs-skip"
-property of the "crossbar_mpu:" node. Lines 134 and 135 are added to the
-following node.
-
-::
-
-           crossbar_mpu: crossbar@4a002a48 {
-                ti,irqs-skip = <10 133 134 135 139 140>;
-            };
-
-| **Note:** The icss_emac.bin application uses much more interrupt
-  lines. Thats is why IDK's dtb skips aditional interrupts.
-
-::
-
-            crossbar_mpu: crossbar@4a002a48 {
-                ti,irqs-skip = <10 44 127 129 133 134 135 136 137 139 140>;
-            };
-
-.. rubric:: Root-cell configuration
-   :name: root-cell-configuration
-
-When hypervisor is being enabled it creates a cell for Linux and moves
-it to that cell. The cell is called as "root-cell". The cell
-configuration as a "*.c" file which is compiled to a special binary
-format "*.cell" file. The hypervisor uses the "cell" file to create a
-cell. The cell configuration describes memory regions and their
-attributes which will be used by the cell,
-
-::
-
-       .mem_regions = {
-            /* OCMCRAM */ {
-                .phys_start = 0x40300000,
-                .virt_start = 0x40300000,
-                .size = 0x80000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_IO,
-            },
-            /* 0x40380000 - 0x48020000 */ {
-                .phys_start = 0x40380000,
-                .virt_start = 0x40380000,
-                .size = 0x7ca0000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_IO,
-            },
-            /* UART... */ {
-                .phys_start = 0x48020000,
-                .virt_start = 0x48020000,
-                .size = 0xe0000,//0x00001000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_IO,
-            },
-          ...
-            /* RAM */ {
-                .phys_start = 0x80000000,
-                .virt_start = 0x80000000,
-                .size = 0x6F000000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_EXECUTE,
-            },
-            /* Leave hole for hypervisor */
-
-            /* RAM */ {
-                .phys_start = 0xF0000000,
-                .virt_start = 0xF0000000,
-                .size = 0x10000000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_EXECUTE,
-            },
-
-bitmap of CPU cores dedicated for the cell,
-
-::
-
-    .cpus = {
-            0x3,
-        },
-
-bitmap of interrupt controller SPI interrupts
-
-::
-
-       .irqchips = {
-            /* GIC */ {
-                .address = 0x48211000,
-                .pin_base = 32,
-                .pin_bitmap = {
-                    0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
-                },
-            },
-            /* GIC */ {
-                .address = 0x48211000,
-                .pin_base = 160,
-                .pin_bitmap = {
-                    0xffffffff, 0, 0, 0
-                },
-            },
-        },
-
-and some other parameters. That is for all cells.
-
-In addition to that the root cell also allocates the physical memory for
-the hypervisor.
-
-::
-
-           .hypervisor_memory = {
-                .phys_start = 0xef000000,
-                .size = 0x1000000,
-            },
-
-The "memory regions" section is used by hypervisor to create the second
-stage MMU translation table. Usually for root-cell the identical mapping
-is being used - "VA = PA".
-
-See the am57xx-evm.c file is the complete am57xx-evm root cell
-configuration.
-
-.. rubric:: Bare Metal Inmate Example
-   :name: bare-metal-inmate-example
-
-Jailhouse comes with inmate demos located at the *inmates/demos*
-directory. Current (v0.6) version has two demo inmates: **gic-demo** and
-**uart-demo**. Those are very simple bare-metal applications that
-demonstrates a uart and arm-timer interrupt. Those demos are common for
-all jailhouse platforms.
-
-More interesting may be the **ti-app**, a demo made especially for
-AM572x SOC. The code is located at the *inmate/ti_app* directory.
-
-Basically this application is a sandbox to make some experiments. The
-current version demonstrates of using a uart, timer and a GIC SPI
-interrupt (timer generates periodic interrupts). The application also
-has some extra code, which was used to measure interrupt latency.
-
-|
-
-As any inmate the ti-app inmate works in a cell. The am57xx-evm-ti-app.c
-is the cell configuration file. For this cell only ARM1 core will be
-used:
-
-::
-
-       .cpus = {
-            0x2,
-        },
-
-**NOTE:** *Actually on am572 SOC, which has only 2 ARM core and Linux
-always uses the ARM0 core only ARM1 can be taken for an inmate.*
-
-The cell configuration has 5 memory regions:
-
-::
-
-           /* UART... */ {
-                .phys_start = 0x48020000,
-                .virt_start = 0x48020000,
-                .size = 0x1000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
-            },
-            /* UART... */ {
-                .phys_start = 0x48424000,
-                .virt_start = 0x48424000,
-                .size = 0x1000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
-            },
-            /* TIMER... */ {
-                .phys_start = 0x48826000,
-                .virt_start = 0x48826000,
-                .size = 0x1000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
-            },
-            /* L4_CFG */ {
-                .phys_start = 0x4a000000,
-                .virt_start = 0x4a000000,
-                .size = 0xE00000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
-            },
-            /* RAM */ {
-                .phys_start = 0xee000000,
-                .virt_start = 0,
-                .size = 0x800000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
-            },
-
-Two for UARTs. *The first one for UART3, which is a standard EVM debug
-uart. The second for UART9, using of which requires some board
-modifications. But UART9 doesn't conflict with Linux or hypervisor and
-may be more useful if the inmate needs a dedicated UART.* One region for
-timer9 and one for access multiple configuration registers.
-
-The last region is for RAM allocated for the inmate. Similar to
-root-cell memory regions configuration memory mapping for all regions
-except for RAM are identical (VA = PA). For the RAM region virtual
-address has to be '0'. The physical addresses of the region must be
-inside of the physical memory reserved for inmates in the Linux DTS
-file.
-
-In the .irqchip section of the cell configuration file we reserve GIC
-interrupt line #134 (*One of two lines reserved in the kernel DTS*).
-
-::
-
-
-        /* GIC */ {
-            .address = 0x48211000,
-            .pin_base = 160,
-            .pin_bitmap = {
-                0x00000040,
-            },
-        },
-
-*Here where #134 comes from. The 0x00000040 is the bitmask of the sixth
-bit. So, .pin_base(160) + .pin_bitmap(6) - 32(number of SWI and PPI
-interrupt) = 134.*
-
-As other jailhouse demos the **ti-app** uses the jailhouse startup code,
-which sets the inmate vector table, zeros BSS segment, sets the stack up
-and calls the inmate_main(). The initialization of the GIC controller is
-done by hypervisor. Also the hypervisor remaps GICC interface to GICV
-interface and intercepts all inmates accesses to GICD. It allows to
-read/write only GICD registers, related to the lines given in the
-.irq_chips section. In our case for the line #134 only.
-
-In the inmate_main() the inmate initializes uart, sets the crossbar and
-calls the gic_setup() to set the inmate's interrupt handler. *The
-jailhouse provides inmate interrupt controller API. This can be used by
-inmate.*
-
-The ti-app initializes the timer and enters to the infinite loop.
-
-Actually the inmate code has only about 100 lines and doesn't require
-any more explanation.
-
-.. rubric:: RTOS PDK Inmates
-   :name: rtos-pdk-inmates
-
-The jailhouse demo applications and the "ti_app" are built by
-jailhouse's makefile inside the jailhouse's source tree. It is more
-interesting to build an inmate outside of the jailhouse source tree,
-using independent makefile and third party libraries. This release
-provides **led_test**, a simple example of a bare-metal application,
-which uses prebuilt RTOS PDK libraries and is built independently on
-Jailhouse. It also has ports of two TI RTOS SYSBIOS test applications -
-pruss and icss_emac. *There are two other examples: 1) bare-metal
-memcp_bm - a simple application to measure memory bandwidth; 2)
-Ethercat_slave_demo - ported to Jailhouse example from "PRU-ICSS
-Industrial Software for Sitara™ Processors". The example requires some
-modifications of the PRU-ICSS Industrial Software, which is not
-published yet. That is why the ethercat_slave_demo included here as a
-reference only.*
-
-The code of the applications is located on the
-$(SDK_INSTALL_PATH)/processor_sdk_rtos_am57xx_4_01_00_04/demos/jailhouse-inmate
-directory, which contains:
-
-::
-
-    ├── baremetal
-    │   ├── led
-    │   │   ├── led_test.c
-    │   │   └── makefile
-    │   ├── memcp_bm
-    │   │   ├── makefile
-    │   │   └── memcp_bm.c
-    │   └── soc
-    │       └── am572x
-    │           ├── evmAM572x
-    │           │   ├── entry.S
-    │           │   ├── gic.c
-    │           │   ├── linker.cmd
-    │           │   └── make.inc
-    │           └── rules.mk
-    ├── makefile
-    ├── rtos
-    │   ├── ethercat_slave_demo
-    │   │   ├── bios
-    │   │   │   ├── am572x_app.cfg
-    │   │   │   └── makefile
-    │   │   ├── Makefile
-    │   │   └── src
-    │   │       └── board_jh.c
-    │   ├── icss_emac
-    │   │   ├── bios
-    │   │   │   ├── icss_emac_arm_wSoCLib.cfg
-    │   │   │   └── makefile
-    │   │   ├── lnk_pruss_fw.cmd
-    │   │   ├── Makefile
-    │   │   └── src
-    │   │       ├── idkAM572x_ethernet_config_jh.c
-    │   │       └── idkAM572x_jh.c
-    │   ├── pru-icss
-    │   │   ├── bios
-    │   │   │   ├── makefile
-    │   │   │   └── pruss_arm_wSoCLib.cfg
-    │   │   ├── Makefile
-    │   │   └── src
-    │   │       └── idkAM572x_jh.c
-    │   └── Rules.mk
-    └── setenv.sh
-
-.. rubric:: Bare-metal example
-   :name: bare-metal-example
-
-The bare-metal directory has three subdirectories: **soc** - has common
-for bare-metal applications soc specific code; **led** - led_test
-application code; **memcp_bm** - memcp_bm code;
-
-The **soc/am572x/evmAM572x** sub-directory contains:
-
--  **entry.S** - startup file for an inmate;
--  **gic.c** - has the dummy \_weak\_ INTCCommonIntrHandler(), which can
-   be overridden by an actual application handler.
--  **linker.cmd** - jailhouse requires that an inmate shall start from
-   address "0". It also requires that all inmates segments be located in
-   contiguous memory. This linker.cmd is to meet these requirements.
-
-The **led** directory contains:
-
--  The main inmate **led_test.c** code. This file is based on
-   $(SDK_INSTALL_PATH)/pdk_am57xx_1_0_6/packages/ti/board/diag/led/src/led_test.c
-   diagnostic application. Because the inmate works as a virtual machine
-   in order to use caches MMU has to be enabled. So, the application
-   creates the MMU translation table with identical mapping and enables
-   MMU. It also has the gic_init(), which is now used at this relese.
--  **makefile** is to build the inmate. As you can see, it links number
-   of brebuilt PDK libraries.
-
-|
-| To build the **led_test.bin** (a jailhouse inmate has to be \*.bin,
-  but not \*.out file):
-
--  cd to $(SDK_INSTALL_PATH)/processor_sdk_rtos_am57xx_4_01_00_04
-   drectory
--  source setupenv.sh
--  cd to
-   $(SDK_INSTALL_PATH)/processor_sdk_rtos_am57xx_4_01_00_04/demos/jailhouse-inmates
--  source setenv.sh
--  run **make led_test**
-
-That should build the led_test.bin binary, that can be loaded to the
-jailhouse cell and run. As any other inmate it has to be run in a cell,
-created with appropriate cell configuration. In contrast to the
-led_test.bin, which is compiled independently on jailhouse, a
-corresponding cell configuration is compiled by jailhouse makefile.
-
-The am57xx-pdk-leddiag.c cell configuration file is located in the
-$TI_SDK_PATH/board-support/extra-drivers/jailhouse-0.7/configs
-directory. Use the compiled am57xx-pdk-leddiag.cell file when you create
-the cell for led_test.bin inmate.
-
-See `Running the Demo <#Running_the_Demo>`__ to run the inmate.
-
-The **memcp_bm** is very similar to led_test. It is built in the same
-way as the led_test. Use the am57xx-bm.cell file from
-$TI_SDK_PATH/board-support/extra-drivers/jailhouse-0.7/configs to create
-the jailhouse cell for the memcp_bm inmate.
-
-|
-
-.. rubric:: RTOS BIOS Examples
-   :name: rtos-bios-examples
-
-| The pruss and icss_emac examples are located in the rtos/pruss and
-  rtos/icss_emac directories. The structures of the both directories are
-  identical. Each directory contains the bios and src subdirectories.
-  The bios contains XDC type application configuration file and
-  makefile. The configuration file is reworked copy of the original RTOS
-  application configuration file. For example the configuration file for
-  icss_emac inmate was ported from
-  $(SDK_INSTALL_PATH)/ti/pdk_am57xx_1_0_7/packages/ti/drv/icss_emac/test/am572x/armv7/bios/icss_emac_arm_wSoCLib.cfg
-  file. As far as jailhouse inmate is not responsible for board related
-  configuration, the board library, i2c library, OCRAM MMU sections and
-  some other unnecessary for the inmate components were removed from the
-  configuration file.
-
-| As far as the application main function calls the board_init()
-  function, this function as well as the Board_moduleClockInit() (with
-  required for icss_emac application clocks) are implemented in the
-  idkAM572x_jh.c file.
-
-| Thus the ported configuration file, the idkAM572x_jh.c and makefiles
-  are only new files required to port RTOS SDK existing project to
-  jailhouse inmate.
-
-The jailhouse-inmate/Makefile has the "pruss_test" and "icss_emac_test"
-targets to build the BIOS inmates.
-
-The structure of the ethercat_slave_demo example is very similar to the
-pruss and icss_emac examples. As far as it depends on a particular
-version of the "PRU-ICSS Industrial Software", which has to be installed
-independently, building of the demo is not included into the top level
-makefile.
-
-|
-
-.. rubric:: RTOS BIOS Porting Notes
-   :name: rtos-bios-porting-notes
-
-As you can see in the previous section, the RTOS BIOS inmates has only
-few new files. Almost all files were reused from RTOS SDK examples. But
-following notes have to be considered when porting an RTOS BIOS
-application to a Jailhouse inmate.
-
-Jailhouse inmate runs in a small cell. The cell is created by
-hypervisor, which was started from already booted Linux OS. That says
-that the SOC, board and most clocks are already initialized and the
-inmate don't need and usually cannot touch any resources not listed in
-the inmate cell configuration file.
-
-Thus the using of board and i2c libraries were removed from
-cponfiguration file. Also OCRAM was removed from MMU configuration.
-
-Jailhouse hypervisor allows inmate to access certain GICD registers, but
-only for those interrupt lines, which are listed in the cell
-configuration file. The cell creating routine reconfigures GICD target
-registers by itself. The standard gic_init() BIOS API configures target
-registers for all interrupt lines. That is not permitted for an inmate.
-To avoid this the latest SYSBIOS release has a special feature, which
-allows to disable target configuration from GIC initialization function.
-See the following fragment at the configuration file:
-
-::
-
-    var Hwi = xdc.useModule('ti.sysbios.family.arm.gic.Hwi');
-    Hwi.initGicd = false;
-
-The RTOS BIOS applications are built to \*.out format. RTOS loader may
-load this file to the board even if the image has multiple sections with
-their addresses spread across the entire SOC address range. The
-Jailhouse supports only \*.bin format, and inmate may use only allocated
-for it memory carved out from Linux. Therefore the ported application
-shall use only limited memory.
-
-Jailhouse may start an inmate that start from virtual address 0x0, but
-an usual RTOS application is linked to the 0x80000000 address and with
-different from that entry point. The Jailhouse allows to start such
-applications (see above). But using the linux-loader required additional
-node in the inmate cell configuration.
-
-::
-
-           /* RAM loader */ {
-                .phys_start = 0xed000000,
-                .virt_start = 0x0,
-                .size = 0x10000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
-            },
-            /* RAM RTOS 224MB*/ {
-                .phys_start = 0xe0000000,
-                .virt_start = 0x80000000,
-                .size = 0xd000000,
-                .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-                    JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
-            },
-
-| You may see that cell configuration for icss_emac inmate configures
-  two RAM regions:
-
-#. small one with virtual address 0x0 for the linux-loader;
-#. main region for the icss_emac test itself;
-
-|
-
-.. rubric:: General Porting Notes
-   :name: general-porting-notes
-
-When you start porting your RTOS or bare-metal application to Jailhouse
-inmate, you have to consider several things. They are listed below.
-*This list is not complete and has just recommendations based on common
-sense and previous porting experience*.
-
--  **Linux always starts first** before hypervisor. Linux initializes
-   all (or almost all) common resources of SOC. Thus it initializes
-   memory controller, clocks, interrupt controller etc. It configures
-   PINMUX registers. In most cases it takes care about board
-   configuration as well.
-
--  **Inmate Cell Configuration** defines resources, which are available
-   for the inmate. The ported application can use only those resources
-   and responsible for theirs initialization only. The ported
-   application will not run on the board it used to run, but on a
-   different **virtual board**, defined by the cell configuration. Thats
-   is why the application cannot use any common board_init or soc_init
-   functions that may touch used by Linux resources. **Inmate is a guest
-   only**.
-
--  As it mentioned above Linux initializes **Interrupt Controller** and
-   dynamically configures crossbar registers. It has to be planned ahead
-   which interrupts inmate may use. Those interrupts has to be reserved
-   at Linux's dts file. Also used by the inmate interrupts have to
-   listed in the inmate cell configuration. Hypervisor configures GIC
-   target registers for those interrupt. Inmate is responsible only for
-   enabling, disabling and acknowledging the interrupts.
-
--  Linux owns **I2C** buses. Inmate cannot has its owe driver to control
-   I2C bus. It is not practicable even if the both root-cell and inmate
-   cell configurations share I2C region and Linux and the Inmate have an
-   agreement not to use I2C at the same time. The problem is that the
-   Linux I2C driver works in interrupt mode and if the Inmate issues an
-   I2C transaction, Linux's interrupt handler will be called. It brakes
-   the Linux's and Inmate's I2C drivers state machines (or whatever they
-   have).
-
--  Using **GPIO** may have the same as I2C problem. It is easy to
-   disable an entire GPIO bank from using by Linux and use it for the
-   Inmate. But it is not practical to share the same bank by the both
-   Linux and Inmate.
-
-|
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Performance_Audio.rst b/source/rtos/Examples_and_Demonstrations/_Performance_Audio.rst
deleted file mode 100644
index 0890b71d3..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Performance_Audio.rst
+++ /dev/null
@@ -1,212 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Performance_Audio
-
-Introduction
-============
-
-This page describes the performance audio demo, developed within Processor SDK RTOS on 66AK2Gx platform.
-This demo implements and integrates audio I/O, framework, auto-detection, decoding, audio stream
-processing (ASP) and encoding - the foundational building blocks of any performance audio application.
-The system block diagram below shows the structure of the demo.
-
-.. Image:: /images/pa_k2g_layout.png
-	:scale: 100 %
-
-This demo utilizes Processor SDK features/components:
-
--  **SYS/BIOS** application utilizing TI-RTOS features for DSP-C66x core and ARM-A15 core
--  **McASP LLD** from PDK for audio input/output
--  **IPC** for inter-processor communications between DSP and ARM
--  **UIA** for instrumentation logging
-
-Requirements
-============
-
-Hardware
-
--  `66AK2Gx Evaluation Module (EVMK2G) <http://www.ti.com/tool/evmk2g>`__
--  `66AK2Gx Audio Daughter Card (AUDK2G) <http://www.ti.com/tool/AUDK2G>`__
--  `Momentum Data Systems (MDS) HDMI repeater kit <http://www.mds.com/products/hdmivideo/>`__ (optional).
-   Contact contactsales@mds.com for more information.
-
-Software
-
--  Code Composer Studio (CCS)
--  Python 2.7.14 and Sed 4.2.1 for Windows only
-
-How to Run the Demo
-===================
-
-Hardware Setup
---------------
-
--  Setup K2G EVM according to the `Quick Start Guide <http://www.ti.com/lit/pdf/sprw292>`__
--  Setup Audio Daughter Card according to the `Quick Start Guide <http://www.ti.com/lit/pdf/sprw287>`__ and attach it to the K2G EVM.
-   The Audio Daughter Card connects to the EVM through the JP1 “Audio Expansion” and J12 “Serial Expansion” connectors on EVM.
--  Connect an analog player output to the ADC_IN0-3 input jacks on the Audio Daughter Card.
--  Connect a DVD/Blue-Ray player digital output (S/PDIF) to the MOD1 Digital Input (Optical) connector on the Audio Daughter Card.
--  Connect speakers to DAC_OUT0-3 output jacks on the Audio Daughter Card.
--  Connect a COM port on PC to UART0 port on K2G EVM using a RS-232 cable.
--  Connect XDS2xx USB Onboard Debug Probe to a PC USB port using the USB cable delivered with the EVM.
-
-.. Image:: /images/pa_k2g_EVM_DC_setup.png
-	:scale: 70 %
-
-Optional Setup for HDMI
------------------------
-
--  Connect the MDS HSR41P to the MDS IFB.
-
-   -  Connect HSR41P J4 “Main” header to the IFB J5 “Main” header using the short 26-wire ribbon cable. Ensure the red wire on the ribbon
-      cable is connected between HSR41P J4 Pin1 and IFB J5 Pin1.
-   -  Connect HSR41P J7 “Sec” header to the IFB J2 “Sec” header using the short 34-wire ribbon cable. Ensure the red wire on the ribbon
-      cable is connected between HSR41P J7 Pin1 and IFB J2 Pin1.
-
--  Connect the MDS IFB to the Audio Daughter Card. Connect IFB J3 “McASP0” header to Audio Daughter Card “I2S Header” using the supplied
-   long 34-wire ribbon cable. Ensure the red wire on the ribbon cable is connected between IFB J3 Pin1 and Audio Daughter Card “I2S Header”
-   Pin1 (note the “I2S Header” is only 32 pins, so the two wires on the ribbon cable opposite Pin1 are unused).
--  Connect HDMI cable from audio source (e.g. Blu-ray player) to HSR41P J6 “IN”. Connect HDMI cable to audio sink (e.g. HDMI enabled monitor)
-   from HSR41P J8 “HDMI OUT”.
--  Connect 5V AC to USB power supply to IFB power connector J1.
-
-.. Image:: /images/pa_k2g_EVM_DC_HDMI_setup.png
-	:scale: 70 %
-
-Software and Tools Setup
-------------------------
-CCS is required to load the binaries and run the demo. Sed and Python are required for run time reselection of input/output, control and reconfiguration
-of decoding and/or audio stream procesing, etc. One may choose to run the demo first and then install Sed and Python for run-time reconfiguration.
-
--  Download and Install CCS (download link available at Processor SDK download page)
--  Obtain Sed 4.2.1 from http://gnuwin32.sourceforge.net/packages/sed.htm,
-   executable installer, sed-4.2.1-setup.exe (click on Setup next to "Complete package, except sources" and download will start).
-   Install it to c:/PA_Tools/GnuWin32 (or change installation location in
-   <process-sdk installation root>/demos/performance-audio/src/setup_build_env/setup_env.bat.
--  Obtain Python 2.7.14 from https://www.python.org/downloads/release/python-2714/ (click on
-   Windows x86 MSI installer, and the installer python-2.7.14.msi will be downloaded automatically).
-   Install it to c:/PA_Tools/Python27 (or change installation location in
-   <process-sdk installation root>/demos/performance-audio/src/setup_build_env/setup_env.bat.
--  Once Python is installed, open a Command Prompt and go to <process-sdk installation root>/demos/performance-audio/src/setup_build_env. Run setup_env.bat,
-   and then go to <process-sdk installation root>/demos/performance-audio/tools/ and run setup.bat
-   to install PyAlpha dependencies. Note: since tools/setup.bat will download Python packages from the web, one needs to
-   make sure that the proxy environment variables are set properly.
-
-Load and Run Pre-built Binaries
--------------------------------
-
-This demo can be run by loading and running the DSP and ARM binaries through CCS:
-
-#.  Click View -> Target Configurations.
-#.  In the Target Configurations window, right click and then click Import Target Configurations.
-#.  Browse to <process-sdk installation root>/demos/performance-audio/src/pasrc/test_dsp/targetConfigs, click K2GEVM.ccxml and then click Open.
-#.  In the Target Configurations window, right-click on K2GEVM.ccxml and select Launch Selected Configuration.
-#.  In the Debug window, right-click on the C66x and select Connect Target. The output from the GEL code invoked on the target connection can be observed in the Console output window. The final line of this output should read "C66xx: GEL Output: DDR3A initialization complete".
-#.  In the Debug window, right-click on the CortexA15 and select Connect Target. The output from the GEL code invoked on the target connection can be observed in the Console output window. The final line of this output should read "CortexA15: GEL Output: A15 non secure mode entered".
-#.  In the Debug Window, click on the C66x. Then open Run->Load->Load Program. In the Load Program window, click on Browse and double click <process-sdk installation root>/demos/performance-audio/prebuilt-binaries/test_dsp.xe66. Then click OK to load the C66x binary.
-#.  In the Debug Window, click on the CortexA15. Then open Run->Load->Load Program. In the Load Program window, click on Browse and double click <process-sdk installation root>/demos/performance-audio/prebuilt-binaries/test_arm.xa15fg. Then click OK to load the CortexA15 binary.
-#.  In the Debug window, click on the C66x. Then Open Run->Resume to execute the C66x code.
-#.  In the Debug window, click on the CortexA15. Then Open Run->Resume to execute the CortexA15 code.
-#.  The CIO Console output window should display memory usage statistics. The final line of output should display the memory usage summary for the EXT NC SHM heap.
-#.  Default input interface is S/PDIF. Play music on the media player with S/PDIF output. Sound should come out of speakers connected to analog out DAC_OUT0.
-
-Limitations:
-
--  If code needs to be reload and rerun, one must terminate the CCS debugging session,
-   power cycle the EVM, and start a new CCS debugging session. Then repeat from step 4 listed above.
-
-Run-time Reconfiguration (in Windows only)
-------------------------------------------
-Please make sure src/setup_build_env/setup_env.bat and tools/setup.bat have both been run to setup the tools path.
-
-Output volume can be changed at run-time via Python scripts through UART:
-
--  Open a windows command prompt, go to tools folder and use the following command to change output volume:
-
-   -  python.exe pyalpha -I alpha -h pa_i13_evmk2g_io_a -p COM1 writeVOLControlMasterN(<volume level>),
-      where <volume level> is level adjustment from default in units of 0.5dB. For example,
-      python.exe pyalpha -I alpha -h pa_i13_evmk2g_io_a -p COM1 writeVOLControlMasterN(-24)
-      lowers the level by 12dB from default.
-
-Input interface is S/PDIF by default and can be reslected at run-time (Note: interface can be reselected
-only when playing is stopped):
-
--  Switch to HDMI input:
-
-   -  Stop playing
-   -  Issue command to change to HDMI input:
-      python.exe pyalpha -I alpha -h pa_i13_evmk2g_io_a -p COM1 execPAIInHDMI
-   -  Play again using digital player with HDMI output
-
--  Switch to analog input:
-
-   -  Stop playing
-   -  Issue command to change output to ADC slave:
-      python.exe pyalpha -I alpha -h pa_i13_evmk2g_io_a -p COM1 execPAIOutAnalogSlave
-   -  Issue command to change input to analog:
-      python.exe pyalpha -I alpha -h pa_i13_evmk2g_io_a -p COM1 execPAIInAnalog
-   -  Play again using analog player
-
-Limitations of run-time reconfiguration as of this release:
-
--  Input interface reselection can only be done when input is mute.
--  Once analog input is selected, S/PDIF can NOT be selected anymore. One
-   must reload the code and rerun the demo.
-
-How to Rebuild the Demo
-=======================
-
-The performance audio demo can be rebuilt from the source code, following the
-instructions given below.
-
-Setup Environment Variables in Linux
-------------------------------------
-A bash shell script, <process-sdk installation root>/demos/performance-audio/src/setup_build_env/setup_env.sh,
-can be used to set up the environment variables:
-
--  set the TI tools path and performance audio demo path in setup_env.sh properly.
--  set version numbers of each component to what's going to be used for the build (default is what's delivered in PRSDK).
--  run the shell script using command "source setup_env.sh".
-
-Setup Environment Variables in Windows
---------------------------------------
-Batch file <process-sdk installation root>/demos/performance-audio/src/setup_build_env/setup_env.bat can be
-used to set up the environment variables.
-
--  set variable TI_TOOLS_DIR in setup_env.bat properly (default is C:\ti).
--  set version numbers of each component to what's going to be used for the build (default is what's delivered in PRSDK).
--  go to folder <process-sdk installation root>/demos/performance-audio/src/setup_build_env and run setup_env.bat (Note: this
-   script MUST be run in the setup_build_env folder.)
--  after running setup_env.bat, run setup_paf.bat in the same folder (Note: setup_env.bat MUST be run before setup_paf.bat).
-
-Rebuild the Demo
-----------------
-
--  Go to source folder: <process-sdk installation root>/demos/performance-audio/src
--  Issue command "make clean" and "make install" for Linux
--  Issue command "gmake clean" and "gmake install" for Windows
--  The rebuilt binaries are placed in src/install/pasdk/debug. They can also be
-   found at src/pasdk/test_dsp/bin/debug and src/pasdk/test_arm/bin/debug
-
-Trouble Shooting
-================
-
-Problems may be encountered when setting up or running the demo. Here are some common problems and the corresponding solutions:
-
-1.  Sound doesn't come out of the speakers:
-
-   -  Make sure the audio daughter card (and HDMI repeater card if used) is connected well. The `PDK addon audio loopback test
-      <index_examples_demos.html#k2g-audio-dc-addon>`__ can be run to verify the setup of EVM and audio daughter card.
-   -  In CCS Expressions window, enter variable "asipLoopCount1" and check if it is incrementing. If not, terminate the debug session, power cycle
-      the EVM, and restart.
-
-2.  The Python command times out:
-
-   -  Make sure to use UART0 COM port on the EVM. The Python scripts may not work well if J23 USB connector is used for UART communications.
-
-3.  The source code doesn't build:
-
-   -  Make sure the environment variables are set correctly. The default tools location in setup.env may not be where the tools are installed.
-      Change TI_TOOLS_DIR to where tools and Proc-SDK components are installed.
-
-4.  Python setup can't install PyAlpha dependencies.
-
-   - Make sure proxy environment variables, HTTP_PROXY and HTTPS_PROXY, are set properly.
diff --git a/source/rtos/Examples_and_Demonstrations/_Posix_SMP_Demo.rst b/source/rtos/Examples_and_Demonstrations/_Posix_SMP_Demo.rst
deleted file mode 100644
index 41d12d6a6..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Posix_SMP_Demo.rst
+++ /dev/null
@@ -1,217 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_Posix-SMP_Demo
-
-Introduction
-============
-
-This page describes the SMP/Posix demo provided in the Processor-SDK for
-RTOS and Linux. This demo uses Posix APIs together with a simple
-benchmark (Dhrystone) to automatically calculate the effective
-throughput of all the cores in each SMP cluster. SMP mode is only
-supported on Coretex-A15 cores.
-
-This demo runs on:
-
--  AM572x (A15, C66, M4)
--  AM437x (A9)
--  AM335x (A8)
--  K2H (A15, C66)
--  K2E (A15, C66)
--  K2G (A15, C66)
--  K2L (A15, C66)
--  C6678 (C66)
--  C6657 (C66)
-
-The sections below provide details of the application as well as build
-and run instructions.
-
-Requirements
-============
-
-The following materials are required to run this demonstration:
-
-Hardware
-
--  TI EVM (see list above)
--  Serial UART cable (provided in EVM kit)
-
-Software
-
--  Processor-SDK RTOS
--  Code Composer Studio
-
-|
-
-Software Design
-===============
-
-The demo is based on Dhrystone 2.1 from
-`link <http://fossies.org/linux/privat/old/dhrystone-2.1.tar.gz/>`__.
-
-The purpose of the demo is two-fold. First, it is to show easy scaling
-of throughput across cores in a SMP cluster when running TI-RTOS.
-Second, it shows easy portability of Posix threads between TI-RTOS and
-Linux.
-
-The overall requirement is discover all parameters automatically without
-user input, and to minimize the amount of code that must be customized
-between TI-RTOS and Linux. This demonstrates that the same Posix threads
-as well as their setup/control code can be run on either TI-RTOS or
-Linux with minimal effort.
-
-In order to accomplish this, several major modifications were made to
-Dhrystone in order to "threadify" it. Some of these changes slightly
-affect the results compared to an unmodified version. Thus this modified
-version should be run on all processors where comparisons will be drawn.
-
--  **Removal of most printf() during normal operation.** Original code
-   dumped all final values for the user to verify. Changed to
-   programmatic verification. Only printf() for actual results (DMIPS
-   and Dhrystones) preserved.
--  **Removal of all global variables.** They are accessed through an
-   "inst" pointer instead.
--  **Adaptive discovery of iteration count.** Original code used a
-   #define. This version doubles iteration count until execution time is
-   about 10M timer ticks.
--  **Adaptive discovery of number of cores in SMP cluster.** Original
-   code didn't use threads. This version doubled number of threads until
-   cumulative DMIPS flattens out.
-
-POSIX barriers are used inside the timed portion of the code. This is
-not to time the performance of the barrier, but is instead used to time
-how long all threads together take to complete. It is assumed the
-execution times of the threads (> 0.1 second) are orders of magnitude
-more than the barrier, so the barrier's effect on results is negligible.
-
-Processor SDK uses makefiles for TI-RTOS and Yocto recipes for Linux for
-the supported EVMs. The makefile can also be used to compile native
-builds for Linux (both for EVMs and x86).
-
-For more information on TI-RTOS Posix, see `POSIX
-Support <http://processors.wiki.ti.com/index.php/SYS/BIOS_POSIX_Thread_(pthread)_Support>`__.
-
-|
-
-How to Run the Demo
-===================
-
-The processor SDK includes pre-built binaries which may be loaded and
-run using the SBL with UART or using CCS with UART or ROV (UART display
-for newer versions and ROV for older versions). To run using UART, hook
-up to the board using UART and run the .out file.
-
-.. Image:: /images/Posix-demo-uart.PNG
-
-To run using CCS, use the following steps. Each binary has an associated
-\\*.rov.xs file located in the same directory--enabling the CCS ROV tool.
-Newer versions will display directly to the UART console and any steps
-involving ROV may be skipped.
-
-::
-
-    <SDK_INSTALL_PATH>/processor_sdk_rtos_<platform>_2_00_xx_xx/demos/posix-smp/bin/<platform>/<core>/debug/dhry.out
-    <SDK_INSTALL_PATH>/processor_sdk_rtos_<platform>_2_00_xx_xx/demos/posix-smp/bin/<platform>/<core>/debug/dhry_pa15fg.rov.xs
-
-For all platforms and core types, the basic procedure for running the
-demo will be the same:
-
-#. Using CCS, launch the target configuration for the EVM `CCS-Target
-   Configurations <http://processors.wiki.ti.com/index.php/Target_Configuration_-_Custom_Configurations>`__.
-   Please ensure that the target configuration will load the appropriate
-   CCS gel files found in the emupak. Make sure all Coretex-A15 cores in
-   the SMP cluster have an appropriate CCS gel file.
-#. The default ccxml file only loads a gel on connect for some of the
-   cores. Modify the ccxml file to load the gel for all the
-   corresponding cores.
-#. In the CCS debug view, group and then connect to all cores of device
-   that you wish to test on (i.e. - all of the clustered A15 cores).
-#. For each, core load the dhry.out file. The principle core should halt
-   at main while the SMP linked cores will begin auto-running upon load.
-#. Once all cores have been loaded, run all the cores.
-#. The output will be sent to the UART console in real time.
-#. The demo should not take more than a few minutes to run. You must
-   manually halt the cores to end the demo.
-
-If using Processor-SDK 3.0 or later,
-
-#. Open the ROV window (Tools > RTOS Object View (ROV)) and view the
-   SysMin module to inspect the output of the demo. If you see the below
-   message, please specify the XDC and SYSBIOS versions:
-
-.. Image:: /images/Use_rov_1.jpg
-
-.. Image:: /images/Use_rov_2.png
-
-.. Image:: /images/Posix-smp2.png
-
-The output buffer shown in the ROV contains the different stages of the
-demo's progression:
-
-#. The demo finds an appropriate number of iterations for the device.
-#. The demo begins to add threads.
-#. The demo concludes when adding additional threads does not further
-   increase the DMIPS.
-
-The output takes the form of: "xxxxxxx iterations \*n threads;
-dhrystones xxxxxxxx, dmips = xxxx". In the screenshot above, moving from
-two threads to four threads does not appreciably improve the DMIPS, so
-the demo completes. This behavior is expected because the demo is only
-running on two cores in this example.
-
-.. note::
-   -  A15 cores may usually be connected to directly; on the AM572x, the M4
-      IPUs must first be initialized by the gel scripts (Scripts > AM572x
-      MULTICORE initialization > IPUxSSClkEnable_API)
-   -  If the K2 demo will not run, try updating to the latest emupack by
-      doing "Help/Check For Updates" and selecting "Keystone2 device
-      support" update (only). There are additional instructions for
-      configuring groups, etc. at `SMP
-      Debug <http://processors.wiki.ti.com/index.php/SMP_Debug>`__.
-   -  If the primary core of an SMP group will not allow running after
-      loading the demo, try pausing the linked cores and then running all
-      the cores in a group
-   -  For TI-RTOS documentation for enabling SMP, refer to
-      `SMP/BIOS <http://processors.wiki.ti.com/index.php/SMP/BIOS>`__. The
-      POSIX demo in the Processor SDK RTOS packages with C66x does not
-      support SMP. This is a POSIX pthread demo intended to run Dhrystone
-      on one C66x core without SMP.
-   -  Some of the DMIPS values may not be accurate, but the values will
-      increase proportionally with the number of cores
-
-How to Build the Demo
-=====================
-
-Processor-SDK RTOS
-------------------
-
-To build the project manually, first navigate to the top level makefile:
-
-::
-
-     <SDK_INSTALL_PATH>/processor_sdk_rtos_<platform>_2_00_xx_xx/demos/posix-smp/makefile
-
-Edit the makefile to include the paths to BIOS, XDC, PDK packages, and
-the toolchains for the cores being used.
-
-::
-
-    #DEPOT = <ROOT_INSTALL_PATH>
-    #### BIOS-side dependencies ####
-    #BIOS_INSTALL_PATH ?= $(DEPOT)\bios_n_nn_nn_nn
-    #XDC_INSTALL_PATH ?= $(DEPOT)\xdctools_n_nn_nn_nn_core
-    #### BIOS-side toolchains ####
-    #TOOLCHAIN_PATH_A15 ?= $(DEPOT)\ccsv6\tools\compiler\gcc-arm-none-eabi-n_n-xxxxqn
-    #TOOLCHAIN_PATH_M4 ?= $(DEPOT)\ccsv6\tools\compiler\ti-cgt-arm_x.x.x
-
-Navigate to the demo directory and run "make". The steps to run the demo
-will be the same.
-
-Processor-SDK Linux
--------------------
-
-The Posix-SMP demo has been added to the Linux SDK matrix starting in
-Processor-SDK 3.0. Simply run the example from the Matrix and the output
-will be displayed on the console.
-
-For the documentation on the Linux Matrix, please see:
-`link <http://processors.wiki.ti.com/index.php/Matrix_Users_Guide>`__.
-
diff --git a/source/rtos/Examples_and_Demonstrations/_RTOS_Examples.rst b/source/rtos/Examples_and_Demonstrations/_RTOS_Examples.rst
deleted file mode 100644
index eb80cf181..000000000
--- a/source/rtos/Examples_and_Demonstrations/_RTOS_Examples.rst
+++ /dev/null
@@ -1,630 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Examples
-
-Overview
-========
-
-The SYS/BIOS examples gets user started with development of code using a
-real-time operating system. These are simple examples that does not get
-into details of software components provided in the SDK.
-
-
-ARM Cortex-A53
-==============
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout. As a
-sample we will use the AM65x device to describe the steps for the Cortex-A53.
-
-.. Note:: For future Device Support Package releases, the Hello World example for the Cortex-A53 will be added to CCS as an out-of-box experience.
-
-1. Create a work space folder to be used for Hello Example project
-(e.g. /ti/am65x_am53_hello_workspace), and start CCS. If prompted with
-**New Products Discovered**, install any desired products and restart
-CCS if required.
-
-2. In CCS, go to File --> New -->
-CCS Project.
-
-3. Enter a project name and configure the new CCS project as follows:
-
- * **Target**: GPEVM_AM65x
- * **Cortex A**
- * **Device Endianness**: little
-
-4. Under "Project Templates and examples", select "More Examples... --> Search Using Import Wizard".
-Select "hello" project and click "Finish".
-
-5. Remove AM6548.lds from the project. Add the file **linker_a53.lds** located in the folder (PDK INSTALL PATH)/packages/ti/build/am65xx/
-to the project.
-
-6. Remove hello.cfg from the project. Add the file **sysbios_a53.cfg** located in the folder (PDK INSTALL PATH)/packages/ti/build/am65xx/
-to the project.
-
-7. Add the file **InitMmu.c** located under (IPC INSTALL PATH)/examples/AM65XX_bios_elf/ex02_messageq/host
-to the project.
-
-8. Select Compiler: right-click on the project, select "Properites". Under "Tool-chain",
-select "GNU v7.2.1 (Linaro aarch64)" (or higher).
-
-9. Build the project: right-click on the project and
-select "Build Project".
-
-10. Launch the target configuration using the appropriate emulator to connect to AM65x EVM
-as described in the AM65x EVM Hardware Setup Guide.
-
-11. Right click on DMSC_Cortex_M3_0 and click Connect Target.
-
-12. Connect to the CortexA53_0_0 core. Load and run Hello Example out file.
-You should see Hello World string displayed on console window.
-
-|
-
-ARM Cortex-A15
-==============
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout. As a
-sample we will use the AM572x device to describe the steps. The same
-steps can be used for create hello world examples for A15 cores in
-Keystone 2 family of devices.
-
-.. note::
-
-   -  The K2G, K2E and K2H devices, can be located under Unclassified
-      devices in the Resource Explorer. Refer below Screenshot for Keystone II
-
-.. Image:: /images/KSII_RS.png
-
-1. Create a work space folder (\ti\am_572x_hello_workspace) under ti
-folder to be used for Hello Example project, and start CCS. You may be
-prompted with **New Products Discovered**, so select all and **click on
-Finish**
-
-2. On CCS click View --> Resource Explorer (Examples).
-
-3. On SYS/BIOS scroll down to AM572X --> Cortex A --> Generic Example
---> click on Hello Example.
-
-.. Image:: /images/Sys_bios_hello_example_screen_1.jpg
-
-4. To import Hello Example, on the right window click on step 1. Import
-The Example to CCS Project.
-
-5. On New CCS Project window enter project name and then click Next.
-
-.. Image:: /images/Sys_bios_hello_example_screen_2.jpg
-
-6. On RSTC window select platform name: **ti.platforms.evmAM572X** and
-check that the target is set to **gnu.targets.arm.A15F**
-
-7. Click Finish. Your project should show up on Project Explorer window.
-
-8. To get log message to print on console add this variable to hello.cfg
-file:
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-    var SemiHostSupport = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');
-
-.. raw:: html
-
-   </div>
-
-.. note::
-   You also need to replace the nosys library in linker with
-   rdimon which is the Semi-Hosting enabled BSP library.
-
-Right click on project --> Show Build Settings... --> Build --> GNU
-Linker --> Libraries
-
-9. Build Hello Example project by Right click on Hello Project and click
-Build project.
-
-10. Create new target configuration (if one doesn`t exist) as described
-in here :ref:`Create Target Configuration File for EVM <Create-Target-Configuration-File-for-EVM-label/>`
-
-11. Right click on the target configuration and Launch target
-configurations.
-
-12. Right click CortexA15_0 and connect target.
-
-13. Load and run Hello Example out file. You should see **Hello World**
-string displayed on console window.
-
-|
-
-ARM Cortex-A9
-=============
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout.
-
-1. Create a work space folder (\\ti\\am_437x_hello_workspace) under ti
-folder to be used for Hello Example project, and start CCS. You may be
-prompted with **New Products Discovered**, so select all and **click on
-Finish**
-
-2. On CCS click View --> Resource Explorer (Examples).
-
-3. On SYS/BIOS scroll down to AM4378 --> Cortex A --> Generic Example
---> click on Hello Example.
-
-.. Image:: /images/RTOS_CortexA9_HelloWorld.png
-
-4. To import Hello Example, on the right window click on step 1. Import
-The Example to CCS Project.
-
-5. On New CCS Project window enter project name and then click Next.
-
-.. Image:: /images/HelloWorld_cortexA9.png
-
-6. On RSTC window select platform name: **ti.platforms.evmAM437X** and
-check that the target is set to **gnu.targets.arm.A9F**
-
-7. Click Finish. Your project should show up on Project Explorer window.
-
-8. To get log message to print on console add this variable to hello.cfg
-file:
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-    var SemiHostSupport = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. note::
-   You also need to replace the nosys library in linker with
-   rdimon which is the Semi-Hosting enabled BSP library.
-
-Right click on project --> Show Build Settings... --> Build --> GNU
-Linker --> Libraries
-
-9. Build Hello Example project by Right click on Hello Project and click
-Build project.
-
-10. Create new target configuration (if one doesn`t exist) as described
-here :ref:`Create Target Configuration File for EVM <Create-Target-Configuration-File-for-EVM-label>`
-
-11. Right click on the target configuration and Launch target
-configurations.
-
-12. Right click CortexA9_0 and connect target.
-
-13. Load and run Hello Example out file. You should see **Hello World**
-string displayed on console window.
-
-|
-
-ARM Cortex-A8
-=============
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout.
-
-1. Create a work space folder (\\ti\\am_335x_hello_workspace) under ti
-folder to be used for Hello Example project, and start CCS. You may be
-prompted with **New Products Discovered**, so select all and **click on
-Finish**
-
-2. On CCS click View -->
-Resource Explorer (Examples).
-
-3. On SYS/BIOS scroll down to AM3352 --> Cortex A --> Generic Example
---> click on Hello Example.
-
-.. Image:: /images/RTOS_CortexA8_HelloWorld.png
-
-4. To import Hello Example, on the right window click on step 1. Import
-The Example to CCS Project.
-
-5. On New CCS Project window enter project name and then
-click Next.
-
-.. Image:: /images/HelloWorld_cortexA8.png
-
-6. On RSTC window select platform name: **ti.platforms.evmAM335X** and
-check that the target is set to **gnu.targets.arm.A8F**
-
-7. Click Finish. Your project should show up on
-Project Explorer window.
-
-8. To get log message to print on console add this variable to hello.cfg
-file:
-
-.. raw:: html
-
-   <div class="mw-geshi mw-code mw-content-ltr" dir="ltr">
-
-.. raw:: html
-
-   <div class="c source-c">
-
-.. code:: c
-
-    var SemiHostSupport = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. note::
-   You also need to replace the nosys library in linker with
-   rdimon which is the Semi-Hosting enabled BSP library.
-
-Right click on project --> Show Build Settings... --> Build --> GNU
-Linker --> Libraries
-
-9. Build Hello Example project by Right click on Hello Project and click
-Build project.
-
-10. Create new target configuration (if one doesn`t exist) as described
-here :ref:`Create Target Configuration File for EVM <Create-Target-Configuration-File-for-EVM-label>`
-
-11. Right click on the target configuration and Launch target
-configurations.
-
-12. Right click CortexA8_0 and connect target.
-
-13. Load and run Hello Example out file. You should see **Hello World**
-string displayed on console window.
-
-|
-
-ARM Cortex-R5
-=============
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout.
-
-1. Create a work space folder (/ti/am65x_r5_hello_workspace) under ti
-folder to be used for Hello Example project, and start CCS. You may be
-prompted with **New Products Discovered**, so select all and **click on
-Finish**
-
-2. Select File --> New -->
-CCS Project.
-
-3. Select Target:
-AM6548.
-
-4. Select Cortex R
-[ARM] tab.
-
-5. Under Project templates and examples,
-expand SYS/BIOS. Expand More Examples..., click Search using Import Wizard.
-
-6. Select "hello" project,
-click Finish.
-
-7. Launch the target configuration using the appropriate emulator to
-connect to AM65x EVM as described in the AM65x EVM Hardware Setup Guide.
-
-8. Right click on DMSC_Cortex_M3_0 and
-click Connect Target.
-
-9. Connect to the MCU_PULSAR_Cortex_R5_0 core. Load and run Hello Example
-out file. You should see Hello World string displayed on console window.
-
-
-ARM Cortex-M4
-=============
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout.
-
-1. Create a work space folder (/ti/am_572x_hello_workspace) under ti
-folder to be used for Hello Example project, and start CCS. You may be
-prompted with **New Products Discovered**, so select all and **click on
-Finish**
-
-2. On CCS click View --> Resource Explorer
-(Examples).
-
-3. on SYS/BIOS scroll down to AM572X --> Cortex M --> Generic Example
---> click on Hello Example.
-
-.. Image:: /images/SYSBIOS_hello_world_M4_template.jpg
-
-4. To import Hello Example, on the right window click on step 1. Import
-The Example to CCS Project.
-
-5. Go to Project Explorer window and click on project properties.
-
-.. Image:: /images/SYSBIOS_M4_platformSelect.jpg
-
-6. On RSTC window select platform name: **ti.platforms.evmAM572X** and
-check that the target is set to **gnu.targets.arm.elf.M4**
-
-7. Click Finish. Your project should show up on
-Project Explorer window.
-
-8. Build Hello Example project by Right click on Hello Project and click
-Build project.
-
-9. Launch target configurations using appropriate emulator to connect to
-AM572X EVM.
-
-10. Right click CortexA15_0 and connect target. From the Scripts menu
-select `AM572x Multicore
-Initialization->IPU1SSClkEnable_API <index_how_to_guides.html#connect-to-am57x-target-cores>`__.
-
-11. Connect to the Cortex_M4_IPU1_C0. Load and run Hello Example out
-file. You should see **Hello World** string displayed on console window.
-
-|
-
-ARM9
-====
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout. As a
-sample we will use the OMAP-L138 device to describe the steps.
-
-1. Create a workspace folder inside the ti
-folder to be used for the Hello Example project, and start CCS. You may be
-prompted with **New Products Discovered**, so select all and **click on
-Finish**
-
-2. On CCS click View --> Resource Explorer Classic (Examples).
-
-3. On SYS/BIOS scroll down to OMAP-L1x --> LCDKOMAPL138 --> TI Target Examples --> Generic Examples
---> click on Hello Example.
-
-.. Image:: /images/omapl13x_arm9_hello_rtos_tirex.png
-
-4. To import Hello Example, on the right window click on step 1. Import
-The Example to CCS Project.
-
-5. On New CCS Project window enter project name and then click Next.
-
-.. Image:: /images/omapl13x_arm9_hello_rtos_ccs.png
-
-6. On RSTC window select platform name: **ti.platforms.evmOMAPL138** and
-check that the target is set to **ti.targets.arm.elf.Arm9**
-
-7. Click Finish. Your project should show up on Project Explorer window.
-
-8. Build Hello Example project by Right click on Hello Project and click
-Build project.
-
-9. Create new target configuration (if one doesn`t exist) as described
-in here :ref:`Create Target Configuration File for EVM <Create-Target-Configuration-File-for-EVM-label/>`
-
-10. Right click on the target configuration and Launch target
-configurations.
-
-11. Right click ARM9_0 and connect target.
-
-12. Load and run Hello Example out file. You should see **Hello World**
-string displayed on the console window.
-
-|
-
-DSP C66x
-========
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout. As a
-sample we will use the AM572x device to describe the steps but the same
-steps can be used for create hello world examples for C66x cores in
-Keystone I and Keystone 2 family of devices.
-
-.. note::
-
-   -  The C66x examples corresponding Keystone I devices can be located
-      under C66x Multi-core DSP devies in the Resource Explorer. Refer
-      below screenshot
-
-.. Image:: /images/KSI_RS.png
-
-.. note::
-
-   -  The K2G, K2E and K2H devices, can be located under Unclassified
-      devices in the Resource Explorer. Refer below screen shot
-
-.. Image:: /images/KSII_RS.png
-
-1. Create a work space folder (\ti\am_572x_hello_workspace) under ti
-folder to be used for Hello Example project, and start CCS. You may be
-prompted with **New Products Discovered**, so select all and **click on
-Finish**
-
-2. On CCS click View --> Resource Explorer (Examples).
-
-3. on SYS/BIOS scroll down to AM572X --> C66x --> Generic Example -->
-click on Hello Example.
-
-.. Image:: /images/SYSBIOS_hello_world_dsp_template.jpg
-
-4. To import Hello Example, on the right window click on step 1. Import
-The Example to CCS Project.
-
-5. On New CCS Project window enter project name and then click Next.
-
-.. Image:: /images/SYSBIOS_DSP_platformSelect.jpg
-
-6. On RSTC window select platform name: **ti.platforms.evmAM572X** and
-check that the target is set to **ti.targets.elf.C66** (Auto populated)
-
-7. Click Finish. Your project should show up on Project Explorer window.
-
-8. Build Hello Example project by Right click on Hello Project and click
-Build project.
-
-10. Create new target configuration (if one doesn`t exist) as described
-`here <index_how_to_guides.html#create-target-configuration-file-for-evm>`__.
-
-11. Right click on the target configuration and Launch target
-configurations.
-
-12. Right click CortexA15_0 and connect target. From the Scripts menu
-select `AM572x Multicore
-Initialization->DSP1SSClkEnable_API <index_how_to_guides.html#connect-to-am57x-target-cores>`__.
-
-13. Route the GPTimer5 suspend ctrl signal to the DSP using the Scripts
-menu GP timer Suspend Ctrl -> GPTimer5SuspendCtl_DSP1SS_BIOS as
-described `here <index_how_to_guides.html#timer-suspend-control-options-for-dsp>`__.
-
-14. Connect to C66x_DSP1 Load and run Hello Example out file. You should
-see **Hello World** string displayed on console window.
-
-DSP C674x
-=========
-
-The hello example serves as a basic sanity check program for SYS/BIOS.
-It demonstrates how to print the string 'hello world' to stdout. As a
-sample we will use the C6748 device to describe the steps but the same
-steps can be used for create hello world examples for C674x cores in
-OMAPL1x/DA8x family of devices.
-
-.. note::
-
-   -  Locate the appropriate device that you are using to make sure the
-      correct SYSBIOS platform definiition gets used in the build
-
-1. Create a work space folder ( Eg. tirtos_hello_workspace) that can be
-used for Hello Example project, and start CCS. You may be prompted with
-**New Products Discovered**, so select all and **click on Finish** Note:
-at this stage the version of SYSBIOS and corresponding dependencies are
-assumed to be discovered by CCS. If not please follow the steps
-described here:
-`Discovering_SDK_products <index_how_to_guides.html#discovering-sdk-products>`__
-
-2. On CCS click View --> Resource Explorer Classic (Examples).
-
-3. on SYS/BIOS scroll down to C6748 /OMAPL1x and select --> C674x -->
-Generic Example --> click on Hello Example.
-
-.. Image:: /images/OMAPL138_SYSBIOS_TI_RTOS_CCSv7.png
-
-4. To import Hello Example, on the right window click on step 1. Import
-The Example to CCS Project.
-
-5. On New CCS Project window enter project name and then click Next.
-
-.. Image:: /images/Create_Project_Step1.png
-
-6. On RSTC window select platform name: **ti.platforms.evmc6748** and
-check that the target is set to **ti.targets.elf.C674** (Auto populated)
-
-.. Image:: /images/Create_Project_Step2.png
-
-7. Click Finish. Your project should show up on Project Explorer window.
-
-8. Build Hello Example project by Right click on Hello Project and click
-Build project.
-
-10. Create new target configuration (if one doesn`t exist) as described
-`here <index_how_to_guides.html#create-target-configuration-file-for-evm>`__.
-
-11. Right click on the target configuration and Launch target
-configurations.
-
-12. Developers can Connect to the C674x on OMAPL137/C6747/C6748 can
-connect directly to the DSP. For OMAPL138 device, you will need to
-connect to the ARM as this is ARM master boot device and ARM needs to
-power up the DSP You should see the following log in the Console
-
-::
-
-    C674X_0: Output:   Target Connected.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    Memory Map Cleared.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    Memory Map Setup Complete.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    PSC Enable Complete.
-    C674X_0: Output:    ---------------------------------------------
-    C674X_0: Output:    PLL0 init done for Core:300MHz, EMIFA:25MHz
-    C674X_0: Output:    DDR initialization is in progress....
-    C674X_0: Output:    PLL1 init done for DDR:150MHz
-    C674X_0: Output:    Using DDR2 settings
-    C674X_0: Output:    DDR2 init for 150 MHz is done
-    C674X_0: Output:    ---------------------------------------------
-
-13. Connect to C674x_DSP1 Load and run Hello Example out file. You
-should see **Hello World** string displayed on console window.
-
-.. Image:: /images/Hello_world_dsp674x_rtos.png
-
-|
-
-Usage Notes
-===========
-
-After execution of the hello world examples on the core, the CCS Editor
-may report "Can't find a source file" error messages when you pause or
-the application exits/aborts after completion. This occurs due to source
-files from SYSBIOS or XDC packages not being in the default search path
-of the CCS Editor. when you run into this issue, you can navigate to the
-file using Locate file option in the Editor. Once you provide the
-location the CCS Editor will be able to locate all the other required
-files from that package based on relative path.
-
-For example, when running SYS/BIOS Hello Example using AM57x-GP EVM if
-you see the message
-
-::
-
-     Can't find a source file at "/db/ztree/library/trees/xdctargets/xdctargets-i02/src/gnu/targets    /arm/rtsv7A/syscalls.c"
-     Locate the file or edit the source lookup path to include its location. The above file is located  under file path ${PROC_SDK_DIR}\bios_6_42_02_29\packages\gnu\targets\arm\rtsv7A
-
-You can also prevent these issues by adding the Processor SDK components
-to file search path under Windows->Preferences options in CCS GUI.
-
-|
-
-Known Issues
-============
-
--  **SYS/BIOS examples for Cortex-A15 generate linker errors due to the
-   FPU related flags**
-
-Some versions of CCS are impacted by linker setting used in CCS RTOS
-templates and may need some manual modification to set the correct
--mfpu, -mcpu and -march. If you are seeing VFP errors in the link step,
-you are most likely running into this issue. To correct this issue
-please check the resolution here:
-https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/539973
-
-|
-
-
-Useful Resources
-================
-
--  `TI RTOS
-   training <http://processors.wiki.ti.com/index.php/Introduction_to_the_TI-RTOS_Kernel_Workshop>`__
--  `SYS/BIOS
-   Information <http://processors.wiki.ti.com/index.php/Category:SYSBIOS>`__
--  `SYS/BIOS
-   FAQ <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__
-
-|
-
diff --git a/source/rtos/Examples_and_Demonstrations/_RTOS_Template_App.rst b/source/rtos/Examples_and_Demonstrations/_RTOS_Template_App.rst
deleted file mode 100644
index 93544e9f1..000000000
--- a/source/rtos/Examples_and_Demonstrations/_RTOS_Template_App.rst
+++ /dev/null
@@ -1,743 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Template_App
-
-Introduction
-============
-.. note::
-   This workshop duplicates information found elsewhere in the RTOS Software
-   Developer Guide for the purpose of creating a cohesive document.
-
-This workshop is a simple introduction for software development using
-Processor SDK RTOS. The goal of this workshop is to get you familiarized with
-Processor SDK RTOS and introduce you to using Sitara Evaluation Modules (EVMs)
-and TI tools.
-
-To accomplish this goal, we will work through an interactive lab using the
-RTOS/Bare-metal Template Application. This application will introduce key concepts of
-the SDK and serves as the starting point for creating your own application.
-
-Here's what we will learn over the course of this lab:
-
-- Basic usage of Code Composer Studio (CCS)
-
-  - Importing
-  - Editing
-  - Building
-  - Flashing
-- Processor SDK RTOS Software
-
-  - Low level drivers (LLDs) such as UART, GPIO, etc.
-  - Operating System Abstraction Layer (OSAL)
-  - Board library
-
-|
-
-Prerequisites
-=============
-
-Software
---------
-- Processor SDK RTOS for your platform
-
-  - `AM335x <http://www.ti.com/tool/PROCESSOR-SDK-AM335X>`_
-  - `AM437x <http://www.ti.com/tool/PROCESSOR-SDK-AM437X>`_
-  - `AM57x <http://www.ti.com/tool/PROCESSOR-SDK-AM57X>`_
-  - `AM65x <http://www.ti.com/tool/PROCESSOR-SDK-AM65X>`_
-
-- CCS Version associated with your SDK Release
-
-  - A download link for CCS is located on the same page as the SDK download.
-
-.. note::
-   If you are using AM65x, you will also need to install latest TI Emulators
-   and Sitara device support packages into CCS. This can be done through
-   CCS --> Help --> Check for Updates.
-
-Hardware
---------
-- A supported Sitara Evaluation Module
-
-  - `AM335x EVM <http://www.ti.com/tool/TMDXEVM3358>`_
-  - `AM437x EVM <http://www.ti.com/tool/TMDSEVM437X>`_
-  - `AM572x EVM <http://www.ti.com/tool/TMDSEVM572X>`_
-  - `AM654x EVM <http://www.ti.com/tool/TMDX654IDKEVM>`_
-
-- JTAG Debug Probe if using AM572x EVM
-
-  - XDS100-class JTAG debug probes
-
-    - Low cost, low performance
-    - XDS100v1 is not supported.
-  - XDS200-class JTAG debug probes
-
-    - Recommended
-  - XDS560v2-class JTAG debug probes
-
-    - High performance
-- Serial UART cable provided in the EVM kit
-
-Recommended Training Videos
----------------------------
-- `Processor SDK Training Series`__
-
-  - Introduction to the Processor SDK Training Series
-  - Processor SDK Overview
-  - Introduction to Processor SDK RTOS Part 1
-  - Introduction to Processor SDK RTOS Part 2
-  - Application Development Using Processor SDK RTOS
-- `AM437x Sitara Processors Training Series`__
-- `AM57x Sitara Processors Training Series`__
-- `AM65x Sitara Processors Training Series`__
-
-__ https://training.ti.com/processor-sdk-training-series
-__ https://training.ti.com/am437x-sitara-processors-training-series
-__ https://training.ti.com/am57x-sitara-processors-training-series
-__ https://training.ti.com/am6x
-
-|
-
-Template Application Overview
-=============================
-The Template Application is intended for
-customers to use as a starting point during software development using
-Processor SDK RTOS software. The Template Application can be quickly brought up
-by importing the included Code Composer Studio (CCS) project into the CCS
-development environment. The application currently includes the typical low
-level drivers such as UART, GPIO, and I2C, the OSAL layer, and Board Library.
-For additional details refer to the **README.txt** file in the installed
-package.
-
-Components Used
----------------
-
--  SYS/BIOS (RTOS only)
--  XDCTools (RTOS only)
--  Processor SDK RTOS PDK
-
-   - Drivers, OSAL, etc.
-
-Software Design
----------------
-
-The Template Application is designed to provide a foundational project with a
-clean separation of the application-specific submodule from the startup and
-initialization code. This gives users the ability to focus on
-application-specific code and quickly get it up and running. This separation is
-achieved by splitting the "main" and "app" submodules into different files.
-
-The source files are organized as follows::
-
-    └── template_app
-        ├── baremetal
-        │   ├── app.c --> Application tasks are here
-        │   ├── app.h --> Application header file
-        │   ├── baremetal_template_app_am572x_a15_evmAM572X.projectspec --> Project spec file
-        |   ├── main.c --> Main file which has board and driver init code
-        │   ├── lnk_a15.cmd --> Linker command file.
-        ├── GPIO_board.h --> Gpio board header
-        ├── GPIO_evmAM572x_board.c --> Gpio board configuration
-        └── rtos
-            ├── app.c --> Application tasks are here
-            ├── app.cfg --> Application specific config file
-            ├── app.defs --> Definitions (Currently empty)
-            ├── app.h --> Application header file
-            ├── main.c --> Main file which has board and driver init cod
-            ├── main.cfg --> Main BIOS config file
-            └── rtos_template_app_am572x_a15_evmAM572X.projectspec --> Project spec file
-
-In general, to write a new application **app.c** and **app.h** can be
-modified, recompiled, and run.
-
-|
-
-Lab
-===
-Now that the introductory material is out of the way, it is time to get our
-hands dirty and begin the lab.
-
-.. Note::
-   The AM572x EVM was used for the creation of this lab material, but the same
-   instructions apply for the other supported platforms -- AM335x EVM,
-   AM437x EVM, and AM654x EVM.
-
-Task 1 - Installing the Processor SDK into CCS
-----------------------------------------------
-Before using the Processor SDK, we must install its components into Code
-Composer Studio (CCS). Typically -- if you chose to install the Software
-Development Kit (SDK) into the default **$HOME/ti**
-or **C:\\ti** location -- CCS will automatically detect the new products the
-next time it is opened and prompt you to install them. If you are not prompted
-to install the new products, you can do so manually through the *Window -->
-Preferences --> Code Composer Studio --> Products* menu. This menu will allow
-you define product discovery paths and rediscover, install, and unistall
-products.
-
-.. image:: /images/install-discovered-products.png
-   :scale: 70 %
-
-For more info on setting up CCS. Check out
-`Setup CCS for EVM and Processor-SDK RTOS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__
-in the How To Guides.
-
-Task 2 - Importing and Building the  Template Application
----------------------------------------------------------
-We begin the lab by importing the RTOS or Bare-metal Template Application into CCS. The
-Template Application is delivered as a preconfigured CCS Project, making this
-process very simple. We will also use this as an opportunity to briefly dive
-into the structure of the SDK.
-
-To import a project into CCS, go to the *Project --> Import CCS Projects...*
-menu. Typically, you will import SDK projects from either the
-**pdk_<platform>_<version>** or **processor_sdk_rtos_<platform>_<version>**
-directories. The **pdk_<platform>_<version>** directory contains Chip Support
-Library (CSL), Low Level Drivers (LLDs), Boot, Diagnostics, and other
-functions. It is also where LLD example projects are created. The
-**processor_sdk_rtos_<platform>_<version>** directory contains demos
-(including the Template App), documentation, and resources for creating
-bootable SD cards.
-
-Now that you have an understanding of these directories, let us move on to
-importing the Template Application.
-
-To import a project into CCS open the *Project --> Import CCS Projects...*
-menu. Then click *Browse...* to locate the template app which can be found at:
-**processor_sdk_rtos_<platform>_<version>/demos/rtos_template_app/<soc_name>/<evm_name>/<core_name>**.
-This will create a copy of the project in your CCS workspace.
-
-.. image:: /images/import-ccs-project.png
-   :scale: 70 %
-
-After project import is complete you will see the Template Application under
-the *Project Explorer* on the left side of CCS. Next, right click on the
-project and select *Build Project*. You should get a message that says
-``**** Build Finished ****`` in the CCS Console.
-
-Task 3 - Hardware Setup
------------------------
-
-.. Warning::
-   The EVM board is sensitive to electrostatic discharges
-   (ESD). Use a grounding strap or other device to prevent damaging the
-   board. Be sure to connect communication cables before applying power to
-   any equipment.
-
-Hardware setup will vary depending on which EVM you are using. Generally,
-you need to make sure that the boot switches are set correctly and that serial,
-a JTAG debug probe, and power are connected to the board.
-
-Refer to the Quick Start Guide that came with your board and the Hardware
-User's Guide for more detailed hardware setup information.
-
-- AM335x EVM:
-
-  - `Quick Start Guide`__
-  - `HW User's Guide`__
-- AM437x EVM:
-
-  - `Quick Start Guide`__
-  - `HW User's Guide`__
-- AM572x EVM:
-
-  - `Quick Start Guide`__
-  - `HW User's Guide`__
-- AM654x EVM
-  - `Quick Start Guide`__
-
-__ http://www.ti.com/lit/ml/sprw225d/sprw225d.pdf
-__ http://processors.wiki.ti.com/index.php/AM335x_General_Purpose_EVM_HW_User_Guide
-__ http://www.ti.com/lit/ml/sprw256/sprw256.pdf
-__ http://processors.wiki.ti.com/index.php/AM437x_General_Purpose_EVM_HW_User_Guide
-__ http://www.ti.com/lit/ug/sprw275/sprw275.pdf
-__ http://www.ti.com/lit/pdf/spruig1
-__ http://www.ti.com/lit/pdf/sprw323
-
-Example connections for the AM572x EVM are provided below:
-
-Front
-^^^^^
-.. image:: /images/am572x-evm-hw-setup-front.jpg
-   :scale: 50 %
-
-Back
-^^^^
-.. image:: /images/am572x-evm-hw-setup-back.jpg
-   :scale: 44 %
-
-Task 4 - Loading and Running the Template Application
------------------------------------------------------
-
-Creating a Target Configuration File
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In order to connect to the target platform we first need to create a target
-configuration file. To do this, open CCS and go to the *File --> New -->
-Target Configuration File* menu and create a new target configuration file
-named after your board. For example, **am572x-evm.ccxml**. Next, you need to
-choose your *connection* and *board* on the target configuration file page.
-The *connection* is your chosen JTAG Debug Probe (for example, the XDS200) and
-the *board* is the name of your EVM (either *EVMAM3358*, *EVMAM437X*, or
-*GPEVM_AM572x_SiRevA*).
-
-For example, here is the target configuration for the AM572x EVM using an
-XDS200 Debug Probe:
-
-.. image:: /images/am572x-evm-target-config.png
-   :scale: 70 %
-
-After setup is complete, clike the *Save* button to save your target
-configuration. Then click *Test Connection* to verify that you can connect
-to the board. If the test is successful you should receive the following
-message::
-
-    The JTAG DR Integrity scan-test has succeeded.
-
-Connecting to the Target
-^^^^^^^^^^^^^^^^^^^^^^^^
-With our target configuration confirmed, we can now move on to connecting to
-the target and loading our application.
-
-First, set up the UART connection using the following host configuration
-in your favorite serial terminal program (e.g. Tera Term, screen, Minicom):
-
--  **Baud Rate**: 115200
--  **Data Bits**: 8
--  **Parity**: None
--  **Flow Control**: Off
-
-Next, click on *View --> Target Configurations* in CCS. Then, right click on
-the target configuration that you created earlier and click *Launch Selected
-Configuration*. This action will switch CCS into the debug perspective. Your
-CCS instance should look similar to below:
-
-.. image:: /images/ccs-debug-pers.png
-   :scale: 70 %
-
-In the top left corner of CCS you should see a list of all of the available
-cores on your device. Right click on the primary core (listed below) and choose
-the *Connect Target* option. During this process you should see GEL output in
-the CCS console and the status of the core should change from "Disconnected"
-to "Suspended".
-
-Primary cores for each target:
-
-+--------+--------+--------+--------+
-| AM335x | AM437x | AM572x | AM654x |
-+========+========+========+========+
-|   A8   |   A9   | A15_0  | A53_0  |
-+--------+--------+--------+--------+
-
-.. Note::
-   For AM572x EVM, the template application can also run on the M4 and DSP
-   cores. If you intend to run the application on one of these cores you must
-   still connect to the main A15_0 core **first**. After connecting to the
-   A15_0 core you can then follow the same procedure as above to connect
-   to the secondary core where you would like to run the application. Do not
-   attempt to load and run the template application on two cores simultaneously
-   as the Template Application is not designed to run this way.
-
-   Similar instructions apply to AM654x EVM, where you should connect to the M3
-   core first before running on your application core.
-
-Running the Application
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Now that we are connected to the target, it is time to load the application.
-To do this, go to the *Run --> Load --> Load Program* menu in CCS. Then, click
-the *Browse project...* button and choose the
-**[rtos or baremetal]_template_app_<board>_<core>.out** executable. Then click *OK* to load
-the executable.
-
-.. image:: /images/load-executable.png
-
-You should now see the **main.c** file open in CCS and the program halted at
-the beginning of the ``main()`` function. At this point you can click on the
-*Resume (F8)* |resume| button to start executing the Template Application.
-
-.. |resume| image:: /images/resume-button.png
-
-The application will begin running and print progress over the UART. You should
-see the following text printed to your serial terminal::
-
-    Board Init complete
-    Uart Init complete
-    I2C Init complete
-    Gpio Init complete
-    MCSPI Init complete
-    ======== Peripheral Initialization complete ========
-
-    ======== Starting to create application tasks ========
-
-    gpio_toggle_led_task task created.
-    uart_task task created.
-    spi_test_task task created.
-    i2c_eeprom_read_and_display_task task created.
-    ======== Application tasks created successfully ========
-
-    gpio_toggle_led task started
-    uart_task task started
-
-    i2c_eeprom_read_and_display task started
-    spi_test task started
-    Board Name read: AM572PM_
-    Board version read: A.30
-    spi_test task ended
-    i2c_eeprom_read_and_display task ended
-    uart_task :Enter a word or Esc to quit >
-
-Type a word into the serial terminal. It should be echoed back to you. Then,
-enter the ``ESC`` character to exit the Template Application. For example::
-
-    uart_task :Enter a word or Esc to quit >hello
-    Data received is:hello
-
-    uart_task :Enter a word or Esc to quit >test
-    Data received is:test
-
-    uart_task :Enter a word or Esc to quit >^[
-
-    uart_task task ended
-    Template app ended
-
-Next, click the *Terminate* |terminate| button to disconnect from the target.
-At this point you have successfully imported, built, and run the Template
-Application.
-
-.. |terminate| image:: /images/terminate-button.png
-
-Task 5 - Examining the Template Application
-------------------------------------------------
-Now that you're familiar with using the Template Application, let us look into
-the code to see how it all works.
-
-The main.c File
-^^^^^^^^^^^^^^^
-Begin by opening the **main.c** file. At the top of this file, after the
-copyright header, there are a series of ``#include`` statements gathering
-the necessary header files for the application:
-
-.. code-block:: c
-
-    /* Standard header files */
-    #include <string.h>
-
-    /* XDCtools Header files (RTOS only) */
-    #include <xdc/std.h>
-    #include <xdc/cfg/global.h>
-    #include <xdc/runtime/System.h>
-    #include <xdc/runtime/Error.h>
-
-    /* BIOS Header files (RTOS only) */
-    #include <ti/sysbios/BIOS.h>
-    #include <ti/sysbios/knl/Task.h>
-
-    /* Board header file */
-    #include <ti/board/board.h>
-
-    /* Local template app header file */
-    #include "app.h"
-
-- (RTOS only) XDCtools provides configuration tools to create and build a static
-  configuration as part of your application. These headers are necessary
-  for the ``*.cfg`` configuration files.
-- (RTOS only) BIOS is a synonym for TI-RTOS. These headers are necessary for accessing
-  common RTOS features such as tasks.
-- The Board Library is a thin utility
-  layer on top of  CSL and other board utilities. It provides uniform
-  Application Programming Interfaces (APIs)
-  for all supported boards. It aims to assist the user to quickly write
-  portable applications for supported boards by hiding board level details
-  from the user.
-- The ``app.h`` header file includes header files for drivers used
-  in the application code as well as macros and function prototypes.
-  Specifically, ``app.h`` includes headers for the following LLDs
-  which are used by the application:
-
-    .. code-block:: c
-
-        /* Low level driver header files */
-        #include <ti/drv/gpio/GPIO.h>
-        #include <ti/drv/uart/src/UART_utils_defs.h>
-        #include <ti/drv/uart/UART_stdio.h>
-        #include <ti/drv/uart/UART.h>
-        #include <ti/drv/i2c/I2C.h>
-        #include <ti/drv/spi/MCSPI.h>
-
-Next, we come across the ``main()`` function which demonstrates the common
-procedure for initializing an RTOS or bare-metal application. You can read the comments in
-the code for further clarification. Let's break down the steps:
-
-1) Initialize the board::
-
-    Board_initCfg boardCfg;
-    boardCfg =
-        BOARD_INIT_PINMUX_CONFIG |
-        BOARD_INIT_MODULE_CLOCK |
-        BOARD_INIT_UART_STDIO;
-    Board_init(boardCfg);
-
-2) Intialize the peripherals::
-
-    UART_init();
-    I2C_init();
-    GPIO_init();
-    MCSPI_init();
-
-3) (RTOS only) Create the application tasks. We will discuss this further in the section
-   covering the ``app.c`` file.
-
-4) Start BIOS (RTOS) or start the application tasks directly (Bare-metal)::
-
-    BIOS_start();
-
-    or
-
-    appRunTasks();
-
-The app.c File
-^^^^^^^^^^^^^^
-
-**RTOS**
-
-Open the **app.c** file and take a look at the ``appTasksCreate()``
-function. You should recall that this function was called in step three
-of ``main()``. Inside of ``appTasksCreate()`` there are ``biosTaskCreate()``
-function calls for each peripheral task. ``biosTaskCreate()`` just wraps the
-common task creation procudure into an easy-to-use function call. Navigate to
-the bottom of the **app.c** file to check out ``biosTaskCreate()``.
-
-The task creation procudure is as follows:
-
-1) Create task variables
-
-    .. code-block:: c
-
-            Task_Params taskParams;
-            Error_Block eb;
-            Task_Handle task;
-
-2) Initialize ``Error_Block`` and ``Task_Params`` to their default values
-
-    .. code-block:: c
-
-        Error_init(&eb);
-        Task_Params_init(&taskParams);
-
-3) Apply user arguments for stack name, priority, and stack size
-
-    .. code-block:: c
-
-            taskParams.instance->name = taskName;
-            taskParams.priority = taskPriority;
-            taskParams.stackSize = stackSize;
-
-4) Create the task
-
-    .. code-block:: c
-
-        task = Task_create(taskFunctionPtr, &taskParams, &eb);
-
-The tasks themselves are simply functions in your code following the format
-below:
-
-.. code-block:: c
-
-    void myTaskFunc(UArg arg0, UArg arg1)
-
-**Bare-metal**
-
-Open the **app.c** file and take a look at the ``appRunTasks()`` function.
-Inside of ``appRunTasks()`` there are function calls for each peripheral task.
-This file also contains setup code for a timer interrupt that controls
-the LED blink task.
-
-.. note::
-   The application functions are called "tasks" for naming consistency
-   with the RTOS template application, but they are not actual SYS/BIOS
-   tasks.
-
-Next, let's take a look at ``i2c_eeprom_read_and_display_task()`` to
-see how to use TI Drivers. The procedure for opening a TI Driver generally
-follows these steps:
-
-1) Create driver handle and params structure
-
-    .. code-block:: c
-
-        I2C_Handle      handle;
-        I2C_Params      params;
-
-2) Initialize and set the driver parameters
-
-    .. code-block:: c
-
-        I2C_Params_init(&params);
-        params.transferMode  = I2C_MODE_CALLBACK;
-        params.transferCallbackFxn = someI2CCallbackFunction;
-        // etc...
-
-3) Open the driver
-
-    .. code-block:: c
-
-        handle = I2C_open(someI2C_configIndexValue, &params);
-        if (!handle) {
-            System_printf("I2C did not open");
-        }
-
-For more information on TI Drivers, check out the included documentation for
-each driver at **pdk_<platform>_<version>/packages/ti/drv/<driver>/docs**.
-
-For more infomation on SYS/BIOS, check out the  User Guide at
-**bios_<version>/docs**.
-
-Task 6 - Modifying the RTOS Template Application
-------------------------------------------------
-.. note::
-   The instructions below apply to the RTOS Template Application only.
-
-Now that you have an understanding of how to use the drivers and create RTOS
-tasks, let us make some simple modifications to create our own application.
-
-We will create a simple application which allows the user to control the LED
-blink rate over the UART terminal. The user should be able to enter an LED
-blink period (between 0 and 5 seconds) and the user LED
-should blink at that rate.
-
-This part of the lab is broken down into several sections. In each section,
-you will be given general instructions for modifications to make to the source
-files. After you make your own modifications they will be verified against
-provided code examples. Try to make the modifications on your own before
-looking at the answers!
-
-Delete the Code You Don't Need
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The Template Application has tasks for UART, I2C, GPIO, and MCSPI drivers. Some
-of these tasks will not be used by our application. Go ahead and remove any
-tasks that you do not think you will need to create the
-application. Hold off on modifying tasks that will be reused until later
-steps.
-
-.. attention::
-   Don't peek! The next section will discuss answers to the task above.
-
-Since our application is only consuming user input and blinking the LEDs, we
-only need the UART and GPIO tasks. That means the I2C and SPI tasks can be
-removed.
-
-Add Support for Additional Features
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Our application will require that the UART task has a way to communicate the
-delay value it receives from the user to the LED task to modify the blink rate.
-While this could be accomplished with something as simple as a shared global
-variable, TI-RTOS provides many other ways to accomplish inter-process
-communication. Take a look at the BIOS User Guide, which is bundled with the
-SDK at **bios_<version>/docs/Bios_User_Guide.pdf** for ideas on how to share
-data between tasks. After you decide on a method, you can use the API
-documentation located at **bios_<version>/docs/Bios_APIs.html** to figure out
-how to use the API in your application.
-
-.. attention::
-   Don't peek! The next section will discuss answers to the task above.
-
-A good choice for passing the LED blink rate is the ``ti.sysbios.knl.Mailbox``
-module. This module can be used to pass buffers from one task to another on the
-same processor.
-
-To include ``Mailbox`` in your project you first need to add the module to the
-**app.cfg** file:
-
-.. code-block:: javascript
-
-    var Mailbox = xdc.useModule('ti.sysbios.knl.Mailbox');
-
-Next, you need to include the ``ti/sysbios/knl/Mailbox.h`` header file in
-**app.h**:
-
-.. code-block:: c
-
-    #include <ti/sysbios/knl/Mailbox.h>
-
-To create a Mailbox, use the ``Mailbox_create()`` API which is defined below:
-
-.. code-block:: c
-
-    Mailbox_Handle Mailbox_create(SizeT             bufsize,
-                                  UInt              numBufs,
-                                  Mailbox_Params    *params,
-                                  Error_Block       *eb)
-
-You are now set up to use ``Mailbox`` in your application code.
-
-Add New Application Code
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Modify the existing UART and LED task code to functions for the new application.
-If you run in to any issues, make sure to use CCS debug features such as
-breakpoints and variable watching to verify that the application is functioning
-in the way that you expect. Functional example code for the AM572x EVM will be
-provided at the end.
-
-.. attention::
-   Don't peek! The next section will discuss answers to the task above.
-
-1) Create a global ``Mailbox_Handle`` to be shared by the ``uart_task()`` and
-   ``gpio_toggle_led_task()``. Then create a Mailbox at the end of the
-   ``appTasksCreate()`` function.
-2) Modify the ``uart_task()`` code to scan for an unisgned integer delay value
-   instead of a string. This value should then be placed in the Mailbox by
-   using the ``Mailbox_post()`` API.
-3) Modify ``gpio_toggle_led_task()`` to retrieve a delay value from the
-   Mailbox via the ``Mailbox_pend()`` API. This delay value should be used in
-   the ``task_sleep()`` function calls.
-
-Now, give your project a try. You should be able to type in LED delay values to
-the UART terminal and see the blink rate of the LED change accordingly. To see
-a functioning solution, you can download the modified source files from the
-links below. Sections of the source files that were modified from the originals
-are marked with a ``/* Modification: */`` comment.
-
-  - :download:`app.c <../example_code/template_app_mods/app.c>`
-  - :download:`app.h <../example_code/template_app_mods/app.h>`
-  - :download:`app.cfg <../example_code/template_app_mods/app.cfg>`
-
-|
-
-Additional Information
-======================
-Porting to a Custom Board
--------------------------
-The Template Application can be easily modified to run on a custom board. The
-major change required is to link in a new Board Library. Modifying the
-Template Application for your custom Board can be achieved by simply removing
-the ``ti.board`` library and PATH from the project and replacing with your
-specific board libraty and PATH under the linker build options in CCS by
-right clicking on the project and selecting
-*Properties --> GNU Linker --> Libraries*.
-
-For example, currently the library linked for AM572x is specified in the
-**.projectspec** file as follows::
-
-    linkerBuildOptions=
-        -L${TI_PDK_INSTALL_DIR}/packages/ti/board/lib/evmAM572x/a15/release/
-        -l:ti.board.aa15fg
-
-.. note::
-   Currently for AM572x EVM there is also a dependemcy on the
-   **GPIO_evmAM572x_board.c** and **GPIO_board.h** files. These files can be
-   modified for your custom board.
-
-Next Steps
-==========
-Thanks for taking the time to read through this getting started workshop.
-At this point you should be comfortable with the basic structure of the SDK,
-know how to import, build, modify, and run applications on the target, and know
-where to find various documentation in the SDK and Software Developer Guide.
-
-Next, you can check out our various video training series in the `TI training
-portal`__, check out our
-`Examples and Demonstrations <index_examples_demos.html>`__, and get
-started writing your own application!
-
-__ https://training.ti.com/
-
-If you have any questions along the way please remember to read the
-`FAQ <index_faq.html>`__ or reach out to our engineers on the `E2E forums`__.
-
-__ http://e2e.ti.com/
diff --git a/source/rtos/Examples_and_Demonstrations/_SimpleLink_WiFi_Demo.rst b/source/rtos/Examples_and_Demonstrations/_SimpleLink_WiFi_Demo.rst
deleted file mode 100644
index 8fe3ecc82..000000000
--- a/source/rtos/Examples_and_Demonstrations/_SimpleLink_WiFi_Demo.rst
+++ /dev/null
@@ -1,241 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_SimpleLink_WiFi_Demo
-
-
-Overview
-========
-
-This page describes the SimpleLink WiFi Demo provided in the
-Processor-SDK for RTOS. This demo illustrates the integration of CC3120
-BoosterPack and AMIC110 ICE using components in the SDK to provides a
-low cost WiFi solution for application development.
-
-
-Supported platforms
-===================
-
--  iceAMIC110 ( A8 )
-
-
-Requirements
-============
-
-Following are required to run the application:
-
-Hardware
-
--  TI CC3120 BoosterPack
--  TI EVM (see list above)
--  Blue wires between CC3120 BP and AMIC110 ICE
--  Serial UART cable (provided in EVM kit)
--  Connection Diagram
-
-   .. Image:: /images/sl_wifi_demo_connection.jpg
-
--  Picture of connected EVMs
-
-   .. Image:: /images/sl_wifi_demo_connected.jpg
-
-Software
-
--  Processor-SDK RTOS 5.1.0 and later
--  Code Composer Studio 8.0 and later
-
-
-Components Used
-===============
-
-RTOS Components:
-
--  SYS/BIOS
--  XDCTools
--  Processor SDK RTOS PDK: SPI, UART, GPIO LLDs, OSAL, Board etc.
-
-
-Software Design
-===============
-
-The demo implemented a network terminal application to illustrate
-how the SimpleLink WiFi Plugin for Processor SDK RTOS can be used to provide
-a low cost solution for Sitara devies (AM3/4/5). The AMIC110 ICE and CC3120
-BoosterPack are connected via SPI and GPIO pins. The SPI interface will provide
-The data and command channels for SimpleLink WiFi Plugin, while the GPIO pins
-are providing the INT and RESET signals.
-
-The following diagram shows the overview of the demo:
-
-.. Image:: /images/sl_wifi_demo_overview.jpg
-
-
-The source files are organized as follows:
-
-::
-
-              └── simplelink-wifi-demo
-                  ├── bin --> Folder for the executables
-                  ├── examples --> Demo source code, projectspec file and makefile
-                  ├── lib --> Folder for SimpleLink WiFi Plugin liraray
-                  ├── source --> Folder for SimpleLink WiFi Plugin source
-
-
-How to Build the SimpleLink WiFi Plugin Demo using CCS
-=====================================
-
-Please follow below step by step procedure to build the application.
-
-#. Install Code Composer Studio.
-#. Install Processor SDK RTOS for the respective platform needed, in a
-   location where CCS expects: (by default $HOME/ti or c:/ti) Refer
-   :ref:`Processor SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-   for details.
-#. Open CCS:
-#. Click Project-->Import CCS Projects and select network_terminal_AMIC110_ICE_RTOS_ccs
-   under directory :
-   processor_sdk_rtos_<platform>_<version>/demos/simplelink-wifi-demo/
-#. Build the application . ( By right clicking on imported project and
-   clicking "Build project")
-
-.. note::
-   This will create executable binary under <CCS_Workspace>/network_terminal_AMIC110_ICE_RTOS_RTOS_ccs/Debug/network_terminal_AMIC110_ICE_RTOS_RTOS_ccs.out
-
-.. Image:: /images/sl_wifi_demo_ccs_import.jpg
-
-
-How to Build the SimpleLink WiFi Plugin Demo using makefile on Windows
-=====================================
-
-Please follow below step by step procedure to build the application.
-
-#. Install Processor SDK RTOS for the respective platform needed, in a
-   location where CCS expects: (by default c:/ti) Refer
-   :ref:`Processor SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-   for details.
-#. Under DOS command prompt type:
-#. cd processor_sdk_rtos_<platform>_<version>/ folder
-#. setupenv.bat
-#. cd processor_sdk_rtos_<platform>_<version>/demos/simplelink-wifi-demo/examples\rtos/AMIC110_ICE/demos/network_terminal/tirtos/ccs
-#. gmake clean
-#. gmake all
-#. The executable binary will be generated under
-   processor_sdk_rtos_<platform>_<version>/demos/simplelink-wifi-demo/examples\rtos/AMIC110_ICE/demos/network_terminal/tirtos/ccs and
-   The executable network_terminal.out, boot image files network_terminal.bin and app will be under
-   processor_sdk_rtos_<platform>_<version>/demos/simplelink-wifi-demo/bin/am335x/a8/debug
-
-
-How to Build the SimpleLink WiFi Plugin Demo using makefile on Linux
-=====================================
-
-Please follow below step by step procedure to build the application.
-
-#. Install Processor SDK RTOS for the respective platform needed, in a
-   location where CCS expects: (by default $HOME/ti) Refer
-   :ref:`Processor SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-   for details.
-#. Under Linux command prompt type:
-#. cd processor_sdk_rtos_<platform>_<version>/ folder
-#. source setupenv.sh
-#. cd processor_sdk_rtos_<platform>_<version>/demos/simplelink-wifi-demo/examples\rtos/AMIC110_ICE/demos/network_terminal/tirtos/ccs
-#. make clean
-#. make all
-#. The executable binary will be generated under
-   processor_sdk_rtos_<platform>_<version>/demos/simplelink-wifi-demo/examples\rtos/AMIC110_ICE/demos/network_terminal/tirtos/ccs
-
-
-How to Run the SimpleLink WiFi Plugin Demo using CCS
-===================================
-
-You will need the following:
-
-#. Install Code Composer Studio to load and run the Template
-   Application. Refer to :ref:`Processor SDK RTOS Getting Started
-   Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>` for
-   installing CCS.
-#. AMIC110 ICE board
-#. JTAG Emulator
-
-To load and run SimpleLink WiFi Plugin Demo:
-
-#. Connect the computer to the JTAG port on the board using the JTAG
-   emulator.
-#. Power on the EVM/board. Ensure that no boot mode is
-   entered (do not have SD card loaded or QSPI flashed)
-#. Open up a serial terminal for UART communication (Refer to :ref:`Processor
-   SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`, setup
-   EVM hardware)
-#. Open CCS and launch target config file for the EVM (Refer to
-   `Processor SDK RTOS Setup
-   CCS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__ for setting up CCS)
-#. Connect to the primary core to make sure on connect gels are run
-   A8 core for AM335x
-#. Connect to core where the application is expected to run, if not the primary core.
-#. Load executable by clicking("Run --> Load --> Load Program.). Click
-   on Browse Project and select outfile under:
-   <CCS_Workspace>/network_terminal_AMIC110_ICE_RTOS_RTOS_ccs/Debug/network_terminal_AMIC110_ICE_RTOS_RTOS_ccs.out
-#. Run application by clicking the Run icon. ( Or Click Run --> Resume)
-
-Now the network terminal demo will run and print progress through the UART.
-
--  The inital display on the UART
-.. Image:: /images/sl_wifi_demo_uart_init.jpg
-
--  Enter "help" at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_help.jpg
-
--  Enter "scan -n 10" at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_scan.jpg
-
--  Enter " wlanconnect -s "dir645" -t WPA/WPA2 -p "12345678" " at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_wlanconnect.jpg
-
--  Enter "ping 192.168.0.1" at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_ping.jpg
-
-.. note::
-   This demo uses the D-Link DIR-645 wirless router with DHCP server. "dir645" is its SSID. "12345678" is its
-   connection password. "192.168.0.1" is its default gateway. Users should adjust those parameters according
-   to their own wireless routers.
-
-
-How to Run the SimpleLink WiFi Plugin Demo using UART Boot
-===================================
-
-To load and run SimpleLink WiFi Plugin Demo:
-
-#. Connect the J3 to the USB port on a PC via the UART to USB cable.
-#. Power on the EVM/board.
-#. Open up a serial terminal for UART communication (Refer to :ref:`Processor
-   SDK RTOS Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`, setup
-   EVM hardware)
-#. Send the bootloader_boot_uart_a8host_debug.bin under
-   pdk_<platform>_<version>/packages/ti/starterware/binary/bootloader/bin/am335x-evm/gcc
-   using the XMODEM.
-
-   .. Image:: /images/sl_uart_boot_1st.jpg
-
-#. Upon completion,  then send the network_terminal.bin under
-   processor_sdk_rtos_<platform>_<version>/demos/simplelink-wifi-demo/bin/am335x/a8/debug
-   using the XMODEM.
-
-   .. Image:: /images/sl_uart_boot_2nd.jpg
-
-Now the network terminal demo will run and print progress through the UART.
-
--  The inital display on the UART
-.. Image:: /images/sl_wifi_demo_uart_init.jpg
-
--  Enter "help" at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_help.jpg
-
--  Enter "scan -n 10" at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_scan.jpg
-
--  Enter " wlanconnect -s "dir645" -t WPA/WPA2 -p "12345678" " at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_wlanconnect.jpg
-
--  Enter "ping 192.168.0.1" at UART prompt
-.. Image:: /images/sl_wifi_demo_uart_ping.jpg
-
-.. note::
-   This demo uses the D-Link DIR-645 wirless router with DHCP server. "dir645" is its SSID. "12345678" is its
-   connection password. "192.168.0.1" is its default gateway. Users should adjust those parameters according
-   to their own wireless routers.
-
diff --git a/source/rtos/Examples_and_Demonstrations/_Sofware_Diagnostics_Reference.rst b/source/rtos/Examples_and_Demonstrations/_Sofware_Diagnostics_Reference.rst
deleted file mode 100644
index 16dfb90bc..000000000
--- a/source/rtos/Examples_and_Demonstrations/_Sofware_Diagnostics_Reference.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-
-Introduction
-============
-
-This page describes the Software Diagnostics Reference (SDR) code and test framework provided as part of the SDK.
-
-This SDR is supported on:
-
--  J721E (MCU R5F)
-
-The Software Diagnostic Reference code can be found in the following directory.
-pdk/packages/ti/diag/sdr
diff --git a/source/rtos/FAQ.rst b/source/rtos/FAQ.rst
deleted file mode 100644
index b73ec227c..000000000
--- a/source/rtos/FAQ.rst
+++ /dev/null
@@ -1,1251 +0,0 @@
-.. _index-faq:
-
-############################
-Frequently Asked Questions
-############################
-
-.. toctree::
-   :maxdepth: 5
-
-   index_faq
-
-Processor SDK RTOS software is tested and validated on TI evaluation platforms that generally includes the superset part
-in the device family however, the software components like CSL, LLD drivers and RTOS are applicable on reduced feature set
-variant of the devices. Most of the code in the Processor SDK RTOS for multi-core devices is independent of how many cores
-exists on the device as they provide baseline platform software that can be run from any core.
-
-It is the users responsibility to modify components that deploy tasks/software on slave cores like OpenMP, OpenCL, IPC and MultiProc Manager
-so that they use the feature set that is available on their device. In most cases software documentation will provide guidance on updating
-the software package however this should not be considered a comprehensive list of software components to be updated
-to run the software on a reduced feature set device variant.
-
-Example: `Processor SDK RTOS porting guide for AM571x/AM570x Speed
-Grades <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Porting_Guide_for_AM571x/AM570x_Speed_Grades>`_
-
-Features noted as “not supported,” in device datasheet must not be used. Their functionality is not supported by TI for this
-family of devices. These features are subject to removal without notice on future device revisions. Any information regarding
-the unsupported features has been retained in the documentation solely for the purpose of clarifying signal names or for consistency
-with previous feature descriptions.
-
-|
-
-Training and Documentation
-==========================
-
-.. rubric:: Is there any training content available for Processor SDK
-   RTOS?
-   :name: is-there-any-training-content-available-for-processor-sdk-rtos
-
-There are multiple Processor SDK RTOS training modules available online
-as part of the `Processor SDK Training
-Series <https://training.ti.com/processor-sdk-training-series>`__. Link
-to the complete series or refer to the direct links below:
-
-Training URLs:
-
--  `Processor SDK RTOS Overview Part
-   I <https://training.ti.com/introduction-processor-sdk-rtos-part-1?cu=519268>`__
--  `Processor SDK RTOS Overview Part
-   II <https://training.ti.com/introduction-processor-sdk-rtos-part-2?cu=519268>`__
--  `Application Development Using Processor SDK
-   RTOS <https://training.ti.com/application-development-using-processor-sdk-rtos?cu=519268>`__
-
-.. rubric:: What documentation exists for Processor SDK RTOS?
-   :name: what-documentation-exists-for-processor-sdk-rtos
-
-There are three main documents for Processor SDK RTOS:
-
--  :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-   Provides information on setting up software and running basic
-   examples/demonstrations bundled within the Processor SDK.
--  :ref:`Software Developer
-   Guide <rtos-index>`:
-   Provides information on features, functions, delivery package, and
-   compile tools for the Processor SDK RTOS release. This guide also
-   provides detailed information regarding software elements and
-   software infrastructure to allow developers to start creating
-   applications.
--  :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>`: Provides
-   migration information for applications built on top of the Processor
-   SDK for RTOS.
-
-|
-
-Host and Target Setup
-=====================
-
-.. rubric:: How do I setup the build environment with custom Processor
-   SDK RTOS and CCS Installation paths on the host machine?
-   :name: how-do-i-setup-the-build-environment-with-custom-processor-sdk-rtos-and-ccs-installation-paths-on-the-host-machine
-
-The steps to set up CCS and Processor SDK RTOS when the SDK or the IDE
-is installed in a location other than the default location are described
-below: `Processor SDK RTOS Setup with CCS <How_to_Guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__.
-
-A common gotcha while setting up the build environment is
-compatibility with CCS version. Please refer to :ref:`Release
-Notes <processor-sdk-rtos-release-notes>` for the
-recommended version of CCS.
-
-.. rubric:: Can I install multiple versions of the Processor SDK RTOS in
-   the same folder?
-   :name: can-i-install-multiple-versions-of-the-processor-sdk-rtos-in-the-same-folder
-
-Typically, the version numbers of most components (PDK, Processor SDK,
-BIOS, XDC, etc.) will be updated in the newer release. However there are
-components like DSPLIB, IMGLIB, etc. and EDMA drivers that may remain
-the same. The safe option would be to install the most current Processor
-SDK in a custom location. You can have multiple versions of the SDK for
-different devices on your machine and install all of them in custom
-folders. For example, if you have a project with AM335x and AM437x that
-requires you to download the Processor SDK RTOS for those device, we
-recommend that you install them under different directories say
-C:\\ti\\PRSDK_AM3x and C:\\ti\\PRSDK_AM4x
-
-.. note::
-   When you install the SDK in a custom location, there are few additional
-   steps to follow:
-
-   -  CCS auto-detects components only in C:\\ti path. So you will need to
-      add the custom path to discovery as described in `Setup
-      CCS <How_to_Guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__.
-   -  Assuming CCS is installed in the default path, the process to set the
-      custom SDK path while building the SDK is provided in `Install in
-      Custom Path <How_to_Guides.html#update-environment-when-installing-to-a-custom-path>`
-
-.. rubric:: What are the typical flows for a new user to setup the
-   Processor SDK RTOS development environment?
-   :name: what-are-the-typical-flows-for-a-new-user-to-setup-the-processor-sdk-rtos-development-environment
-
-The typical Processor SDK RTOS setup steps have been described below:
-
-.. rubric:: Step 1: Basic Hardware, SDK, and IDE Setup
-   :name: step-1-basic-hardware-sdk-and-ide-setup
-
-Setup the software and hardware as described in the :ref:`Getting Started
-Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-At this stage, you should have the CCS IDE environment, the Processor
-SDK RTOS installed and be able to connect to your target using an
-emulator.
-
-.. note::
-   If you have installed CCS and/or the Processor SDK RTOS in a custom
-   location, you need to manually add the SDK install path to CCS as
-   described here
-   `CCS_and_SDK_installed_in_different_directories <How_to_Guides.html#ccs-and-sdk-installed-in-different-directories>`__
-
-.. rubric:: Step 2: Run the Out-of-Box Examples or Diagnostics
-   :name: step-2-run-the-out-of-box-examples-or-diagnostics
-
-The SDK and CCS ships with some pre-built out-of-box
-demonstrations/examples that can be flashed on to the EVM, copied over
-to an SD card, or loaded over emulator so that you can bring up and test
-the EVM hardware. The steps to flash and run the out-of-box examples are
-described here:
-
--  `Running_examples.2Fdemonstrations <Examples_and_Demonstrations.html#examples-and-demonstrations>`__
-
-.. rubric:: Step 3: Build Environment Setup
-   :name: step-3-build-environment-setup
-
-Processor SDK RTOS provides a script to set up the Windows and Linux
-environment with the component and compiler PATHs. Running the script
-and rebuilding the Processor SDK from the root directory is described in
-the wiki article `Setup build Environment <Overview.html#setup-environment>`.
-
-.. note::
-
-   -  The script assumes that CCS and Processor SDK RTOS are installed in
-      the default location. If you have installed CCS and/or the Processor
-      SDK RTOS in a custom location, then modify the setup file to the
-      custom path. Please setup the environment using the steps described
-      in the wiki article
-      `Processor SDK RTOS Install in Custom Path <How_to_Guides.html#update-environment-when-installing-to-a-custom-path>`__
-   -  After the script executes, it prints all the PATH macros set for the
-      different variables. Be sure that the compiler and component paths
-      have been setup correctly.
-
-
-.. rubric:: Step 4: Rebuilding the SDK
-   :name: step-4-rebuilding-the-sdk
-
-The critical device-specific components of the Processor SDK RTOS can be
-rebuilt from the top-level make file provided in the root directory
-processor_sdk_rtos_x_xx_xx_xx. Invoking the build and available options
-from top-level make files is described in the wiki article `Rebuilding
-SDK
-Components <Overview.html#top-level-makefile>`__.
-
-.. note::
-   The SDK offers command line build for all the components. CCS projects
-   are only supported for DSP libraries and PDK driver examples.
-
-.. rubric:: Step 5: Generate and Run Peripheral Driver Examples
-   :name: step-5-generate-and-run-peripheral-driver-examples
-
-The PDK component in Processor SDK RTOS provides drivers for different
-IPs on the SOC and provides unit tests and examples for the drivers to
-test them on a specific board/hardware. These examples do not ship with
-pre-generated CCS projects and require users to generate a project
-create script to generate the CCS project for the unit tests. The
-procedure to generate the CCS projects for a given SOC is described in
-this article
-`PDK_Example_and_Test_Project_Creation <How_to_Guides.html#pdk-example-and-test-project-creation>`__.
-
-.. rubric:: Step 6: Exploring Other Components in the SDK
-   :name: step-6-exploring-other-components-in-the-sdk
-
-The SDK package includes several other components that allow application
-developers to develop software for multi-core devices. This includes an
-inter-processor communication component known as (IPC). For SOCs that
-contain an C66x DSP, the SDK provides several optimized DSP libraries
-(DSPLIB, MATHLIB and IMGLIB). These components also ship with pre-built
-examples that can be built using build steps described in their
-documentation that is linked at the top level :ref:`Software Developer
-Guide <rtos-index>`.
-
-|
-
-.. rubric:: How can I optimize the build time when rebuilding the
-   Processor SDK RTOS ?
-   :name: how-can-i-optimize-the-build-time-when-rebuilding-the-processor-sdk-rtos
-
-Processor SDK RTOS top level build will rebuild IPC, all components
-inside the PDK package for all supported cores and evaluation platforms.
-Building all components can cause long build times. If you wish to only
-rebuild a section of the package, the build times can be significantly
-optimized if you invoke make for specific components in the SDK instead
-of making all components. Also, for the PDK users can invoke the build
-using the following syntax
-
-::
-
-    make LIMIT_BOARDS="<BOARD>" LIMIT_SOCS="<SOC>" LIMIT_CORES="<CORE>"
-
-**SOC** can be am335x, am437x, am571x, am572x, k2g,k2h,k2e, etc.
-
-**CORE** can be “a15_0”, “c66x”, or “ipu1_0”, for a15, c66, m4
-respectively.
-
-**BOARD** can be any evaluation hardware platform that your SOC
-supports.
-
-::
-
-    For Example:
-    make LIMIT_BOARDS="evmK2G iceK2G" LIMIT_SOCS="k2g" LIMIT_CORES="a15_0"
-|
-
-.. rubric:: Why am I not able to connect to the DSP core in CCS when
-   Linux is booted on KeyStone II devices?
-   :name: why-am-i-not-able-to-connect-to-the-dsp-core-in-ccs-when-linux-is-booted-on-keystone-ii-devices
-
-The U-boot code that is booted before booting Linux puts the DSP core in
-reset. In order to connect to the DSP, you need to run a GEL script in
-CCS as described in this article
-`Taking_the_C66x_Out_Of_Reset_with_Linux_Running_on_the_ARM_A15 <How_to_Guides.html#taking-the-c66x-out-of-reset-with-linux-running-on-the-arm-a15>`__.
-
-.. rubric:: How can I create a SD card for Processor SDK RTOS?
-   :name: how-can-i-create-a-sd-card-for-processor-sdk-rtos
-
-Many of the TI-supported EVMs ship with an SD card with Linux Booting as
-part of the EVM out-of-box experience. Users are required to create a
-separate SD card if they want to boot their EVM with Processor SDK RTOS
-out-of-box demonstrations or run board diagnostics. The procedure to
-create an SD differs depending on whether you are doing this on a
-Windows or Linux host machine, as described in the two articles shown
-here:
-
--  `Create an SD card on Windows Host (AMx, K2G only) <Overview.html#windows-sd-card-creation-guide>`__
-
--  `Create an SD card on Linux Host (AMx, K2G only) <Overview.html#linux-sd-card-creation-guide>`__
-
-.. rubric:: How can I restore the firmware on my EVM to factory
-   settings?
-   :name: how-can-i-restore-the-firmware-on-my-evm-to-factory-settings
-
-Most of the Sitara EVMs ship with a bootable SD card that boots Linux.
-To restore the EVM to factory settings, simply reflash the SD card with
-the bootable image using the `SD Card Creation
-Script <http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_create_SD_card_script>`__
-provided in Processor SDK Linux.
-
-For KeyStone Devices, the Processor SDK RTOS provides a `Program EVM
-Script <How_to_Guides.html#default-binaries-and-setup>`__
-with default binaries that reflash images on EEPROM, SPI, and/or NAND
-(depending on the EVM platform used).
-
-.. rubric:: Can I run Processor SDK RTOS on BeagleBone?
-   :name: can-i-run-processor-sdk-rtos-on-beaglebone
-
-Yes, Processor SDK RTOS software can be used to develop and run code on
-BeagleBone platform. In order to test Processor SDK RTOS software on
-BeagleBone, you will need to connect a JTAG to the BeagleBone. With the
-default configuration of the board, we have observed that connecting a
-JTAG causes a reset. Users need to follow the procedure provided here to
-prevent a reset from occurring.
-
--  `Preventing a Reset When Connecting a JTAG on
-   BeagleBone <http://elinux.org/Beagleboard:BeagleBone#Board_Reset_on_JTAG_Connect.28A3.2CA4.2CA5.29>`__
-
-|
-
-Device Drivers
-==============
-
-.. rubric:: How do I find out if a driver is supported in the package
-   for my device?
-   :name: how-do-i-find-out-if-a-driver-is-supported-in-the-package-for-my-device
-
-For all SoC and board-specific driver support, we recommend that you
-refer to the :ref:`Release Notes <RN-Supported-Platforms-label>`
-corresponding to your release.
-
-If you need further details for driver support on all cores on
-heterogeneous multi-core devices, please reach out to the engineering
-team using `E2E forums <http://e2e.ti.com/support/>`__.
-
-.. rubric:: Where can I find example projects for device drivers?
-   :name: where-can-i-find-example-projects-for-device-drivers
-
-The PDK package in processor SDK RTOS does not contain pre-canned CCS
-projects for driver examples. But it does provide scripts to set up the
-development environment and create the example CCS projects based on
-that setup. This allows the SDK the flexibility to create CCS projects
-based on the user-specific host setup. In order to create the example
-projects, users can follow the sequence provided below:
-
-#. Users are required to setup their development environment using
-   `Processor SDK RTOS Setup <Overview.html#setup-environment>`__
-#. Setup the PDK build environment `PDK
-   Setup <How_to_Guides.html#building-pdk-using-gmake-in-windows-environment>`__.
-#. Execute the PdkProjectCreate script in ${PDK_INSTALL_PATH}/packages
-   as described on the `PDK Example and Test Project Creation
-   wiki <How_to_Guides.html#pdk-example-and-test-project-creation>`__
-
-.. rubric:: What is the difference between SOC-specific driver library
-   and the SOC-independent (Generic core-specific) driver library?
-   :name: what-is-the-difference-between-soc-specific-driver-library-and-the-soc-independent-generic-core-specific-driver-library
-
-Each low level driver (LLD) in the PDK package contains two versions of
-the driver library. The naming conventions are as follows:
-
--  **Generic Core-specific Driver Library** :
-   ti.drv.<module>.<core_specific_extension>
-
-Example: ti.drv.gpio.aa15fg (A15 core-specific GPIO driver library)
-
--  **SOC-specific Driver Library**:
-   ti.pdk.<module>.<soc>.<core_specific_extension>
-
-Example: ti.drv.gpio.am572x.aa15fg (A15 GPIO driver library for AM572x)
-
-When using the core-specific driver library, users are required to
-provide SOC-specific driver initialization structures that provide
-information regarding the module instance used, interrupt numbers,
-configuration modes, etc.
-
-The SOC-specific driver library contains a default configuration
-(provided in <module>_soc.c file) built into the library that gets used
-to initialize the driver on TI EVMs and to run sample applications
-provided in driver package. It may need to be modified to suit for a
-custom board and/or target application. The default configuration
-includes a specific peripheral instance, interrupt configuration, etc.
-
-.. rubric:: How to create ARM baremetal CCS project that link to PDK
-   driver libraries using GNU Linker?
-   :name: how-to-create-arm-baremetal-ccs-project-that-link-to-pdk-driver-libraries-using-gnu-linker
-
-The static libraries in Platform development kit (PDK) drivers use the
-convention ti.drv.<module>.a<ARM extension>. For example, the UART
-driver library for A15 is named "ti.drv.uart.aa15fg". This is different
-form the convention of naming the libraries with a suffix of "lib" and
-extension ".a" which is generally the case for ARM compiler libraries
-(e.g., librdimon.a, libgcc.a, libm.a). This is usually not an issue when
-building applications using GCC compiler and make/gmake as libraries can
-be linked using "-l" option. However, when building bare-metal (no-OS)
-ARM projects in CCS, the IDE expects the libraries to have the name with
-suffix "lib" and extension ".a". If developers try to link libraries
-which does not follow this convention, they observe a linking error that
-mentions that the library doesn`t exist. There are a couple of work
-around options available to users when working with baremetal PDK driver
-libraries:
-
-**Option 1:** Add a colon in front of the library name when adding the
-ARM driver library to "Build Settings"->"GNU Linker"->"Libraries" as
-shown below:
-
-.. Image:: ../images/Bare-metal_driver_link.png
-
-**Option 2:** Add driver libraries using linker command file using the
-INPUT syntax
-
-::
-
-    INPUT(
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\drv\gpio\lib\a8\release\ti.drv.gpio.profiling.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\utils\profiling\lib\a8\release\ti.utils.profiling.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\board\lib\icev2AM335x\a8\release\ti.board.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\drv\i2c\lib\a8\release\ti.drv.i2c.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\drv\uart\lib\a8\release\ti.drv.uart.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\csl\lib\am335x\a8\release\ti.csl.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\osal\lib\tirtos\a8\release\ti.osal.aa8fg"
-    )
-
-|
-
-Chip Support Library (CSL)
-==========================
-
-.. rubric:: Are there any bare-metal examples in the PDK package?
-   :name: are-there-any-bare-metal-examples-in-the-pdk-package
-
-Customers who are wanting to start bare-metal code development can refer
-to the diagnostics package which uses the PDK drivers and does not rely
-on the TI RTOS. There are also CSL examples included in the package
-under the path ${PDK_INSTALL_PATH}\\packages\\ti\\csl\\test.
-
-In addition to CSL example, the PDK contains bare-metal diagnostic test
-cases that help in testing EVM functionality. These can be located under
-pdk_am57xx_x_x_x\\packages\\ti\\board\\diag
-
-Some of the driver examples contain a flag for BARE METAL usage of the
-driver. Example: GPIO/SPI already have these flags implemented.
-
-.. rubric:: Can I read core-specific registers on multi-core devices
-   supported in Processor SDK RTOS using CSL code?
-   :name: can-i-read-core-specific-registers-on-multi-core-devices-supported-in-processor-sdk-rtos-using-csl-code
-
-Yes, SDK provides CSL code to read core status and system configurations
-using the CSL provided for specific core. For CSL code specific to cores
-and peripherals present on your device, please refer to the header files
-provided under ${PDK_INSTALL_PATH}\\packages\\ti\\csl\\src\\ip.
-
-A good example of where you may need to access CSL code to read
-core-specific information is on a multi-core device. You can have code
-shared between multiple cores and would like to use a different code
-path or internal buffer based on core ID. The CSL code helps you
-implement this as follows:
-
-For example, if you need to read the core ID on a multi-core DSP device:
-
-::
-
-     uint32_t coreNum;
-     /* Get the core number. */
-     coreNum = CSL_chipReadReg(CSL_CHIP_DNUM);
-
-To do the same on the multi-core A15 device, you can use the following
-code in the A15 CSL:
-
-::
-
-     unsigned int armNum;
-     armNum = CSL_a15ReadCoreId(); //This gets the core ID using the MPIDR in the A15
-
-.. rubric:: How do I find out which CSL header and source files apply to
-   my device?
-   :name: how-do-i-find-out-which-csl-header-and-source-files-apply-to-my-device
-
-The CSL package that is part of the SDK is a unified CSL that covers all
-devices supported by the Processor SDK RTOS. When you link to the CSL
-library or include the header files for a specific IP, the CSL library
-requires users to add a MACRO definition (-D SOC_XX####) to your build
-to indicate which SOC you are using. In order to locate the IP files for
-your device, always look at the header file at the top of the CSL
-directory pdk_<device>_xx_xx_xx\\packages\\ti\\csl and the files that are
-found under the SOC_XX#### corresponds to the SOC that you are using.
-
-SOC-specific files can also be found under the
-pdk_<device>_xx_xx_xx\\packages\\ti\\csl\\soc\\<device_name>
-
-.. rubric:: What is the system memory map used by the SDK examples?
-   :name: what-is-the-system-memory-map-used-by-the-sdk-examples
-
-The TI RTOS-based examples included in the SDK rely on the platform
-definitions provided inside bios_6_xx_xx_xx\\packages\\ti\\platforms for
-partitioning the SOC memory between all the available cores on the SoC.
-Please take a look at the snapshot below for AM572x:
-
-::
-
-    /*  Memory Map for ti.platforms.evmAM572X
-     *
-     *  Virtual     Physical        Size            Comment
-     *  ------------------------------------------------------------------------
-     *              8000_0000  1000_0000  ( 256 MB) External Memory
-     *
-     *  0000_0000 0 8000_0000        100  ( 256  B) --------
-     *              8000_0100       FF00  ( ~64 KB) --------
-     *  0000_0000   8001_0000        100  ( 256  B) --------
-     *              8001_0100       FF00  ( ~64 KB) --------
-     *  0000_0000   8002_0000        100  ( 256  B) --------
-     *              8002_0100       FF00  ( ~64 KB) --------
-     *  0000_0000   8003_0000        100  ( 256  B) --------
-     *              8003_0100    FE_FF00  ( ~16 MB) --------
-     *            1 8100_0000    40_0000  (   4 MB) --------
-     *              8140_0000    C0_0000  (  12 MB) --------
-     *            2 8200_0000    40_0000  (   4 MB) --------
-     *              8240_0000    C0_0000  (  12 MB) --------
-     *            3 8300_0000    40_0000  (   4 MB) --------
-     *              8340_0000    C0_0000  (  12 MB) --------
-     *            4 8400_0000    40_0000  (   4 MB) --------
-     *              8440_0000    C0_0000  (  12 MB) --------
-     *            5 8500_0000   100_0000  (  16 MB) --------
-     *            6 8600_0000   100_0000  (  16 MB) --------
-     *            7 8700_0000   100_0000  (  16 MB) --------
-     *            8 8800_0000   100_0000  (  16 MB) --------
-     *            9 8900_0000   100_0000  (  16 MB) --------
-     *            A 8A00_0000    80_0000  (   8 MB) IPU1 (code, data), benelli
-     *              8A80_0000    80_0000  (   8 MB) IPU2 (code, data), benelli
-     *            B 8B00_0000   100_0000  (  16 MB) HOST (code, data)
-     *            C 8C00_0000   100_0000  (  16 MB) DSP1 (code, data)
-     *            D 8D00_0000   100_0000  (  16 MB) DSP2 (code, data)
-     *            E 8E00_0000   100_0000  (  16 MB) SR_0 (ipc)
-     *            F 8F00_0000   100_0000  (  16 MB) --------
-     */
-
-For bare-metal code, users are required to use a linker command file for
-each of the cores and partition the memory manually so that there is no
-memory overlap in the applications running on each of the cores. For
-bare-metal linker command files, you can refer to the CCS templates for
-`Hello World <Examples_and_Demonstrations.html#no-os-bare-metal-example>`__
-or the linker command file used in the common folder of the the
-diagnostics package.
-
-|
-
-Board Support
-=============
-
-.. rubric:: What steps are involved when creating a new custom board
-   library?
-   :name: what-steps-are-involved-when-creating-a-new-custom-board-library
-
-The board library consolidates all the board-specific information so
-that all the modifications made when moving to a new custom platform
-using the SOC can be made in the source of this library. The following
-steps are involved in creating custom board library:
-
--  **Modify SOC Clock Settings** The core clocks and module clocks used
-   on the custom board library may vary based on the power requirements
-   and external components used on the boards. TI provides `Clock Tree
-   Tools <http://www.ti.com/tool/CLOCKTREETOOL>`__ to simulate the
-   device clocks. We recommend that you test the settings in CCS by
-   creating a GEL file with the modified settings before modifying the
-   source in the board library.
-
--  **Modify SOC DDR:** The board library has the correct DDR
-   initialization sequence to initialize the DDR memory on your board.
-   You may need to make changes to the AC timings, hardware leveling,
-   and DDR PHY configuration, some or all of which may be different than
-   the TI supported platforms. We recommend that you test the settings
-   in CCS by creating a GEL file with the modified settings before
-   modifying the source in the board library.
-
-Useful DDR Configuration Resources
------------------------------------
-
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| Sitara Resources:                                                                                                                | Keystone Resources:                                                  |
-+==================================================================================================================================+======================================================================+
-| `AM57x EMIF Tools <http://www.ti.com/lit/pdf/sprac36>`_                                                                          | `KeyStone II DDR Guide <http://www.ti.com/lit/pdf/sprabx7>`_         |
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| `AM437x DDR Configuration Guide <http://processors.wiki.ti.com/index.php/AM437x_DDR_Configuration_and_Programming_Guide>`_       | `KeyStone II DDR Debug Guide <http://www.ti.com/lit/pdf/sprac04>`_   |
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| `AM335x/AM11x EMIF ConfigurationTools <http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips>`_                 | `KeyStoneI DDR Initialization <http://www.ti.com/lit/pdf/sprabl2>`_  |
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-
--  **Modify SoC Pin Mux Settings.** The Pin Mux configuration for a
-   particular platform is obtained by creating a .pinmux project for the
-   device using the `TI Pin Mux
-   Tools <http://www.ti.com/tool/PINMUXTOOL>`__ available on ti.com. The
-   output of the tool can be plugged into the board library to modify
-   the default configuration. The default baseline Pin Mux project
-   (boardname.pinmux) is included in the board library for reference.
-
--  **Modify IO Instance and Configuration to Match Use Case:** If your
-   custom board uses an IO instance different from the TI-supported
-   board, the instance needs to be modified in the Pin Mux setup as well
-   as in the board_cfg.h file in
-   pdk_xx_Xx_xx_xx/packages/ti/board/src/<customBoardName>/
-
--  **Modify Files Corresponding to External Board Components:** The
-   custom board may have external components (flash devices, Ethernet
-   PHY, etc.) that are different from the components populated on the
-   TI-supported EVM. These components and their support files need to be
-   added to the
-   pdk_xx_Xx_xx_xx/packages/ti/board/src/<customBoardName>/device path
-   and linked as part of the board library build.
-
-The above steps have been explained in detail in **Section 9** of the
-**`Application Development Using Processor SDK RTOS
-Training <http://training.ti.com/application-development-using-processor-sdk-rtos/index.html>`__**.
-The slides talk about the different aspects of porting Processor SDK 3.0
-to your custom platform, including incorporating custom Pin Mux,
-clocking, peripheral instance, etc.
-
-Adding custom board to the PDK directory structure and build setup is
-described in the article
-`Adding_Custom_Board_Library_Target_to_Processor_SDK_RTOS_makefiles <How_to_Guides.html#adding-custom-board-library-target-to-processor-sdk-rtos-makefiles>`__
-
-.. note::
-   TI evaluation platforms for Sitara Processors usually have board
-   information stored in an EEPROM which checks for revision number and
-   board name which is used to configure the board. When creating a custom
-   platform if you don`t intend to use an EEPROM then we recommend removing
-   code corresponding to Board_getIDInfo in your board library
-
-.. rubric:: Do I need to do any post processing on PDK files generated
-   by Pin Mux Utility?
-   :name: do-i-need-to-do-any-post-processing-on-pdk-files-generated-by-pin-mux-utility
-
-The Pin Mux utility is designed to automate the integration of a
-custom-designed SOC pin map into the board library software. For AM335x,
-AM437x, and K2G devices, the PDK files generated by the utility can be
-integrated into the board library without any manual edits to the files.
-For AM57x users, there are system design-level considerations that
-require the user to manually select IO delay modes for specific
-peripherals, which may require manual intervention before integrating
-with the board library.
-
-An example for modifying the Pin Mux in the board library to modify the
-UART instance on AM335x is provided in the wiki article `Processor SDK
-RTOS
-Customization <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Customization:_Modifying_Board_library_to_change_UART_instance_on_AM335x>`__.
-
-**For More Information:** Refer to `Application Development Using
-Processor SDK RTOS
-Training <http://training.ti.com/application-development-using-processor-sdk-rtos/index.html>`__
-and `Application Notes on AM57xx Pin Multiplexing
-Utilities <http://www.ti.com/lit/pdf/sprac44>`__.
-
-.. rubric:: How can I modify PLL settings in board libraries?
-   :name: how-can-i-modify-pll-settings-in-board-libraries
-
-The SOC board library in the PDK configures the SOC PLL and module clock
-settings to the nominal settings required to be used with the TI
-evaluation platform. If you want to use different clock settings due to
-power consideration, or if you are using a variant of the device that
-needs to be clocked differently, you can enter the PLL and clock
-settings in the board library. All of the PLL and module clock settings
-are consolidated in the following files:
-
--  <Board>.c: Contains calls related to all board-level initialization.
-   <Board> refers to the evaluation platform (For example, evmam335x)
--  <EVM>_pll.c: Defines the Board_PLLInit() function that configures the
-   dividers and multipliers for the clock tree.
--  <EVM>_clock.c: Defines clock dividers, scalars, and multipliers for
-   individual board modules initialized using the board library.
-
-.. rubric:: Can you provide an example of modifying a board library to
-   use a different peripheral instance as compared to the EVM design?
-   :name: can-you-provide-an-example-of-modifying-a-board-library-to-use-a-different-peripheral-instance-as-compared-to-the-evm-design
-
-A good example of the steps involved in modifying a peripheral instance
-is provided in the application note "`Processor SDK RTOS Customization:
-Modifying UART
-Instance <http://www.ti.com/lit/pdf/sprac32>`__"
-
-|
-
-Secondary Bootloader
-====================
-
-.. rubric:: What board initialization is required in the application
-   after booting using the Secondary Boot Loader (SBL)?
-   :name: what-board-initialization-is-required-in-the-application-after-booting-using-the-secondary-boot-loader-sbl
-
-SBL calls the board library to set up the PLL clock, DDR, and Pin Mux,
-and to power on target cores and the I/O peripheral from which it will
-boot the application. Excluding those just mentioned, any other
-configuration need to be done from the application code. As long as you
-have added all of the device initialization to the board library, you
-will not need to add any initialization code in the application.
-
-.. note::
-   For AM57xx devices, the AVS and ABB settings required for all core rails
-   is added to the SBL code, as this initialization is required only in a
-   production environment.
-
-
-.. rubric:: Where do I locate flashing and boot utilities in the
-   package?
-   :name: where-do-i-locate-flashing-and-boot-utilities-in-the-package
-
-The documentation for the booting and flashing of images to EVMs using
-Processor SDK RTOS is provided from the wiki article :ref:`Processor SDK RTOS
-Boot Documentation <FC-Boot-label>`
-
-The :ref:`Boot and Flashing Utilities <FC-Boot-label>`
-for all devices is located in the PDK package under the path
-pdk_<device_name>_x_x_x\\packages\\ti\\boot\\sbl\\tools.
-
-The SDK provides secondary bootloader code for all devices, which is
-loaded by the ROM bootloader. The SBL is responsible for device
-initialization, waking up secondary cores, and deployment of the
-application code on different cores on multi-core devices. On single
-core devices, the SBL is used to manage the device initialization, as
-well as loading and running applications on the device.
-
-Depending on the boot design you need to implement, the boot and
-flashing tools that are used for formatting and booting the SBL can also
-be leveraged to format and boot the application image directly. The
-flash-writing utilities for different EVMs can be located under the path
-pdk_<device_name>_x_x_x\\packages\\ti\\boot\\sbl\\tools\\flashWriter.
-
-If the intent is to restore the KeyStone II EVM to factory settings,
-then the `Program EVM Script <How_to_Guides.html#flash-bootable-images-c66x-k2h-k2e-k2l-only>`__
-enables users to program the flash on the EVM using the pre-built
-firmware images provided by TI/board manufacturer.
-
-|
-
-Diagnostics
-===========
-
-.. rubric:: How to I test my EVM functionality? Can I use the same tests
-   on my custom platform?
-   :name: how-to-i-test-my-evm-functionality-can-i-use-the-same-tests-on-my-custom-platform
-
-The Processor SDK RTOS provides unit tests to test interfaces on the EVM
-as part of diagnostics package that can be found in the package in the
-path pdk_<device_namme>_x_x_x\\packages\\ti\\board\\diag. It also provides a
-framework to run each of these tests through a command line serial
-interface. Users can either load the tests using an emulator or they can
-load them over an SD card to test the EVM functionality.
-
-These tests, like all other examples in the SDK, rely on the board
-library to perform the SOC and board initialization. So if you have
-modified the board library to account for the components on your custom
-hardware, then you should be able to re-use the diagnostic tests while
-bringing up your custom hardware. Users will link to the new board
-library and rebuild the diagnostics package to leverage these examples
-on the custom hardware.
-
-|
-
-Filesystem Support
-==================
-
-.. rubric:: What filesystem support if provided by Processor SDK RTOS ?
-   Can I use UBIFS, RAMFS, or FATFS with TI RTOS when using external
-   non-volatile memory devices?
-   :name: what-filesystem-support-if-provided-by-processor-sdk-rtos-can-i-use-ubifs-ramfs-or-fatfs-with-ti-rtos-when-using-external-non-volatile-memory-devices
-
-Processor SDK RTOS only supports use of FATFS filesystem for some
-devices. For availability of support for your devices check the :ref:`Release
-Notes <processor-sdk-rtos-release-notes>`
-There are numerous examples for using FATFS with USB driver and SD/MMC
-driver in the SDK that you can use for reference. The FATFS-specific
-documentation for Processor SDK RTOS is available in the `FATFS wiki
-section of the Processor SDK RTOS <Device_Drivers.html#fatfs>`__.
-
-|
-
-TI RTOS
-=======
-
-Useful Resources
-----------------
-
--  `SYSBIOS
-   FAQ <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__
--  `Processor_SDK_RTOS:_TI_RTOS_Tips_And_Tricks <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS:_TI_RTOS_Tips_And_Tricks>`__
--  `TI RTOS
-   Worskshop <https://training.ti.com/ti-rtos-workshop-series>`__
--  `SYS/BIOS_with_GCC_(CortexA) <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)>`__
-
-|
-.. rubric:: How do I start writing my TI RTOS application code? Is there
-   any documentation that describes the process?
-   :name: how-do-i-start-writing-my-ti-rtos-application-code-is-there-any-documentation-that-describes-the-process
-
-The typical recommendation is to start a TI RTOS project using the
-predefined templates provided as part of CCS installation and then add
-custom configuration on top of it. CCS allows users to create a TI RTOS
-project with Minimum, Typical, and a set of generic examples, as you can
-see from wiki `Processor SDK RTOS TI RTOS Getting Started
-Examples <index_overview.html#processor-sdk-rtos-getting-started-guide>`__.
-
-Other than that, there is an TI RTOS workshop that addresses different
-features and use cases of TI RTOS with CCS: `Introduction to the TI-RTOS
-Kernel
-Workshop <http://processors.wiki.ti.com/index.php/Introduction_to_the_TI-RTOS_Kernel_Workshop>`__
-
-The TI RTOS component also ships with user documentation that provides
-information on configuring TI RTOS through scripts APIs and also using
-the graphical XGCONF tool. Full online API and module documentation is
-available here: `TI RTOS API
-Documentation <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_46_00_23/exports/bios_6_46_00_23/docs/cdoc/index.html>`__
-
-.. rubric:: What interrupt latency, foot print, etc. can I expect while
-   using TI RTOS?
-   :name: what-interrupt-latency-foot-print-etc.-can-i-expect-while-using-ti-rtos
-
-Performance and size benchmarks are available for every released
-SYS/BIOS kernel in the TI RTOS package and are shipped as part of the
-standard product documentation. In addition to the benchmark numbers
-themselves, .pdf files provide a detailed description of how the
-benchmarks were implemented. For example, whether they were implemented
-in internal or external memory..
-
-If you do not have access to a release, you can access the release notes
-(and thereby the benchmarks) online by clicking on the following link
-and going to the download link for the TI RTOS version that is part of
-the SDK.
-
--  `SYS/BIOS
-   Releases <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/index.html>`__
-
-This link enables you to access any TI RTOS products and their
-associated release notes. The release notes may be browsed directly.
-There is no need to download the whole product. You will need to have a
-my.ti login to access this site.
-
-Within the SDK package, TI-RTOS Benchmark Documentation can be found
-under directory path
-*bios_6_xx_xx_xx\\packages\\ti\\sysbios\\benchmarks\\doc-files*
-
-.. rubric:: How do I debug TI-RTOS and driver code?
-   :name: how-do-i-debug-ti-rtos-and-driver-code
-
-In order to single step through code, the driver libraries and the TI
-RTOS libraries should be built with complete symbol definition.
-
-For building a debug-able version of TI RTOS, please refer to the
-following article:
-`Making_a_debug-able_Custom_SYSBIOS_Library <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#1_Making_a_debug-able_Custom_SYS.2FBIOS_Library>`__
-
-Processor SDK RTOS drivers are already built with full symbol
-definition. So you should be able to single step into the drivers in the
-CCS IDE environment. **Note**: You may need to add the source of the
-SYS/BIOS and the drivers in the source search path in CCS.
-
-Advanced debug of TI RTOS applications using system analyzer and ROV
-object viewer is described in the `TI RTOS SYSTEM Anlayzer
-wiki <http://processors.wiki.ti.com/index.php/How_is_SYS/BIOS_related_to_System_Analyzer%3F>`__.
-
-|
-
-.. rubric:: How can I run TI RTOS on secondary ARM cores on multi-core
-   ARM devices
-   :name: how-can-i-run-ti-rtos-on-secondary-arm-cores-on-multi-core-arm-devices
-
-Processor SDK RTOS supports multiple device that have multi-core ARM
-like AM572x and Keystone2 devices. In order to run TI RTOS application
-on the secondary ARM core in non-SMP mode, application developers need
-to add correct coreID to the configuration to their BIOS configuration
-to allow the hardware interrupts to be routed to the secondary core.
-
-For example on AM572x which has 2 A15 cores, to run the TI RTOS example
-on secondary ARM core, application users need to add :
-
-::
-
-    var Core = xdc.useModule('ti.sysbios.family.arm.ducati.Core');
-    Core.id = 1;
-
-|
-
-.. rubric:: Why do I get a "undefined reference to
-   \`ti_sysbios_rts_gnu_ReentSupport_checkIfCorrectLibrary'" error when
-   compiling my application?
-   :name: why-do-i-get-a-undefined-reference-to-ti_sysbios_rts_gnu_reentsupport_checkifcorrectlibrary-error-when-compiling-my-application
-
-You may have encountered this error when building an application for ARM
-using makefile and not using CCS. You will need to link in the proper C
-runtime library from SYS/BIOS. Double check the makefile(s) and make
-sure that you are using libc, libgcc, libm, etc. from the SYS/BIOS
-package and not from your toolchain (GCC Linaro).
-
-For additional information, refer to: `What do I need to do to make the
-C runtime library re-entrant when building SYS/BIOS applications for
-Cortex-A GNU
-targets <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#What_do_I_need_to_do_to_make_the_C_runtime_library_re-entrant_when_building_SYS.2FBIOS_applications_for_Cortex-A_GNU_targets.C2.A0.3F>`__
-
-.. rubric:: Where do I post questions on generic TI RTOS?
-   :name: where-do-i-post-questions-on-generic-ti-rtos
-
-We recommend that all TI RTOS users review the list of TI RTOS
-frequently asked questions on the `TI RTOS
-FAQ <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__ page
-prior to posting the questions on the E2E forum. If the question is not
-specific to the Processor SDK RTOS drivers, but relates to configuration
-of a specific module inside TI RTOS, then please post the questions on
-the `TI RTOS E2E Forum <https://e2e.ti.com/support/embedded/tirtos/>`__.
-
-.. rubric:: When load a RTOS example to DSP2, the code stuck at timer.c
-   before go main(), but the same worked on DSP1?
-   :name: when-load-a-rtos-example-to-dsp2-the-code-stuck-at-timer.c-before-go-main-but-the-same-worked-on-dsp1
-
-By default, BIOS uses GPtimer5 to source the clock ticks in the BIOS
-clock module. The GEL is created with the assumption that the DSP1
-developers will use GPtimer5 and DSP2 users will use GPtimer6 to source
-clock module. This means that DSP2 developers will need to add
-configuration script to change the clock source to GPtimer6. Try to add
-the following in your DSP2.cfg :
-
-::
-
-     var Clock = xdc.useModule('ti.sysbios.knl.Clock');
-     Clock.timerId = 5; /* Change BIOS clock to GPTimer6 */
-
-|
-
-Networking Support
-==================
-
-.. rubric:: Can I use NDK software stack on all devices supported in
-   Processor SDK RTOS?
-   :name: can-i-use-ndk-software-stack-on-all-devices-supported-in-processor-sdk-rtos
-
-The NDK software stack provided by TI typically requires a transport
-layer called Network Interface Management Unit (NIMU) layer to interface
-the underlying platform software elements and device drivers. Please
-check the :ref:`Processor SDK RTOS Release Notes <processor-sdk-rtos-release-notes>`
-for support of the NIMU transport driver to determine if NDK software
-can be utilized on your device.
-
-.. rubric:: Where do I find the documentation for the NDK stack?
-   :name: where-do-i-find-the-documentation-for-the-ndk-stack
-
-All the networking-related documentation for Processor SDK RTOS, along
-with the NDK software stack, is linked from the wiki `NDK Documentation
-and
-References <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_NDK#Additional_Documentation_References>`__.
-
-|
-
-Inter-processor Communication (IPC)
-===================================
-
-.. rubric:: How do I build and run IPC examples?
-   :name: how-do-i-build-and-run-ipc-examples
-
-IPC and corresponding examples are designed to be built from the top
-level `Processor SDK RTOS IPC Make Target <Overview.html#additional-targets>`__.
-Please ensure the `Processor SDK RTOS build <Overview.html#additional-targets>`__
-environments have been set up before running the "make ipc_bios" or
-[make ipc_examples] option.
-
-The documentation to run the IPC examples is provided as part of
-ReadMe.txt in the IPC examples or on a device-specific wiki article like
-`How to Run AM57x IPC
-Examples <How_to_Guides.html#run-ipc-examples-on-am572x>`__.
-
-.. rubric:: Where can I locate IPC FAQ document?
-   :name: where-can-i-locate-ipc-faq-document
-
-For IPC-related questions, please refer to the `IPC FAQ wiki
-article <http://processors.wiki.ti.com/index.php/IPC_3.x_FAQ>`__ that
-consolidates the FAQ across all multi-core TI processors.
-
-.. rubric:: How can I run TI RTOS IPC examples on AM57xx devices?
-   :name: how-can-i-run-ti-rtos-ipc-examples-on-am57xx-devices
-
-The instructions to run the IPC examples on AM57xx are provided in the
-wiki article "`Running IPC Examples on
-AM57xx/DRA7xx <How_to_Guides.html#run-ipc-examples-on-am572x>`__"
-
-|
-
-DSP-Optimized Libraries
-=======================
-
-.. rubric:: Why did I encounter a build issue while rebuilding DSPLIB,
-   IMGLIB, or MATHLIB with C6000 CGT 8.x?
-   :name: why-did-i-encounter-a-build-issue-while-rebuilding-dsplib-imglib-or-mathlib-with-c6000-cgt-8.x
-
-This is a known issue. Please refer to the note provided on the
-`Software Libraries
-wiki <http://processors.wiki.ti.com/index.php/Software_libraries#Library_Object_File_Format>`__
-to fix the issue.
-
-.. rubric:: Why does the performance of the DSP Libraries not match with
-   the performance in the documentation?
-   :name: why-does-the-performance-of-the-dsp-libraries-not-match-with-the-performance-in-the-documentation
-
-The performance documented in the optimized DSP libraries that are part
-of the Processor SDK RTOS has been obtained using a C66x simulator
-interface which only works with a flat memory model. In order to obtain
-performance similar to the documentation, the user is expected to
-perform the SOC-specific optimization. This includes placing the data
-buffers in internal DSP memory, using optimized compiler settings in the
-application code, enabling cache if buffers are in DDR memory, enabling
-EDMA for moving data from external memory to L2, etc.
-
-The CSL libraries for the SOC and TI RTOS provide APIs for cache
-management of instruction memory as well as data memory. There are some
-useful documents that enable benchmarking on the DSP and ARM cores.
-
--  `Introduction to DSP
-   Optimization <http://www.ti.com/lit/pdf/sprabf2>`__
--  `TI portal for Core
-   Benchmarking <http://www.ti.com/lsds/ti/processors/technology/benchmarks/core-benchmarks.page>`__
--  `TI DSP Benchmarking Application
-   Report <http://www.ti.com/lit/pdf/sprac13>`__
-
-|
-
-EDMA Library
-============
-
-.. rubric:: How do I resolve EDMA instance usage conflict?
-   :name: how-do-i-resolve-edma-instance-usage-conflict
-
-There are several RTOS driver example projects using EDMA (e.g., PCIE,
-SPI, UART, and MMCSD). These projects typically can run on A15, DSP, or
-M4 cores. As a driver example, these projects use the first EDMA
-instance (EDMA #0), assuming that no others are using it at the system
-level.
-
-There may be an issue if the EDMA instance #0 is already being used in
-the system. For example, if the A15 core runs Linux and uses the EDMA #0
-already, and a user wants to run a Processor SDK RTOS example on C66x
-with default EDMA #0. To resolve such an issue, please choose an unused
-instance. For example, EDMA #1 in the example.
-
-.. rubric:: CCS 7.1 platform can't be verified warning
-   :name: ccs-7.1-platform-cant-be-verified-warning
-
-.. rubric:: When I use CCS 7.1 for Processor SDK RTOS 4.0 projects, I
-   saw a warning "Platform name 'ti.platforms.xxxxxx' could not be
-   verified. Your project may not build as expected."
-   :name: when-i-use-ccs-7.1-for-processor-sdk-rtos-4.0-projects-i-saw-a-warning-platform-name-ti.platforms.xxxxxx-could-not-be-verified.-your-project-may-not-build-as-expected.
-
-The warning shows in Properties---->General of a CCS project in CCS 7.1.
-The warning is due to a change made in CCS 7.1, whereby the User
-Interface tries to verify the project's target/platform name against a
-list of known names and if it cannot be verified then it shows the
-warning. The warning, in itself, does not necessarily mean that the
-target-name is incorrect. Especially in this case where we are looking
-at a known good project, it is likely showing up because the known
-target-names list it is checking against is incomplete. Hence you can
-treat the warning as harmless and ignore it. This causes some confusion
-we have decided to remove the warning in the next release of CCS.
-
-.. rubric:: Keystone I and II devices SGMII/MDIO/PHY
-   :name: keystone-i-and-ii-devices-sgmiimdiophy
-
-.. rubric:: How to setup SGMII interface to a PHY or to another SGMII
-   port without using a PHY?
-   :name: how-to-setup-sgmii-interface-to-a-phy-or-to-another-sgmii-port-without-using-a-phy
-
-There are 3 SGMII connectivity modes: • SGMII port with PHY attached and
-auto-negotiation enabled - for connecting to an external PHY • SGMII
-master to SGMII device with auto-negotiation enabled - this is for
-connecting two SGMII devices, one has to be set as master and the other
-as device • SGMII port to SGMII port with forced link configuration –
-generally this is used when one of the ports does not support
-auto-negotiation
-
-When a device having an SGMII MAC port is connected to a PHY device, the
-SGMII MAC is the device in this link and the PHY is the master. The link
-is established using auto-negotiation across the SGMII link that is
-initiated by the master with an expected response by the device. If the
-auto-negotiation is not initiated by the link master (PHY), the link
-will remain down. In TI Keystone EVMs, the Processor with an SGMII MAC
-port is connected to a PHY, which provides a copper interface to a
-Gigabit RJ-45 connector. The Processor’s SGMII MAC port is configured as
-a device with auto-negotiation enabled. This is done in the Init_SGMII().
-
-When a SGMII MAC port is connected to another SGMII MAC port and
-auto-negotiation is enabled, one must be configured to emulate a master
-while the other is a device. The master port uses the MR_ADV_ABILITY
-register to determine speed and duplex setting instead of the
-MR_LP_ADV_ABILITY register.
-
-Alternately, when an SGMII MAC port is connected to another SGMII MAC
-port and auto-negotiation is not enabled, or not available, a “forced
-link” can be established. Again, the MR_ADV_ABILITY register determines
-the speed and duplex setting. Please refer to the TI KeyStone
-Architecture Gigabit Ethernet (GbE) Switch Subsystem User Guide, section
-3.3, SGMII_CONTROL, MR_ADV_ABILITY and MR_LP_ADV_ABILITY registers for
-detail. The corresponding CSL code is implemented in
-packages\\ti\\csl\\src\\ip\\sgmii\\Vx\\csl_cpsgmiiAux.h.
-
-.. rubric:: In a TI SGMII to FPGA (PHY port) connection, data corruption
-   is observed on egress direction, what could be the cause?
-   :name: in-a-ti-sgmii-to-fpga-phy-port-connection-data-corruption-is-observed-on-egress-direction-what-could-be-the-cause
-
-First to check if the FPGA side is a PHY port or 1000BASE-X media port.
-There are many similarities but they are not identical. It is important
-to recognize that from an electrical point of view, the SGMII interface
-is very similar to the 1000BASE-X interface. Both use 8B/10B encoding, a
-serial interface and an embedded clock. Systems can operate with SGMII
-connected to a media port but they are not guaranteed to operate as they
-are not consistent with the Ethernet standard.
-
-Also, check Rx equalization. Some FPGA may have different choices of
-robust mode (dynamic feedback equalization, aka DFE) or more basic mode
-(linear equalizer). The DFE allows better compensation of transmission
-channel losses by providing a closer adjustment of filter parameters
-than when using a linear equalizer. However, a DFE cannot remove the
-pre-cursor of a transmitted bit; it only compensates for the post
-cursors. Try to use basic mode to see if it helps.
-
-.. rubric:: How do I program the PHY through MDIO interface? I find that
-   TI Init_MDIO() function is empty?
-   :name: how-do-i-program-the-phy-through-mdio-interface-i-find-that-ti-init_mdio-function-is-empty
-
-For some TI EVMs, Init_MDIO() is empty because that PHY is configured
-using pin strapping and no MDIO control is needed to enable it to
-operate through auto-negotiation in the optimum configuration. Sample
-CSL code to access PHY via MDIO can be found under
-packages\\ti\\csl\\src\\ip\\mdio\\Vx\\csl_mdioAux.h. The MDIO user access
-register is used to communicate with the physical transceiver connected
-to the MDIO bus, not to a register of the Keystone SOC MDIO itself. The
-code must be customized for what you want to get or set within the PHY.
-To do this you must set the correct PHY address and then identify PHY
-register that you want to access. Those registers are defined in the PHY
-datasheet, not TI Keystone documents.
-
-After PHY is programmed, the MDIO controller will continue polling the
-PHY periodically for status. The PHY Alive Status Register (ALIVE) and
-PHY Link Status Register (LINK) can be read to monitor this status of
-the PHY and link (please refer to the TI KeyStone Architecture Gigabit
-Ethernet (GbE) Switch Subsystem User Guide, section 3.4).
-
-DMSC/SYSFW
-==========
-
-Questions and answers found in this section expand on information found in the
-`System Firmware Public Documentation
-<http://software-dl.ti.com/tisci/esd/latest/1_intro/index.html>`__
-
-.. rubric:: How do I configure the AM65x MMU to preemptively restrict write
-   access to memory regions protected by SYSFW controlled firewalls?
-
-Device Management & Security Controller (DMSC) uses device firewalls
-to prevent applications from directly manipulating non-real-time registers.  The
-MMU can optionally be used to mimic the firewall access restrictions enforced by
-DMSC.  Programming the MMU in such a manner allows applications to be compatible
-with firewall configurations whether or not DMSC firewall support is enabled.
-Therefore, it is highly recommended that applications configure the MMU to
-prevent write accesses to these regions as detailed below.
-
-The recommendation to keep MMU configuration as restrictive (or more
-restrictive) than the firewalls always stands as the MMU will give a
-precise exception at the time the offending instruction is executed. The
-firewall will give an imprecise data abort that will happen some time after
-the offending memory access lands.
-
-The following table describes all AM65x MMR regions which must be
-configured for read only using the MMU.
-
-+------------------------+------------+------------+------------+---------------+--------------+
-| IP Block               | MMR Region | Start      | End        | MMU Page      | MMU Page     |
-|                        | Name       | Address    | Address    | Start Address | End Address  |
-+========================+============+============+============+===============+==============+
-| MCU Navigator UDMASS   | cfg        | 0x283C0000 | 0x283C001F | 0x00283C0000  | 0x00283D0000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMAP   | rflow      | 0x28400000 | 0x28401FFF | 0x0028400000  | 0x0028410000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| MCU Navigator Ring     | cfg        | 0x28440000 | 0x2847FFFF | 0x0028440000  | 0x0028450000 |
-| Accelerator            |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| MCU Navigator UDMASS   | gcntcfg    | 0x28480000 | 0x28481FFF | 0x0028480000  | 0x0028490000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMAP   | tchan      | 0x284A0000 | 0x284A3FFF | 0x00284A0000  | 0x00284B0000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMAP   | rchan      | 0x284C0000 | 0x284C3FFF | 0x00284C0000  | 0x00284D0000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| MCU Navigator UDMASS   | imap       | 0x28560000 | 0x2856FFFF | 0x0028560000  | 0x0028570000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| MCU Navigator UDMASS   | l2g        | 0x28570000 | 0x2857007F | 0x0028570000  | 0x0028580000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| MCU Navigator UDMASS   | mcast      | 0x28580000 | 0x28580FFF | 0x0028580000  | 0x0028590000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMAP   | gcfg       | 0x285C0000 | 0x285C00FF | 0x00285C0000  | 0x00285D0000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| MCU Navigator Ring     | gcfg       | 0x285D0000 | 0x285D03FF | 0x00285D0000  | 0x00285E0000 |
-| Accelerator            |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator MODSS   | cfg        | 0x30800000 | 0x3080001F | 0x0030800000  | 0x0030810000 |
-| Interrupt Aggregator 0 |            |            |            |               |              |
-+------------------------+------------+------------+------------+               |              +
-| Main Navigator MODSS   | cfg        | 0x30801000 | 0x3080101F |               |              |
-| Interrupt Aggregator 1 |            |            |            |               |              |
-+------------------------+------------+------------+------------+               |              +
-| Main Navigator UDMASS  | cfg        | 0x30802000 | 0x3080201F |               |              |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator MODSS   | imap       | 0x30900000 | 0x30907FFF | 0x0030900000  | 0x0030910000 |
-| Interrupt Aggregator 0 |            |            |            |               |              |
-+------------------------+------------+------------+------------+               |              +
-| Main Navigator MODSS   | imap       | 0x30908000 | 0x3090FFFF |               |              |
-| Interrupt Aggregator 1 |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMASS  | imap       | 0x30940000 | 0x3097FFFF | 0x0030940000  | 0x0030950000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+                        +            +            +            +---------------+--------------+
-|                        |            |            |            | 0x0030950000  | 0x0030960000 |
-+                        +            +            +            +---------------+--------------+
-|                        |            |            |            | 0x0030960000  | 0x0030970000 |
-+                        +            +            +            +---------------+--------------+
-|                        |            |            |            | 0x0030970000  | 0x0030980000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator         | tchan      | 0x30B00000 | 0x30B0FFFF | 0x0030B00000  | 0x0030B10000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator         | rchan      | 0x30C00000 | 0x30C0FFFF | 0x0030C00000  | 0x0030C10000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator         | rflow      | 0x30D00000 | 0x30D07fff | 0x0030D00000  | 0x0030D10000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMASS  | gcntcfg    | 0x31040000 | 0x31043FFF | 0x0031040000  | 0x0031050000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator Ring    | cfg        | 0x31080000 | 0x310BFFFF | 0x0031080000  | 0x0031090000 |
-| Accelerator            |            |            |            |               |              |
-+                        +            +            +            +---------------+--------------+
-|                        |            |            |            | 0x0031090000  | 0x00310A0000 |
-+                        +            +            +            +---------------+--------------+
-|                        |            |            |            | 0x00310A0000  | 0x00310B0000 |
-+                        +            +            +            +---------------+--------------+
-|                        |            |            |            | 0x00310B0000  | 0x00310C0000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMASS  | l2g        | 0x3110007F | 0x3110007F | 0x0031100000  | 0x0031110000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMASS  | mcast      | 0x31110000 | 0x31113FFF | 0x0031110000  | 0x0031120000 |
-| Interrupt Aggregator   |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator UDMAP   | gcfg       | 0x31150000 | 0x311500FF | 0x0031150000  | 0x0031160000 |
-+------------------------+------------+------------+------------+---------------+--------------+
-| Main Navigator Ring    | gcfg       | 0x31160000 | 0x311603FF | 0x0031160000  | 0x0031170000 |
-| Accelerator            |            |            |            |               |              |
-+------------------------+------------+------------+------------+---------------+--------------+
-
-.. rubric:: What AM65x memory areas are reserved for use by DMSC?
-
-DMSC reserves a portion of the AM65x MSMC memory for the communication path
-between itself and the A53.  Applications must not use the reserved region of
-MSMC or communication with DMSC will be compromised.
-
-The size of the MSMC region used by DMSC is both configurable and discoverable.
-The size of the region can be configured through the DMSC board configuration's
-`msmc_cache_size parameter
-<http://software-dl.ti.com/tisci/esd/latest/3_boardcfg/BOARDCFG.html#design-for-boardcfg-msmc>`__.
-The useable MSMC memory after DMSC reservations can be discovered by sending
-the `TISCI_MSG_QUERY_MSMC message
-<http://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-msmc>`__
-to DMSC.  The message response contains the range of MSMC memory useable by the
-application.
-
-|
-
-SMP Examples
-============
-
-.. rubric:: How do I load SMP enabled example into target through CCS ?
-   :name: how-do-i-load-smp-enabled-example-into-target-through-ccs
-
-Symmetric Multi Processing requires a different approach to load
-the application into target board through CCS. The detailed documentation on loading
-and debugging the SMP enabled example is linked `here
-<http://software-dl.ti.com/ccs/esd/documents/ccs_smp-debug.html>`__.
diff --git a/source/rtos/Foundational_Components.rst b/source/rtos/Foundational_Components.rst
deleted file mode 100644
index a2fe5ee76..000000000
--- a/source/rtos/Foundational_Components.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-########################
-Foundational Components
-########################
-
-.. toctree::
-   :maxdepth: 5
-
-   index_Foundational_Components
-
-
diff --git a/source/rtos/How_to_Guides.rst b/source/rtos/How_to_Guides.rst
deleted file mode 100644
index 95364b343..000000000
--- a/source/rtos/How_to_Guides.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. _index-how-to-guides:
-
-######################
-How to Guides
-######################
-
-.. toctree::
-   :maxdepth: 3
-
-   index_how_to_guides
-
diff --git a/source/rtos/How_to_Guides/Host/Flashing_and_Boot/_Flash_bootable_images.rst b/source/rtos/How_to_Guides/Host/Flashing_and_Boot/_Flash_bootable_images.rst
deleted file mode 100644
index 28bda714e..000000000
--- a/source/rtos/How_to_Guides/Host/Flashing_and_Boot/_Flash_bootable_images.rst
+++ /dev/null
@@ -1,340 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Flashing_Bootable_Images
-
-Overview
-^^^^^^^^
-
-The Processor SDK RTOS for C6657, C6678, K2H, K2E, and K2L EVMs includes
-a script in the directory
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>/bin
-
-named **program_evm.js**. The purpose of this script is to automatically
-flash bootable images onto your EVM.
-
-The following sections will describe how to use this script and the
-default flashable binaries in the Processor SDK RTOS.
-
-Requirements
-^^^^^^^^^^^^
-
--  A Windows or Linux PC
--  Processor SDK RTOS installed on your PC. The version to install must
-   match the SOC you plan to use
--  Code Composer Studio installed on your PC
--  An USB connection to your EVM emulator
-
-.. note::
-   Your board should be set to NO-BOOT mode. Please refer to the boot mode
-   dip switch settings for different boot modes on your EVM Hardware User
-   Guide. See :ref:`this page <RTOS-SDK-Supported-Platforms>` for
-   a link to all supported EVM information.
-
-Directory Structure
-^^^^^^^^^^^^^^^^^^^
-
-The files used are in the Processor SDK RTOS directory. Expanded below
-are the relevant files and directories for flashing the bootable images
-for C667x, but a similar structure is used for C665x.
-
-::
-
-    ├── bin
-    │   ├── configs
-    │   │   └── evm6678l
-    │   │       ├── evm6678l.ccxml
-    │   │       ├── evm6678le.ccxml
-    │   │       ├── evm6678le-linuxhost.ccxml
-    │   │       └── evm6678l-linuxhost.ccxml
-    │   ├── logs
-    │   └── program_evm.js
-    └── prebuilt-images
-        ├── eeprom50.bin
-        ├── eeprom51.bin
-        ├── eepromwriter_evm6678l.out
-        ├── eepromwriter_input50.txt
-        ├── eepromwriter_input51.txt
-        ├── eepromwriter_input.txt
-        ├── nandwriter_evm6678l.out
-        ├── nand_writer_input.txt
-        ├── norwriter_evm6678l.out
-        └── nor_writer_input.txt
-
-Below is the expanded tree for K2H. Similarly, this also applies to K2E
-and K2L EVMs.
-
-::
-
-    ├── bin
-    │   ├── configs
-    │   │   └── evmk2h
-    │   │       ├── evmk2h.ccxml
-    │   │       ├── evmk2h-linuxhost.ccxml
-    │   │       └── program_evm_config
-    │   ├── logs
-    │   └── program_evm.js
-    └── prebuilt-images
-        ├── app
-        ├── config
-        ├── MLO
-        └── spi_flash_writer.out
-
-Default Binaries and Setup
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Processor SDK RTOS provides the basic CCXML files to connect to your
-SOC. There is a separate CCXML file for each SOC, emulator, and host OS
-combination. These CCXML files are located in:
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>/bin/config/<SOC>
-
-Users can choose to use their own CCXML file by setting the environment
-variable, **PROGRAM_EVM_TARGET_CONFIG_FILE**, to point to their CCXML
-file in their terminal or command prompt.
-
-You can create your own CCXML file by opening CCSv6 --> View --> Target
-Configurations, and right-clicking on the Target Configuration pane to
-select New Target Configuration. After selecting your SOC and emulator,
-remember to set the appropriate GEL file in the advance options for Core
-0. The GEL file is used to do basic SOC initialization upon connecting
-to the core.
-
-Processor SDK RTOS also provides the basic binaries needed to perform
-flashing. These are separated into two categories - flashwriters and
-flash images.
-
-Flashwriters
-
--  [C66x] eepromwriter_<SOC>.out - writes content to your EVM EEPROM
-   flash memory
--  [C66x] norwriter_<SOC>.out - writes content to your EVM NOR flash
-   memory
--  [C66x] nandwriter_<SOC>.out - writes content to your EVM NAND flash
-   memory
--  [K2H/E/L] spi_flash_writer.out - writes multiple images to your NOR
-   flash memory
-
-Flash images
-
--  [C66x] eeprom50.bin - eeprom binary for address 0x50. The default for
-   C66x is the POST application.
--  [C66x] eeprom51.bin - eeprom binary for address 0x51. The default for
-   C66x is the Intermediate Boot Loader (IBL).
--  [C66x] nor.bin - nor binary to be used for NOR boot. May not be
-   provided for every EVM or release version.
--  [C66x] nand.bin - nand binary to be used for NAND boot. May not be
-   provided for every EVM or release version.
--  [K2H/K2E/K2L] app - NOR binary to be booted by Secondary Bootloader.
-   The default for Keystone 2 is the POST application
--  [K2H/K2E/K2L] MLO - Secondary Bootloader. The default flash location
-   is in SPI NOR flash memory at offset 0.
-
-Usage
-^^^^^
-
-For Windows users:
-
-::
-
-     > cd [SDK Install Path]\processor_sdk_rtos_<platform>_<version>\bin
-     > set DSS_SCRIPT_DIR=[CCS Install Path]\ccsv6\ccs_base\scripting\bin
-     > %DSS_SCRIPT_DIR%\dss.bat program_evm.js [tmdx|tmds]evm(6678|6657|k2h|k2e|k2l)[l|le|ls][-le|-be]
-
-For Linux users:
-
-::
-
-     > cd [SDK Install Path]/processor_sdk_rtos_<platform>_<version>/bin
-     > export DSS_SCRIPT_DIR=[CCS Install Path]/ccsv6/ccs_base/scripting/bin
-     > $DSS_SCRIPT_DIR/dss.sh program_evm.js [tmdx|tmds]evm(6678|6657|k2h|k2e|k2l)[l|le|ls][-le|-be]
-
-The last argument depends on the SOC that you have, concatenated with
-the options to select emulator and endianness:
-
--  l: EVM uses XDS100 on-board Emulator
--  le: EVM uses 560 Mezzanine Emulator daughter card
--  ls: EVM uses XDS200 Emulator card
--  -le: Little Endian
--  -be: Big Endian
-
-.. note::
-   -  By default, the images provided are little endian.
-   -  Also by default, Keystone 2 EVMs are expected to only use the XDS2xx
-      Emulator. You do not have to supply the emulator in the parameter for
-      K2H/K2E/K2L.
-
-Some examples are:
-
-TMDXEVM6678LE little endian
-
-::
-
-      > $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdxevm6678le-le
-
-TMDSEVM6657LS little endian
-
-::
-
-      > $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdxevm6657ls-le
-
-EVMK2H little endian
-
-::
-
-      > $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdsevmk2h
-
-EVMK2E little endian
-
-::
-
-      > $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdsevmk2e
-
-Sample Output
-^^^^^^^^^^^^^
-
-::
-
-    C:\ti\processor_sdk_rtos_c665x_2_00_01_07\bin>%DSS_SCRIPT_DIR%\dss.bat program_evm.js tmdxevm6657ls-le
-    board: evm6657l
-    endian: Little
-    emulation: XDS200 emulator
-    binaries: ../prebuilt-images/
-    ccxml: C:\ti\processor_sdk_rtos_c665x_2_00_01_07\bin/configs/evm6657l/evm6657ls.ccxml
-    C66xx_0: GEL Output:
-    Connecting Target...
-
-    C66xx_0: GEL Output: DSP core #0
-
-    C66xx_0: GEL Output: C6657L GEL file Ver is 1.006
-
-    C66xx_0: GEL Output: Global Default Setup...
-
-    C66xx_0: GEL Output: Setup Cache...
-
-    C66xx_0: GEL Output: L1P = 32K
-
-    C66xx_0: GEL Output: L1D = 32K
-
-    C66xx_0: GEL Output: L2 = ALL SRAM
-
-    C66xx_0: GEL Output: Setup Cache... Done.
-
-    C66xx_0: GEL Output: Main PLL (PLL1) Setup ...
-
-    C66xx_0: GEL Output: PLL in Bypass ...
-
-    C66xx_0: GEL Output: PLL1 Setup for DSP @ 1000.0 MHz.
-
-    C66xx_0: GEL Output:            SYSCLK2 = 333.3333 MHz, SYSCLK5 = 200.0 MHz.
-
-    C66xx_0: GEL Output:            SYSCLK8 = 15.625 MHz.
-
-    C66xx_0: GEL Output: PLL1 Setup... Done.
-
-    C66xx_0: GEL Output: Power on all PSC modules and DSP domains...
-
-    C66xx_0: GEL Output: Set_PSC_State... Timeout Error #03 pd=12, md=4!
-
-    C66xx_0: GEL Output: Power on all PSC modules and DSP domains... Done.
-
-    C66xx_0: GEL Output: DDR3 PLL (PLL2) Setup ...
-
-    C66xx_0: GEL Output: DDR3 PLL Setup... Done.
-
-    C66xx_0: GEL Output: DDR3 Init begin (1333 auto)
-
-    C66xx_0: GEL Output: XMC Setup ... Done
-
-    C66xx_0: GEL Output: IFRDY bit is SET: DDR3 Interface Ready
-
-    C66xx_0: GEL Output:
-    DDR3 initialization is complete.
-
-    C66xx_0: GEL Output: DDR3 Init done
-
-    C66xx_0: GEL Output: DDR3 memory test... Started
-
-    C66xx_0: GEL Output: DDR3 memory test... Passed
-
-    C66xx_0: GEL Output: PLL and DDR3 Initialization completed(0) ...
-
-    C66xx_0: GEL Output: configSGMIISerdes Setup... Begin
-
-    C66xx_0: GEL Output: SGMII SERDES has been configured.
-
-    C66xx_0: GEL Output: Enabling EDC ...
-
-    C66xx_0: GEL Output: L1P error detection logic is enabled.
-
-    C66xx_0: GEL Output: L2 error detection/correction logic is enabled.
-
-    C66xx_0: GEL Output: MSMC error detection/correction logic is enabled.
-
-    C66xx_0: GEL Output: Enabling EDC ...Done
-
-    C66xx_0: GEL Output: Global Default Setup... Done.
-
-    Start writing eeprom50
-    Writer:../prebuilt-images/eepromwriter_evm6657l.out
-
-    Image:../prebuilt-images/eeprom50.bin
-
-    C66xx_0: GEL Output: Invalidate All Cache...
-
-    C66xx_0: GEL Output: Invalidate All Cache... Done.
-
-    C66xx_0: GEL Output: GEL Reset...
-
-    C66xx_0: GEL Output: GEL Reset... Done.
-
-    C66xx_0: GEL Output: Disable all EDMA3 interrupts and events.
-
-    EEPROM Writer Utility Version 01.00.00.05
-
-    Writing 57432 bytes from DSP memory address 0x0c000000 to EEPROM bus address 0x0050 starting from device address 0x0000
-    ...
-    Reading 57432 bytes from EEPROM bus address 0x0050 to DSP memory address 0x0c010000 starting from device address 0x0000
-    ...
-    Verifying data read ...
-    EEPROM programming completed successfully
-    Start writing eeprom51
-    Writer:../prebuilt-images/eepromwriter_evm6657l.out
-
-    Image:../prebuilt-images/eeprom51.bin
-
-    C66xx_0: GEL Output: Invalidate All Cache...
-
-    C66xx_0: GEL Output: Invalidate All Cache... Done.
-
-    C66xx_0: GEL Output: GEL Reset...
-
-    C66xx_0: GEL Output: GEL Reset... Done.
-
-    C66xx_0: GEL Output: Disable all EDMA3 interrupts and events.
-
-    EEPROM Writer Utility Version 01.00.00.05
-
-    Writing 47888 bytes from DSP memory address 0x0c000000 to EEPROM bus address 0x0051 starting from device address 0x0000
-    ...
-    Reading 47888 bytes from EEPROM bus address 0x0051 to DSP memory address 0x0c010000 starting from device address 0x0000
-    ...
-    Verifying data read ...
-    EEPROM programming completed successfully
-    Writer:../prebuilt-images/nandwriter_evm6657l.out
-
-    NAND:../prebuilt-images/nand.bin
-
-    Required NAND files does not exist in ../prebuilt-images/
-
-    Writer:../prebuilt-images/norwriter_evm6657l.out
-
-    NOR:../prebuilt-images/nor.bin
-
-    Required NOR files does not exist in ../prebuilt-images/
-
-In the above example, nothing was flashed to NAND or NOR since there
-were no nand.bin or nor.bin binaries to flash.
-
diff --git a/source/rtos/How_to_Guides/Host/Porting/_Adding_Custom_Board_Library_Target_to_PSDK_RTOS_makefiles.rst b/source/rtos/How_to_Guides/Host/Porting/_Adding_Custom_Board_Library_Target_to_PSDK_RTOS_makefiles.rst
deleted file mode 100644
index 2825a7199..000000000
--- a/source/rtos/How_to_Guides/Host/Porting/_Adding_Custom_Board_Library_Target_to_PSDK_RTOS_makefiles.rst
+++ /dev/null
@@ -1,277 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Adding_Custom_Board_Library_Target_to_Processor_SDK_RTOS_makefiles
-
-Introduction
-^^^^^^^^^^^^^
-
-The following article describes how a custom Board can be added to the
-Processor SDK RTOS. The scope of this article is to only describe how to
-modify the build files in the PDK to add build steps for your custom
-board library. The article does not describe modification of source
-files to reflect changes to clocking, DDR and pinmux setup for the
-custom board.
-
-The instructions provided in this article uses example of AM572x custom
-board but the instructions apply to all the processors supported in
-Processor SDK RTOS. Note that the instructions on this wiki were created
-using Processor SDK RTOS v3.2 and PDK_AM57xx_1_0_5 and are subject to
-change. Also the wiki was created specifically for the newer board
-variants like evmAM572x, idkAM572x and evmK2G. For AM335x and AM437x
-variant board library has several dependencies on legacy starterware
-package, hence additional steps are required and not covered in the
-wiki.
-
-Instructions to add custom Board to the PDK build
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**Step 1: Creating new directory for custom board library**
-
-In pdk_am57xx_x_x_x/packages/ti/board/src,
-Create new directory myCustomBoard and copy files from existing board
-library package. We recommend that you copy files from the board which
-closely matches your custom board design. In this case, we assume that
-the custom board is based on the design of evmAM572x so we copy over
-the files from that directory into myCustomBoard folder.
-
-**Step 2: Updating names and makefile inside the customBoard package**
-
-In pdk_am57xx_x_x_x/packages/ti/board/src/myCustomBoard, Rename file
-src_files_evmAM572x.mk to src_files_myCustomBoard.mk. This file will
-need a bit of work depending on what elements of board you need for your
-platform. We have left all the files evmAM572x_*.c but you can modify as
-needed.
-
-**Step 3: Adding MACRO based inclusion of updated board_cfg.h
-corresponding to custom Board**
-
-In packages/ti/board/board_cfg.h, add the lines pointing to board_cfg.h
-file in your customBoard package so that updated peripheral instances
-and board specific defines can be picked up
-
-::
-
-    #if defined (myCustomBoard)
-    #include <ti/board/src/myCustomBoard/include/board_cfg.h>
-    #endif
-
-**Step 4: Update top level board package makefile to include build for
-customBoard Library** The makefile is used to include all relevant make
-files for including Low level driver(LLD), source files relevant to
-board and the common board.c file
-
--  In packages/ti/board/build/makefile.mk, add board.c to the
-   customBoard build :
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD),evmAM335x icev2AM335x skAM335x bbbAM335x evmAM437x idkAM437x skAM437x myCustomBoard evmAM572x idkAM571x idkAM572x evmK2H evmK2K evmK2E evmK2L evmK2G iceK2G evmC6678 evmC6657))
-    # Common source files across all platforms and cores
-    SRCS_COMMON += board.c
-    endif
-
--  Add board library source files and LLD files to the customBoard build
-
-In packages/ti/board/build/makefile.mk, change
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD), evmAM572x idkAM571x idkAM572x))
-    include $(PDK_BOARD_COMP_PATH)/src/$(BOARD)/src_files_$(BOARD).mk
-    include $(PDK_BOARD_COMP_PATH)/src/src_files_lld.mk
-    CFLAGS_LOCAL_$(BOARD) += -D$(BOARD)
-    endif
-
-to
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard evmAM572x idkAM571x idkAM572x))
-    include $(PDK_BOARD_COMP_PATH)/src/$(BOARD)/src_files_$(BOARD).mk
-    include $(PDK_BOARD_COMP_PATH)/src/src_files_lld.mk
-    CFLAGS_LOCAL_$(BOARD) += -D$(BOARD)
-    endif
-
-**Step 5: Update Global makerules**
-
-build_config.mk defines the global CFLAGS used to compile different PDK
-components. Add the following line in the BOARD Specific configurations.
-
-::
-
-    CFLAGS_GLOBAL_customAM572x  = -DSOC_AM572x -DevmAM572x
-
-The SOC_AM572x macro ensures that the CSL aplicable to this SOC will be
-included in the build and evmAM572x define will ensure all evmAM572x
-specific includes that apply to the customAM572x are part of the build.
-
-
-**Optional step to update RTSC platform definition** If you have a
-custom RTSC platform definition for your custom board that updates the
-memory and platform configuration using RTSC Tool then you need to
-update the platform.mk file that associates the RTSC platfom with the
-corresponding board library
-
-In packages/ti/buildmakerules/platform.mk, add the following lines:
-
-
-::
-
-     ifeq ($(BOARD),$(filter $(BOARD), evmAM572x))
-       PLATFORM_XDC = "ti.platforms.evmAM572X"
-     endif
-
-::
-
-     ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
-       PLATFORM_XDC = "evmAM572XCustom"
-     endif
-
-.. note::
-   The SYSBIOS platforms follow the convention to consolidate all
-   platform definitions under SYSBIOS_INSTALL_PATH/packages/ti/platforms/\*
-   hence the convention ti.platorms.<platformName> but for custom platform,
-   users are not required to follow this convention.
-
-**Step 6: Update source files corresponding to drivers used in board
-library**. src_files_lld.mk file adds source files corresponding to LLD
-drivers used in the board library. Usually most boards utilitize control
-driver like I2C (for programming the PMIC or reading EEPROM), UART
-drivers (for IO) and boot media drivers like (SPI/QSPI, MMC or NAND). In
-the example below, we assume that the custom Board library has
-dependency on I2C, SPI and UART LLD drivers. Since the LLD drivers will
-be linked to the application along with board library, board library
-only needs <driver>_soc.c corresponding to SOC used on the custom Board.
-
-In packages/ti/board/src/src_files_lld.mk, add the following lines:
-
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
-    SRCDIR +=  $(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x
-
-::
-
-    INCDIR +=  $(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x
-
-::
-
-    # Common source files across all platforms and cores
-    SRCS_COMMON += I2C_soc.c UART_soc.c SPI_soc.c
-    endif
-
-
-.. note::
-   For all LLD drivers linked to the board library you need to include
-   corresponding <drv>_soc.c file. For example if you include GPIO driver
-   for setting board mux then GPIO_soc.c needs to be added to LLD source
-   files.
-
-**Step 7: Add custom Board to BOARDLIST and update CORELIST**
-
-In packages/ti/board/board_component.mk, modify the build to add your
-custom board and specify the cores for which you want to build the board
-library. Example to build board library for only A15 and C66x cores,
-limit the build by specify only a15_0 and C66x in the CORELIST
-
-::
-
-    board_lib_BOARDLIST       = myCustomBoard evmAM335x icev2AM335x skAM335x bbbAM335x evmAM437x idkAM437x skAM437x evmAM572x idkAM571x idkAM572x evmK2H evmK2K evmK2E evmK2L evmK2G iceK2G \
-
-::
-
-    #board_lib_am572x_CORELIST = c66x a15_0 ipu1_0
-    board_lib_am572x_CORELIST = a15_0 c66x
-
-**Step 8: Update .bld files for XDCTOOL based build steps.**
-
-Make corresponding changes in packages/ti/board/config.bld, by adding
-the following lines:
-
-::
-
-    var myCustomBoard = {
-       name: "myCustomBoard",
-       ccOpts: "-DevmAM572x -DSOC_AM572x",
-       targets: [C66LE,A15LE ]
-       lldFiles: [ "$(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x/I2C_soc.c",
-               "$(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x/UART_soc.c",
-               "$(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x/SPI_soc.c"]
-    }
-
-::
-
-    var boards = [ evmAM335x, icev2AM335x, skAM335x, bbbAM335x, evmAM437x, idkAM437x, skAM437x, myCustomBoard, evmAM572x, idkAM571x, idkAM572x, evmK2H, evmK2K, evmK2E, evmK2L, evmK2G, evmC6678, evmC6657 ];
-
-Also, in packages/ti/board/package.bld, I added the following line:
-
-::
-
-    Pkg.otherFiles[Pkg.otherFiles.length++] = "src/myCustomBoard/src_files_myCustomBoard.mk";
-
-
-**Step 9: Setup Top level PDK build files to add the Custom board to
-setup environment.**
-
-Final setup involves updating the top level setup file for PDK package
-to update to setup the build environment to include the custom Board in
-setup. This can be done by commenting out the top line and adding in the
-bottom line in pdksetupenv.bat:
-
-
-::
-
-    @REM if not defined LIMIT_BOARDS set LIMIT_BOARDS=evmAM572x idkAM571x idkAM572x
-    if not defined LIMIT_BOARDS set LIMIT_BOARDS=myCustomBoard
-
-**Alternative:** Invoke the build using command line options to limit
-the build to specific board, specific SOC and specific CORE. For
-example, if you want to build the A15 version of board library for
-AM572x EVM, you can invoke the build using:
-
-::
-
-    gmake board_lib LIMIT_SOCS=am572x LIMIT_BOARDS=customAM572x LIMIT_CORES=a15_0
-
-
-
-**Step 10 : Building the custom board with the updated settings**
-
-To build package change directory to
-<SDK_INSTALL_PATH>/pdk_am57xx_x_x_x/packages, first run pdksetupenv.bat
-
-To make just the board library: gmake board_lib
-
-
-Example custom Board library for reference
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The package provided below provides updated files for building
-customBoard "customAM572x" following all steps described above. Please
-compare the files to the evmAM57xx board library files to follow the
-steps to add your own board library.
-
-`File:Pdk packages ti board
-customAM572x.zip </index.php?title=Special:Upload&wpDestFile=Pdk_packages_ti_board_customAM572x.zip>`__
-
-.. note::
-   Due to software distribution policy on the wiki, we have removed the
-   file linked here. Users can refer to the discussion and zipped package
-   linked from E2E post provided below:
-
--  `E2E post on creation of custom board
-   library <https://e2e.ti.com/support/arm/sitara_arm/f/791/p/555022/2040948#pi316653=2>`__
-
-Additional steps for AM335x/AM437x users
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note::
-   Currently the AM335x and AM437x board libraries re-use the board support
-   that was used in legacy starterware software. AM335x and AM437x users
-   will need to additionally modify build files in starterware to build
-   their custom board library. Additional steps required for AM335x/AM437x
-   will be added to this article soon in this section
-
diff --git a/source/rtos/How_to_Guides/Host/Porting/_PSDK_RTOS_Porting_Guide_for_AM57xx_Speed_Grades.rst b/source/rtos/How_to_Guides/Host/Porting/_PSDK_RTOS_Porting_Guide_for_AM57xx_Speed_Grades.rst
deleted file mode 100644
index fb50d6da5..000000000
--- a/source/rtos/How_to_Guides/Host/Porting/_PSDK_RTOS_Porting_Guide_for_AM57xx_Speed_Grades.rst
+++ /dev/null
@@ -1,303 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Porting_Guide_for_AM571x/AM570x_Speed_Grades
-
-Description
-^^^^^^^^^^^
-
-The AM57x Family of Processors includes a wide range of operating
-performance to meet the needs of a number of broad applications. Among
-these options are a variety of speed grades to meet different
-performance points. These devices have a number of specialized cores to
-provide applications specific computation capabilities. These cores can
-be run at different speeds to fine tune the processor to the needs of
-the application, power budget, thermal characteristics, etc.
-
-The Processor SDK for RTOS is a software development package provided to
-speed development by providing a software reference. This package now
-includes support for then entire AM57x family of processors which can be
-broken down into the AM572x, AM571x, and AM570x sets of devices or
-sub-familes. Most of the devices in this family are supported by the
-Processor SDK for RTOS right out of the box. This support is tested and
-validated on TI designed EVMs. These EVMs use the highest performance
-devices in the family in order to allow users to evaluate the entire
-spectrum of performance.
-
-The AM571X and AM570x supports several lower power speed grades. If one
-of these devices is being used on the custom board, the GEL file and the
-board library needs to be changed to account for this difference. If
-this change is not made, the device could be running out of
-specification. These changes may reach across other cores and clocks on
-the device as well, depending on what speeds they need to operate at.
-This document is not an exhaustive list of all the changes needed for a
-proper board port as it focused on the changes needed to enable
-different speed grades.
-
-Comparison of AM572x, AM571x and AM570x devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**Quick Feature Set comparison between devices in Sitara AM57xx
-family :**
-
-.. Image:: /images/AM572x_AM571X_AM570x_Comparison.png
-
-|
-| **Supported OPP on AM57xx devices:**
-
-.. Image:: /images/AM57xx_OPP.png
-
-Code Composer Studio (CCS) and Emulation support
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-TI Supports following evaluation platform for AM57xx class of devices:
-
--  :ref:`AM572x GP EVM <RTOS-SDK-Supported-Platforms>`
--  :ref:`AM571x IDK <RTOS-SDK-Supported-Platforms>`
--  :ref:`AM572x IDK <RTOS-SDK-Supported-Platforms>`
-
-When developer selects any of the above platforms in Code composer
-Studio, the target configuration automatically brings in the required
-initialization files and GEL files to configure the clocks, target cores,
-external memory.
-
-If you are using a custom platform or AM5708 device that is not
-available on a TI Evaluation platform, you can follow the steps provided
-below to connect to the SOC by reusing the GEL files that are provided
-for TI evaluation platforms. For example, here we demonstrate how you
-can create a target configuration for AM570x and connect to the device
-if your board design is based of one of TI evalauation platforms listed
-below. The assumption here is that the custom board is based off AM571X
-IDK platform
-
-.. note::
-   Support for AM5708 was added to Sitara Chip Support Package 1.3.4
-   in Code composer Studio. If you don`t see the device definition in CCS,
-   then you can update the Sitara Chip Support package by going to
-   `Help->Check
-   Updates <http://ap-fpdsp-swapps.dal.design.ti.com/index.php/File:Check_Updates.png>`__
-
-
-**Step 1: Select the AM570x part number that is populated on your custom
-platform:**
-
-.. Image:: /images/AM5708_EVM_target_configurations.png
-
-**Step 2: Setup the GEL files for the SOC** Go to the Advanced Tab as
-shown in the previous screenshot and update startup GEL file in the A15
-Core as shown in the screenshot below
-
-.. Image:: /images/Advanced_settings_GEL_setup.png
-
-Board Library Changes to Consider for Using Processor SDK RTOS
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Clock and PRCM Updates to consider
-""""""""""""""""""""""""""""""""""
-
-The board library provides setting for OPP_NOM, OPP_OD and OPP_HIGH in
-the PLL settings using 20 MHz input clock that has been used on the
-AM572x GP EVM as well as the AM571x IDK platform. This allows customers
-to setup the MPU to 1.5, 1.176 and 1GHz. For AM570x devices, we support
-the "J" and the "D" variant which support the following max speeds on
-the DPLLs:
-
-.. Image:: /images/AM5706_Speed_Grades.png
-
-When using the "J" speed grade, ensure that the DPLLs in the board set
-the DPLL to OPP_NOM and not for OPP_OD or OPP_HIGH.
-
-To do this, you can invoke the Board_Init from your application using
-either
-
-.. code-block:: c
-
-    Board_initCfg boardCfg;
-    boardCfg = BOARD_INIT_PLL_OPP_NOM;
-    boardCfg |= BOARD_INIT_UNLOCK_MMR |
-           BOARD_INIT_MODULE_CLOCK |
-           BOARD_INIT_PINMUX_CONFIG |
-           BOARD_INIT_DDR |
-           BOARD_INIT_UART_STDIO |
-           BOARD_INIT_WATCHDOG_DISABLE;
-    /* Board Library Init. */
-       Board_init(boardCfg);
-
-.. note::
-   When bootloading direct from flash media, this change may also be
-   required in the SBL code
-
-When using "D" rated parts that run at 500 MHz, in addition to the
-above configuration, you will also need to modify OPP_NOM settings in
-the board library by updating the DPLL setting for MPU and DSP in the
-file <BoardName>_pll.c as shown below:
-
-**Step1 : Update MPU, DSP, IVA and GPU DPLL setting**
-
--  **MPU DPLL Changes:**
-
-.. code-block:: c
-
-      /* Default to OPP_NOM */
-           /* 500MHz at 20MHz sys_clk */
-           mpuPllcParam.mult = 250U;
-           mpuPllcParam.div = 9U;
-           mpuPllcParam.dccEnable = 0U;
-           mpuPllcParam.divM2 = 1U;
-
--  **DSP DPLL Changes:**
-
-.. code-block:: c
-
-           /* 500MHz at 20MHz sys_clk */
-           dspPllcParam.mult = 130U;
-           dspPllcParam.div = 3U;
-           dspPllcParam.divM2 = 1U;
-           dspPllcParam.divM3 = 3U;
-
--  **Remove IVA and GPU PLL settings**
-
-Since IVA and GPU modules are not available on the device, we recommend
-removing the ivaPLL and gpuPLL settings in board.
-
-.. code-block:: c
-
-                  /* Default to OPP_NOM */
-                  /* 388.3MHz at 20MHz sys_clk */
-    -                ivaPllcParam.mult = 233U;
-    -                ivaPllcParam.div = 3U;
-    -                ivaPllcParam.divM2 = 3U;
-
-
-                 /* Default to OPP_NOM */
-                 /* 425MHz at 20MHz sys_clk */
-    -                gpuPllcParam.mult = 170U;
-    -                gpuPllcParam.div = 3U;
-    -                gpuPllcParam.divM2 = 2U;
-
-**Step 2 : Disable clocks configuration and wakeup for IVA in PRCM**
-
--  **Remove IVA wakeup and Module configuration**
-
-The following updates need to be made in the file <BoardName>_clock.c to
-remove IVA wakeup and clock configuration
-
-.. code-block:: c
-
-    -        CSL_FINST(ivaCmReg->CM_IVA_CLKSTCTRL_REG,
-    -        IVA_CM_CORE_CM_IVA_CLKSTCTRL_REG_CLKTRCTRL, SW_WKUP);
-
-
-       /* PRCM Specialized module mode setting functions */
-    -   CSL_FINST(ivaCmReg->CM_IVA_SL2_CLKCTRL_REG,
-    -       IVA_CM_CORE_CM_IVA_SL2_CLKCTRL_REG_MODULEMODE, AUTO);
-    -  while(CSL_IVA_CM_CORE_CM_IVA_SL2_CLKCTRL_REG_IDLEST_DISABLE ==
-    -      CSL_FEXT(ivaCmReg->CM_IVA_SL2_CLKCTRL_REG,
-    -       IVA_CM_CORE_CM_IVA_SL2_CLKCTRL_REG_IDLEST));
-    -   CSL_FINST(ivaCmReg->CM_IVA_IVA_CLKCTRL_REG,
-    -       IVA_CM_CORE_CM_IVA_IVA_CLKCTRL_REG_MODULEMODE, AUTO);
-    -   while(CSL_IVA_CM_CORE_CM_IVA_IVA_CLKCTRL_REG_IDLEST_DISABLE ==
-    -      CSL_FEXT(ivaCmReg->CM_IVA_IVA_CLKCTRL_REG,
-    -       IVA_CM_CORE_CM_IVA_IVA_CLKCTRL_REG_IDLEST));
-
-Configure DDR Interfaces
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-An important one to consider is the speed of the DDR memory. The clock
-for the DDR is selected using the same dplls structure. Some higher
-speed grade parts support a 667 MHz DDR clock, but some of the lower
-speed grade parts only support a 533 MHz DDR3 clock. Make sure to choose
-the appropriate DDR clock for the device on the custom board.
-
-Over in the board/src/<BoardName>/<BoardName_ddr>.c file, make sure that
-the EMIF is being configured correctly for the appropriate speed, and
-that the appropriate number of EMIFs is being selected to match the part
-being used. AM572x part has 2 DDR interfaces running at 533 MHz and the
-AM571x (and AM570x) only have one running at 667 MHz. This code can be
-kept or removed by the board port. As changes are made, the code must
-make sure to configure the new board correctly, with the appropriate
-number of DDR interfaces and speed configuration.
-
-For AM571x and AM570x, make sure to use the code for the AM571x IDK in
-board/src/<BoardName>/<BoardName_ddr>.c to select 1 EMIF:
-
-.. code-block:: c
-
-          /* MA_LISA_MAP_i */
-          hMampuLsm->MAP_0 = 0x80600100U;
-          /* DMM_LISA_MAP_i */
-          hDmmCfg->LISA_MAP[0U] = 0x80600100U;
-
-For AM572x, this is mapped as following
-
-.. code-block:: c
-
-      /* MA_LISA_MAP_i */
-      hMampuLsm->MAP_0 = 0x80740300;
-      hMampuLsm->MAP_1 = 0x80740300;
-      /* DMM_LISA_MAP_i */
-      hDmmCfg->LISA_MAP[0U] = 0x80740300;
-      hDmmCfg->LISA_MAP[1U] = 0x80740300;
-
-.. note::
-   Processor SDK RTOS provides am570x_ddr.c file in the idkAM571x board
-   library for reference for configuring DDR on AM570x parts
-
-Pinmux Changes to Consider
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  For part number where the Display subsystem or SATA is not available,
-   the pins can be configured to any other pin functionality that may be
-   required in the system. If you don`t need to use these pins, we
-   recommend that you leave these pins in default MUXMODE and terminate
-   the pinmux as recommended in the `Schematics
-   Checklist <http://processors.wiki.ti.com/index.php/AM57xx_Schematic_Checklist>`__.
--  There is no pinmux setting for CSI2 module so you can leave the
-   MUXMODE=0 on those pins if there is no instance of the peripheral
-
-.. note::
-   Processor SDK RTOS provides board/src/idkAM571x/include/am570x_pinmux.h
-   file in the idkAM571x board library for reference for configuring pinmux
-   on AM570x based hardware platform
-
-
-Driver SOC Module clock changes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Some control drivers use default Module input clock frequency settings
-in <module>_soc.c file that gets used by the Low level drivers to
-configure the peripheral clocks. The default module input clock
-frequency is set to the OPP_NOM values that are available on the
-superset variant of the device so if you are using lower speed grades.
-Ensure you change the default to match the module clock on the 500 MHz
-settings or you can use the following sequence to update the settings.
-Code below describes how the SPI driver module input clock frequency can
-be modified
-
-.. code-block:: c
-
-       SPI_v1_HWAttrs spi_cfg;
-       /* Get the default SPI init configurations */
-       SPI_socGetInitCfg(TEST_SPI_PORT, &spi_cfg);
-       /* Modify the default SPI configurations if necessary */
-       spi_cfg.inputClkFreq = 24000000;
-       /* Set the default SPI init configurations */
-       SPI_socSetInitCfg(TEST_SPI_PORT, &spi_cfg);
-
-Related Article for Processor SDK Linux developers
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  `Linux_Porting_Guide_for_AM571x/AM570x_Speed_Grades <http://processors.wiki.ti.com/index.php/Linux_Porting_Guide_for_AM571x/AM570x_Speed_Grades>`__
-
-.. rubric:: Useful Utilities
-   :name: useful-utilities
-
--  `Clock Tree Tool <http://www.ti.com/tool/clockTreeTool>`__
--  `Pin Mux tool <http://www.ti.com/tool/PinMuxTool>`__
-
-Support
-^^^^^^^
-
-For any questions related Usage of AM572x, AM571x and AM570x devices,
-please post your question on TI E2E Forums
-
--  `TI E2E Forums for Sitara
-   Processors <https://e2e.ti.com/support/arm/sitara_arm/>`__
-
diff --git a/source/rtos/How_to_Guides/Host/Setup/_Rebuild_drivers_from_PDK_directory.rst b/source/rtos/How_to_Guides/Host/Setup/_Rebuild_drivers_from_PDK_directory.rst
deleted file mode 100644
index f278fdb60..000000000
--- a/source/rtos/How_to_Guides/Host/Setup/_Rebuild_drivers_from_PDK_directory.rst
+++ /dev/null
@@ -1,447 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Rebuilding_The_PDK
-
-Overview
-^^^^^^^^
-
-The instructions below are for building for one platform. If you are
-developing for multiple platforms (e.g., AM437x and AM335x), please
-invoke builds in a serial fashion.
-
-Building PDK using gmake in Windows environment
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The build environment for windows must be setup providing RULES_MAKE
-macro with the location of the top level Rules.make file. Additionally the
-environment PATH variable must be updated with the install location of
-gmake binary. The build environemnt shall also be set running pdksetupenv
-script file provided within the PDK. The build/Rules.make has all the set
-of default configurations. The defaults in the Rules.make assume all
-Processor SDK components have been installed in the SDK_INSTALL_PATH
-location .
-
--  In command prompt navigate to *pdk_[soc]_[version]/packages*
--  Run pdksetupenv.bat
-
-::
-
-    C:\ti\pdk_[soc]_[version]\packages> pdksetupenv.bat
-
--  Alternatively set RULES_MAKE and PATH variable for Windows..
-
-::
-
-    > set RULES_MAKE = C:/ti/pdk_[soc]_[version]/packages/Rules.make
-    > set PATH=%PATH%;C:/ti/xdc_[xdc_version]
-
-.. note::
-   -  The PDK package uses ARM Linaro compiler for the A15/A9/A8 core, TI
-      ARM Compiler for M4/IPU and TI Compiler for C66x core.
-
--  After the build environment has been configured, the entire PDK, or
-   individual components, can be rebuilt through the top-level makefile
-   in pdk_[soc]_[version]/packages
-
-All PDK components can be cleaned and rebuilt with the following
-commands:
-
-::
-
-    C:\ti\pdk_[soc]_[version]\packages>gmake clean
-    C:\ti\pdk_[soc]_[version]\packages>gmake all
-
-Please note that the user can specify parallelism with the make option -j to reduce
-the build time for targets 'all' and 'clean'. For example,
-
-::
-
-    C:\ti\pdk_[soc]_[version]\packages>gmake clean -j4
-    C:\ti\pdk_[soc]_[version]\packages>gmake all -j4
-
-Individual PDK components can be cleaned and rebuilt from within the component's directory
-with the following commands
-
-::
-
-    cd  C:\ti\pdk_[soc]_[version]\packages\ti\<component>
-    C:\ti\pdk_[soc]_[version]\packages\ti\<component>gmake clean
-    C:\ti\pdk_[soc]_[version]\packages\ti\<component>gmake all
-
-    Example:
-
-    cd C:\ti\pdk_[soc]_[version]\packages\ti\drv\i2c
-    C:\ti\pdk_[soc]_[version]\packages\ti\drv\i2c>gmake clean
-    C:\ti\pdk_[soc]_[version]\packages\ti\drv\i2c>gmake all
-
-Please note that parallel make (-j4) is not supported within individual
-PDK components. It is supported only at the top level (C:\\ti\\pdk_[soc]_[version]\\packages)
-for targets 'all' and 'clean'
-
-PDK users can invoke the build for specific core and specific platform
-using the following syntax. This will help save lot of build time on
-heterogeneous platforms with ARM, DSP and IPU cores or on platforms
-where multiple Evaluation platforms are supported.
-
-::
-
-    gmake LIMIT_BOARDS="<BOARD>" LIMIT_SOCS="<SOC>" LIMIT_CORES="<CORE>"
-
--  SOC can be am335x, am437x, am571x, am572x, k2g,k2h,k2e, etc.
--  CORE can be “a15_0”, “c66x”, or “ipu1_0”, for a15, c66, m4
-   respectively.
--  BOARD can be any evaluation hardware platform that your SOC supports.
-
-For Example:
-
-To build only, ARM version of evmAM572x board library
-
-::
-
-    gmake LIMIT_BOARDS="evmAM572x" LIMIT_SOCS="am572x" LIMIT_CORES="a15_0"
-
-To build only, DSP version of evmK2G board library
-
-::
-
-    gmake LIMIT_BOARDS="evmK2G" LIMIT_SOCS="k2g" LIMIT_CORES="dsp_0"
-
-
-Building PDK using make in Linux environment
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The Linux environment shall be setup by exporting RULES_MAKE variable with
-the location of top level Rules.make or by using the pdksetupenv.sh script
-provided within the PDK. The Rules.make has a set of default configurations
-The defaults in the Rules.make script assume all Processor SDK components have
-been installed in the SDK_INSTALL_PATH directory.
-
--  Navigate to *pdk_[soc]_[version]/packages*
--  Run pdksetupenv.sh
-
-::
-
-    ~/ti/pdk_[soc]_[version]/packages$ source pdksetupenv.sh
-
--  Alternatively the RULES_MAKE variable can be exported from the command line.
-
-::
-
-    $ export RULES_MAKE = /home/ti/pdk_[soc]_[version]/packages/Rules.make
-
-.. note::
-   The PDK package uses ARM Linaro compiler for the A15/A9/A8 core, TI ARM
-   Compiler for M4/IPU and TI Compiler for C66x core.
-
--  After the build environment has been configured, the entire PDK, or
-   individual components, can be rebuilt through the top-level makefile
-   in pdk_[soc]_[version]/packages
-
-All PDK components can be cleaned and rebuilt with the following
-commands:
-
-::
-
-    ~/ti/pdk_[soc]_[version]/packages$ make clean
-    ~/ti/pdk_[soc]_[version]/packages$ make all
-
-Please note that the user can specify parallelism with the make option -j to reduce
-the build time for targets 'all' and 'clean'. For example,
-
-::
-
-    ~/ti/pdk_[soc]_[version]/packages$ make clean -j4
-    ~/ti/pdk_[soc]_[version]/packages$ make all -j4
-
-Individual PDK components can be cleaned and rebuilt from within the components' directory as below
-
-::
-
-    cd ~/ti/pdk_[soc]_[version]/packages/ti/drv/<component>
-    ~/ti/pdk_[soc]_[version]/packages/ti/<component>$ make clean
-    ~/ti/pdk_[soc]_[version]/packages/ti/<component>$ make all
-
-    Example:
-    cd ~/ti/pdk_[soc]_[version]/packages/ti/drv/i2c
-    ~/ti/pdk_[soc]_[version]/packages/ti/drv/i2c$ make clean
-    ~/ti/pdk_[soc]_[version]/packages/ti/drv/i2c$ make all
-
-Please note that parallel make (-j) is not supported within individual
-PDK components. It is supported only at the top level (~/ti/pdk_[soc]_[version]/packages)
-for targets 'all' and 'clean'
-
-PDK users can invoke the build for specific core and specific platform
-using the following syntax. This will help save lot of build time on
-heterogeneous platforms with ARM, DSP and IPU cores or on platforms
-where multiple Evaluation platforms are supported.
-
-::
-
-    make LIMIT_BOARDS="<BOARD>" LIMIT_SOCS="<SOC>" LIMIT_CORES="<CORE>"
-
--  LIMIT_SOCS can be am335x, am437x, am571x, am572x, k2g,k2h,k2e, etc.
--  LIMIT_CORES can be “a15_0”, “c66x”, or “ipu1_0”, for a15, c66, m4
-   respectively.
--  LIMIT_BOARDS can be any evaluation hardware platform that your SOC supports.
-
-Please issue "make help" to list the LIMIT_SOCS/LIMIT_CORES/LIMIT_BOARDS supported.
-
-For Example:
-
-To build only, ARM version of evmAM572x board library
-
-::
-
-    make LIMIT_BOARDS="evmAM572x" LIMIT_SOCS="am572x" LIMIT_CORES="a15_0"
-
-To build only, DSP version of evmK2G board library
-
-::
-
-    make LIMIT_BOARDS="evmK2G" LIMIT_SOCS="k2g" LIMIT_CORES="c66x"
-
-
-
-Building PDK components from git repo
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The components PDK can be rebuilt from their git repositories. This is especially useful for development and/or picking up some bug fixes since the previous release.
-Below are the steps on how to set up a development environment with the git repositories
--  Install the most recent version of processor-sdk
--  Replace ~/processor-sdk-installation-dir/pdk_<soc>_<version>  with the PDK git repository https://git.ti.com/cgit/processor-sdk/pdk/
-
-::
-
-   cd ~/ti/<procsdk_install_dir>/
-   git clone  https://git.ti.com/git/processor-sdk/pdk.git
-
-- Clone the PDK components which were present in pdk_<soc>_<version> and  not in the pdk.git. This includes components like csl,sa,pm etc.
-
-::
-
-   cd ~/ti/<procsdk_install_dir>/pdk/packages/ti/
-   git clone https://git.ti.com/git/keystone-rtos/common-csl-ip.git csl
-   cd drv
-   git clone https://git.ti.com/git/keystone-rtos/pm-lld.git pm
-   git clone https://git.ti.com/git/keystone-rtos/sa-lld.git sa
-
-- Set up the development environment with the appropriate PDK_SOC (PDK_SOC is the <soc> field in the pdk_<soc>_<version> directory  which was replaced by pdk.git)
-
-::
-
-   cd ~/ti/<procsdk_install_dir>/pdk/packages/
-   export PDK_SOC=<soc>     //NOTE:PDK_SOC is the <soc> field in the pdk_<soc>_<version> directory  which was replaced by pdk.git
-   source ./pdksetupenv.sh
-
-- Re-build the libraries
-::
-
-   make all -j4
-
-.. note::
-   When updating PDK for picking up bug fixes or for development, please be aware that the supporting components like tools versions might have changed since the previous release.The tools versions used by PDK are specified in pdk/packages/ti/build/pdk_tools_path.mk . Please ensure that those are downloaded in the processor sdk installation directory.
-
-
-PDK Example and Test Project Creation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The PDK contains Windows and Linux scripts used to create example and
-test CCS projects for all PDK sub-components. The following steps detail
-how the scripts are used to create CCS project content.
-
--  Ensure all dependent/prerequisite products are installed and
-   registered with CCS before proceeding with the examples and/or unit
-   test. Starting CCS after installing the Processor SDK products will
-   cause CCS to find and register any new products. Errors will occur
-   during PDK project creation if any dependent products have not been
-   registered with CCS.
--  Navigate to *pdk_[soc]_[version]/packages*
--  [**Optional**] Edit the product versions within the pdkProjectCreate
-   script. The default settings in the pdkProjectCreate script will have
-   the product versions installed with the PDK. The pdkProjectCreate
-   script can be modified to use older or newer product versions based
-   on the user's development environment.
-
-.. note::
-   Project compilation and successful execution cannot be
-   guaranteed for products not installed with the PDK.
-
-.. note::
-
-   -  If the CCS installation is located somewhere other than "C:\\ti",
-      ensure that the pdkProjectCreate script has this location correctly
-      specified by updating the CCS_INSTALL_PATH or set TOOLS_INSTALL_PATH
-      variable
-   -  You may see errors (failed to start server) during the running of the
-      script if an instance of CCS is running, so please ensure that CCS is
-      closed prior to running the pdkProjectCreate script
-   -  When soc is "AM572x" and board is "all", the script uses evmAM572x as
-      the default platform. Please specify board to idkAM572x to create the
-      project for AM572x IDK EVM.
-   -  Run the pdksetupenv script to setup the PDK and SDK path variables
-   -  Run the pdkProjectCreate script. The script takes parameters which
-      allow targeted creation of PDK example and test project content.
-      Below are the command formats for Window's pdkProjectCreate.bat and
-      Linux's pdkProjectCreate.sh:
-
-::
-
-    Windows Usage:
-      pdkProjectCreate.bat [soc] [board] [endian] [module] [project type] [processor] [pdkDir]
-
-     Description:     (first option is default)
-      soc         -   AM335x / AM437x / AM571x / AM572x / K2E / K2G / K2K / K2H / K2L /
-                      C6678 / C6657 / DRA72x / DRA75x / DRA78x / OMAPL137 / OMAPL138
-      board       -   all (use "all" for K2X and C66X SOCs)
-                      -or-
-                      Refer to pdk_<soc>_<version>\packages\ti\board\lib
-                      for valid board inputs for the soc
-      endian      -   little / big
-      module      -   all
-                      -or-
-                      aif2 / bcp / cppi / csl / dfe / emac / fatfs / fm / fftc /
-                      gpio / hyplnk / i2c / icss_emac / iqn2 / mcasp / mcbsp / mmap / mmcsd /
-                      nimu / nimu_icss / nwal / osal / pa / pcie / pktlib / pruss / qm / rm /
-                      sa /serdes-diag / spi / srio / tcp3d / tfw / transportqmss /
-                      transportsrio / tsip / uart / usb / wdtimer / vps / dcan / dss / lcdc
-      project type -  all / example / test
-      processor   -   arm / dsp / m4
-      pdkDir      -   THIS FILE LOCATION / "C:\ti\pdk_<soc>_<version>\packages"
-
-     Example:
-      a) pdkProjectCreate.bat
-                  - Creates all module projects for the AM335x soc for arm little endian
-      b) pdkProjectCreate.bat AM437x
-                  - Creates all module projects for the AM437x soc for arm little endian
-      c) pdkProjectCreate.bat AM437x idkAM437x
-                  - Creates all module projects for idkAM437x device for arm little endian
-      d) pdkProjectCreate.bat AM571x evmAM571x little
-                  - Creates all module projects for evmAM571x device for arm little endian
-      e) pdkProjectCreate.bat AM571x evmAM571x little i2c all dsp
-                  - Creates all i2c module projects for evmAM571x device for dsp little endian
-      f) pdkProjectCreate.bat K2H all little i2c example arm
-                  - Creates i2c module example projects for K2H device for arm little endian
-      g) pdkProjectCreate.bat C6678 all little hyplnk test dsp
-                  - Creates hyplnk module test projects for C6678 device for dsp little endian
-      h) pdkProjectCreate.bat OMAPL138 all little uart all dsp
-                  - Creates all uart module projects for C6748 and OMAPL138 device for dsp little endian
-
-::
-
-    Linux Usage:
-     pdkProjectCreate.sh [soc] [board] [endian] [module] [project type] [processor]
-
-      Description:    (first option is default)
-      soc         -   AM335x / AM437x / AM571x / AM572x / K2E / K2G / K2K / K2H / K2L /
-                      C6678 / C6657 / DRA72x / DRA75x / DRA78x / OMAPL137 / OMAPL138
-      board       -   all (use "all" for K2X and C66X SOCs)
-                      -or-
-                      Refer to pdk_<soc>_<version>\packages\ti\board\lib
-                      for valid board inputs for the soc
-      endian      -   little / big
-      module      -   all
-                      -or-
-                      aif2 / bcp / cppi / csl / dfe / emac / fatfs / fm / fftc /
-                      gpio / hyplnk / i2c / icss_emac / iqn2 / mcasp / mcbsp / mmap / mmcsd /
-                      nimu / nimu_icss / nwal / osal / pa / pcie / pktlib / pruss / qm / rm /
-                      sa / serdes-diag / spi / srio / tcp3d / tfw / transportqmss /
-                      transportsrio / tsip / uart / usb / wdtimer / vps / dcan / dss / lcdc
-      project type -  all / example / test
-      processor   -   arm / dsp / m4
-
-      Example:
-       a) pdkProjectCreate.sh
-                   - Creates all module projects for the AM335x soc for arm little endian
-       b) pdkProjectCreate.sh AM437x
-                   - Creates all module projects for the AM437x soc for arm little endian
-       c) pdkProjectCreate.sh AM437x idkAM437x
-                   - Creates all module projects for idkAM437x device for arm little endian
-       d) pdkProjectCreate.sh AM571x evmAM571x little
-                   - Creates all module projects for evmAM571x device for arm little endian
-       e) pdkProjectCreate.sh AM571x evmAM571x little i2c all dsp
-                   - Creates all i2c module projects for evmAM571x device for dsp little endian
-       f) pdkProjectCreate.sh K2H all little i2c example arm
-                   - Creates i2c module example projects for K2H device for arm little endian
-       g) pdkProjectCreate.sh C6678 all little hyplnk test dsp
-                   - Creates hyplnk module test projects for C6678 device for dsp little endian
-       h) pdkProjectCreate.sh OMAPL138 all little uart all dsp
-                   - Creates all uart module projects for C6748 and OMAPL138 device for dsp little endian
-
-Please note the "module" in above examples may not be showing the full
-list. Please refer to pdkProjectCreate.bat (windows) or
-pdkProjectCreate.sh (Linux) to get the correct list of "modules" being
-supported on a particular device with a particular software release.
-
-The scripts will throw errors for invalid input parameters and for
-invalid configurations. For example, attempting to build DSP projects
-for the am335x device will throw an error since the am335x device does
-not contain a DSP processor.
-
--  The script will search all PDK sub-directories for example and test
-   project files matching the pdkProjectCreate input parameters. CCS
-   projects created during the search will be placed into an centralized
-   CCS project folder. By default this folder is
-   C:\\ti\\pdk_[soc]_[version]\\packages\\MyExampleProjects\\ in Windows and
-   ~/ti/pdk_[soc]_[version]/packages/MyExampleProjects/ in Linux.
-
-
-Steps to run example and/or unit test projects on C66x/A15 Target
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-#. **Import Project**
-
-   Below are the steps for importing project assumes that CCS project is
-   already available.
-
-   #. Select C/C++ Development perspective
-   #. Click on File -> Import
-   #. On the Import Dialog Box select Existing CCS/CCE Eclipse Project
-   #. Click on Next
-   #. This will pop up a new dialog box; ensure that 'Select Root
-      Directory' option is selected
-   #. Click on Browse and select the top level directory where the
-      project is present. For example
-
-      ::
-
-          C:\ti\pdk_[soc]_[version]\packages\MyExampleProjects\
-
-   #. Under the projects section you should see the project. For example
-
-      ::
-
-          GPIO_LedBlink_evmAM572x_c66xExampleProject
-
-   #. Click Finish
-
-#. **Build Project**
-
-   #. To build the project; ensure that the project you want to build,
-      i.e., **GPIO_LedBlink_evmAM572x_c66xExampleProject** is set as the
-      active project. Click on Project -> Build Active Project.Naming
-      convention of Projects created:
-
-      ::
-
-          <Module>_<exampleName>_<BOARD>_<Processor>TestProject or <Module>_<exampleName>_<BOARD>_<Processor>ExampleProject
-
-      ::
-
-          Eg GPIO_LedBlink_evmAM572x_c66xExampleProject, I2C_BasicExample_evmAM572x_armTestProject
-
-#. **Run Project**
-
-   #. Launch the Debugger and switch to the Debug Perspective.
-   #. To execute the project ensure the following is done:
-
-      #. Click on Target -> Reset CPU
-      #. Click on Target -> Load Program
-      #. Select the executable file to be loaded. Example:
-
-        ::
-
-                C:\ti\pdk_[soc]_[version]\packages\MyExampleProjects\GPIO_LedBlink_AM572X_GpEvm_c66xExampleProject\Debug\GPIO_LedBlink_evmAM572x_c66xExampleProject.out
-      4. Click on OK.
-      5. Once the project is loaded; click on Target -> Run to execute
-         it.
-
-|
-
diff --git a/source/rtos/How_to_Guides/Host/Setup/_Setup_CCS_for_EVM_and_PSDK_RTOS.rst b/source/rtos/How_to_Guides/Host/Setup/_Setup_CCS_for_EVM_and_PSDK_RTOS.rst
deleted file mode 100644
index 246b5964a..000000000
--- a/source/rtos/How_to_Guides/Host/Setup/_Setup_CCS_for_EVM_and_PSDK_RTOS.rst
+++ /dev/null
@@ -1,359 +0,0 @@
-Setup CCS for EVM and Processor-SDK RTOS
-------------------------------------------
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Setup_CCS
-
-Overview
-^^^^^^^^^
-
-This page provides information on configuring CCS to work with both the
-EVM and the Processor-SDK for RTOS.
-
-Discovering SDK products
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-CCS and SDK installed in same directory
-""""""""""""""""""""""""""""""""""""""""
-
-After installing the Processor-SDK RTOS, start CCS and it will
-automatically detect the newly installed components (*products*):
-
-.. Image:: /images/CCS-discovered-products.png
-
-CCS and SDK installed in different directories
-"""""""""""""""""""""""""""""""""""""""""""""""
-
-If you chose to install the SDK package in a different folder from where
-CCS is installed (e.g. C:\\TEMP\\RTOS-SDK\\am57x), then you will need to
-add the path to the search path for CCS to locate the new packages. The
-screenshots below demonstrate the process to setup the CCS environment;
-the sequence for a Linux host is the same.
-
-Go to product preference
-'''''''''''''''''''''''''
-
-From CCS, select "Window -> Preferences":
-
-.. Image:: /images/CCS-GP57x-EVM-Custom-Preferences.png
-
-Enter path to SDK
-'''''''''''''''''''
-
-In the Preferences window, select "Code Composer Studio -> RTSC ->
-Products" in the panel on the left. Then, press the "Add" button on the
-panel on the right:
-
-.. Image:: /images/CCS-GP57x-EVM-Custom-Add.png
-
-Verify components
-''''''''''''''''''
-
-Next, verify the newly discovered products. If everything is correct,
-press the "Finish" button on the bottom:
-
-.. Image:: /images/CCS-GP57x-EVM-Custom-Finish.png
-
-Restart CCS
-''''''''''''
-
-When prompted, restart CCS for changes to take effect. You will see
-newly discovered products from the custom path.
-
-.. Image:: /images/CCS-GP57x-EVM-Custom-Confirm.png
-
-Install Latest Emulation Package and Sitara Device Support Package
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-1. In CCS, navigate to Help -> Check for Updates and select "Sitara device support"
-and "TI Emulators" and click Next.
-
- .. image:: /images/TMDX654_EVM_Hardware_Setup/CCS_Check_for_Updates.PNG
-
-2. Click "Next" again, select "I accept the terms of the license agreements"
-and click Finish to begin the installation.
-
- .. image:: /images/TMDX654_EVM_Hardware_Setup/CCS_Updating_Software.png
-
-3. You may be prompted to restart CCS for the updates to take effect. Click "Restart Now" when
-prompted to complete the installation.
-
-
-Create Target Configuration File for EVM
-""""""""""""""""""""""""""""""""""""""""""
-
-In CCS, you need to create a *Target Configuration* for your EVM to be
-able to connect to the target. This configuration defines your:
-
--  Connection to the target (XDS, FET, etc.)
--  Target device (AM437x GP EVM, AM57x GP EVM, etc.)
--  GEL file for hardware initialization. A GEL file is basically a
-   “batch file” that sets up the CCS debug environment including memory
-   map, PLL, clock, etc.
-
-CCS comes with basic configuration that can be used to configure your
-particular setup. In the example below, we provide details for a GP
-AM437x EVM; configuration information for other supported EVMs are also
-provided as needed.
-
-For EVM specific instructions, refer to the **Hardware User's Guide**
-for your :ref:`EVM <RTOS-SDK-Supported-Platforms>`
-
-.. note::
-   **Note for K2G devices:** If using CCS v6.1.2 and Keystone2 device
-   support v1.1.7, 66AK2G02 would not show up in the list of devices when
-   creating the target configuration. This is due to an incompatibility in
-   the XML parser in CCS v6.1.2 with the K2G device xml. In order to
-   work-around this issue, make the change in 66AK2G02.xml as illustrated
-   below in order to have 66AK2G02 display in the device list. This problem
-   does not exist in CCS v6.1.3 onwards as the XML parser has been updated.
-
-   ::
-
-	C:\ti\ccsv6\ccs_base\common\targetdb\devices\66AK2G02.xml
-
-	Line #1
-
-	<?xml version="1.1" encoding="UTF-8" standalone="no"?>
-	to
-	<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-
-Open new target configuration file
-'''''''''''''''''''''''''''''''''''
-
-From CCS, select "File -> New -> Target Configuration File":
-
-.. Image:: /images/CCS-GP437x-EVM-New-Target.png
-
-Select target configuration options
-''''''''''''''''''''''''''''''''''''
-
-The AM437x GP EVM supports embedded XDS100V2 USB Emulation through the
-MicroUSB AB connector. Select
-
--  **Connection**: Texas Instruments XDS100v2 USB Debug Probe
--  **Board or Device**: EVMAM437X
-
-.. Image:: /images/CCS-GP437x-EVM-Configure-Target.png
-
-**Useful Tip**
-
-If you enter the starting numbers of your device in the **Board or
-Device** field, the list will show the relevant subset.
-
-Here is a table showing configuration information for all supported
-EVMs in the Processor-SDK RTOS:
-
-+-----------------------+-----------------------+-----------------------+
-| EVM                   | Connection            | Board                 |
-+=======================+=======================+=======================+
-| AM65x EVM             | Texas Instruments     | GPEVM_AM65x           |
-|                       | XDS110 USB Debug      |                       |
-|                       | Probe                 |                       |
-|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-| AM65x IDK             | Texas Instruments     | IDK_AM65x             |
-|                       | XDS110 USB Debug      |                       |
-|                       | Probe                 |                       |
-|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-| GP335x                | External Emulator     | EVMAM3358             |
-|                       | Supplied by User. EVM |                       |
-|                       | includes a TI 20 pin  |                       |
-|                       | JTAG connector.       |                       |
-+-----------------------+-----------------------+-----------------------+
-| ICE335x               | Texas Instruments     | ICE_AM3359            |
-|                       | XDS100v2 USB Debug    |                       |
-|                       | Probe                 |                       |
-+-----------------------+-----------------------+-----------------------+
-| SK335x                | Texas Instruments     | SK_AM3358             |
-|                       | XDS100v2 USB Debug    |                       |
-|                       | Probe                 |                       |
-+-----------------------+-----------------------+-----------------------+
-| BBB                   | External Emulator     | BeagleBone_Black      |
-|                       | Supplied by User. EVM |                       |
-|                       | includes a TI 20 pin  |                       |
-|                       | JTAG connector.       |                       |
-+-----------------------+-----------------------+-----------------------+
-| GP437x                | Texas Instruments     | EVMAM437X             |
-|                       | XDS100v2 USB Debug    |                       |
-|                       | Probe                 |                       |
-+-----------------------+-----------------------+-----------------------+
-| IDK437x               | Texas Instruments     | IDK_AM437X            |
-|                       | XDS100v2 USB Debug    |                       |
-|                       | Probe                 |                       |
-+-----------------------+-----------------------+-----------------------+
-| GP572x                | External Emulator     | GPEVM_AM572X          |
-|                       | Supplied by User. EVM |                       |
-|                       | includes a TI 20 pin  |                       |
-|                       | JTAG connector.       |                       |
-+-----------------------+-----------------------+-----------------------+
-| X15                   | External Emulator     | GPEVM_AM572X          |
-|                       | Supplied by User. EVM |                       |
-|                       | includes a TI 20 pin  |                       |
-|                       | JTAG connector.       |                       |
-+-----------------------+-----------------------+-----------------------+
-| IDK572x/IDK574x       | Texas Instruments     | IDK_AM572X/IDK_AM574X |
-|                       | XDS100V2 USB Debug    |                       |
-|                       | Probe                 |                       |
-|                       | External Emulator     |                       |
-|                       | Supplied by User. EVM |                       |
-|                       | includes a 60-pin     |                       |
-|                       | MIPI JTAG connector   |                       |
-+-----------------------+-----------------------+-----------------------+
-| C665x EVM             | Texas Instruments     | TMS320C6657           |
-|                       | XDS2xx USB Onboard    |                       |
-|                       | Debug Probe           |                       |
-+-----------------------+-----------------------+-----------------------+
-| C667x EVM             | L w/ XDC100: Texas    | TMS320C6678           |
-|                       | Instruments XDS100v1  |                       |
-|                       | USB Emulator          |                       |
-|                       | LE/LXE with XDS560:   |                       |
-|                       | Blackhawk             |                       |
-|                       | XDS560v2-USB          |                       |
-|                       | Mezzanine Emulator    |                       |
-+-----------------------+-----------------------+-----------------------+
-| K2E EVM               | Texas Instruments     | 66AK2E05              |
-|                       | XDS2xx USB Onboard    |                       |
-|                       | Debug Probe           |                       |
-+-----------------------+-----------------------+-----------------------+
-| K2H EVM               | Texas Instruments     | 66AK2H12              |
-|                       | XDS2xx USB Onboard    |                       |
-|                       | Debug Probe           |                       |
-+-----------------------+-----------------------+-----------------------+
-| K2L EVM               | Texas Instruments     | TCI6630K2L            |
-|                       | XDS2xx USB Onboard    |                       |
-|                       | Debug Probe           |                       |
-+-----------------------+-----------------------+-----------------------+
-| K2G GP EVM            | Texas Instruments     | 66AK2G02              |
-|                       | XDS2xx USB Onboard    |                       |
-|                       | Debug Probe           |                       |
-+-----------------------+-----------------------+-----------------------+
-| OMAPL137 EVM          | Spectrum Digital      | OMAPL137SK            |
-|                       | XDS510USB Emulator    |                       |
-+-----------------------+-----------------------+-----------------------+
-| OMAPL138 LCDK         | External Emulator     | OMAPL138LCDK          |
-|                       | Supplied by User. EVM |                       |
-|                       | includes a TI 14 pin  |                       |
-|                       | JTAG connector.       |                       |
-+-----------------------+-----------------------+-----------------------+
-
-|
-Save target configuration
-''''''''''''''''''''''''''
-
-Next, save the target configuration by pressing the **Save** button:
-
-.. Image:: /images/CCS-GP437x-EVM-Save-Target.png
-
-Test target configuration
-''''''''''''''''''''''''''
-
-Next, test the target configuration by pressing the **Test Connection**
-button. This will confirm that you have successfully created an emulator
-connection with your board.
-
-.. Image:: /images/AM4-GP-test-connection.png
-
-View target configurations
-'''''''''''''''''''''''''''
-
-From CCS, select "View -> Target Configurations":
-
-.. Image:: /images/CCS-GP437x-EVM-View-Target.png
-
-Launch target configuration
-''''''''''''''''''''''''''''
-
-Open "User Defined" list and right click on the target configuration
-file that was just saved and select "Launch Selected Configuration":
-
-.. Image:: /images/CCS-GP437x-EVM-Launch-Target.png
-
-Connect target
-'''''''''''''''
-
-After launch, you can connect to a core. For GP AM437x EVM, select
-**Cortex A9** and select "Connect Target":
-
-.. Image:: /images/CCS-GP437x-EVM-Connnect-Target.png
-
-Success!
-'''''''''
-
-After connecting to target, check the console for status. Typically, the
-end of the configuration will indicate success or failure. For GP AM437x
-EVM, you will see the message "AM437x GP EVM Initialization is Done":
-
-.. Image:: /images/CCS-GP437x-EVM-Run-Target.png
-
-Additional Notes for AM57x
-"""""""""""""""""""""""""""
-
-Connect to AM57x Target Cores
-'''''''''''''''''''''''''''''
-
-After connecting to the boot master core -- typically the ARM core --
-you may need to connect to a target core in order to run code. Depending
-on your SOC, the target core can be
-
--  DSP C66x
--  ARM M4
--  PRUSS
--  IVAHD
-
-Typically the target cores will wait in reset state until the master core
-wakes up the target core to run code. To connect to the target core on
-AM57x, go to **Scripts** menu in CCS Debug View and under **AM572x
-MULTICORE Initialization** enable the corresponding sub system clock.
-For example, enable ``DSP11SSClkEnable_API`` for the first DSP core.
-After running the clock enable option, you can connect to the core.
-
-.. Image:: /images/Multicore-Enable.jpg
-
-Timer Suspend Control Options for DSP
-'''''''''''''''''''''''''''''''''''''''
-
-On AM57xx devices, all the timers on the chip have their suspend control
-signal routed to the A15 core. Which means that if any of the target
-cores are using these timers, the timers will continue to run even when
-the target core has been paused. The timer will only pause when the A15
-core is halted.
-
-This is confusing while debugging code on target cores if you are relying
-on timer for logging, inserting delays or if the timer keeps firing
-interrupts even when the core is halted. One such scenario occurs with
-*GPtimer5* when DSP developers are using SYS/BIOS. The OS uses
-*GPtimer5* on the DSP and forces a frequency check to confirm the timer
-configuration, however the OS can't gain access to the timer due to the
-hook up of the suspend control signals.
-
-Due to this issue the SYS/BIOS developers will need to configure an
-additional CCS configuration check to connect the GPTimer suspend
-control signal to the DSP as shown in the image below:
-
-.. Image:: /images/GPtimer5_DSPConnect.png
-
-Troubleshooting
-""""""""""""""""
-
-If you face any problems, first check these basic items:
-
--  **Power cycle your target.**
--  **Check the USB cable.** One simple way to do this is to connect
-   another device to the USB and ensure the cable works.
--  **Check host driver.** Even with CCS turned off, your host should
-   list the TI XDS as a USB device. If this does not work, try a
-   different USB port.
--  **Latest emulation package.** Ensure that you have the latest
-   emulation files as specified in the `Getting Started Guide <index_overview.html#emulator-support>`__.
-
-If this does not resolve your problem, see these additional resources:
-
--  `Troubleshoot
-   CCS <http://processors.wiki.ti.com/index.php/Troubleshooting_CCSv6>`__
--  `Troubleshoot
-   XDS100 <http://processors.wiki.ti.com/index.php/XDS100#Troubleshooting>`__
--  `Troubleshoot
-   XDS200 <http://processors.wiki.ti.com/index.php/XDS200#Troubleshooting>`__
--  `Troubleshoot
-   XDS560 <http://processors.wiki.ti.com/index.php/XDS560#Frequently_Asked_Questions>`__
-
diff --git a/source/rtos/How_to_Guides/Host/Setup/_TI_RTOS_Tips_and_Tricks.rst b/source/rtos/How_to_Guides/Host/Setup/_TI_RTOS_Tips_and_Tricks.rst
deleted file mode 100644
index f177a2ea6..000000000
--- a/source/rtos/How_to_Guides/Host/Setup/_TI_RTOS_Tips_and_Tricks.rst
+++ /dev/null
@@ -1,578 +0,0 @@
-TI RTOS Tips & Tricks
-----------------------------
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS:_TI_RTOS_Tips_And_Tricks
-
-Description
-^^^^^^^^^^^
-
-The intent of this article is to address common issues that TI RTOS users may run into while configuring SYSBIOS, XDCTools or working with RTSC packages in general on DSP and ARM devices. This is meant to provide insight into build and configuration issue nd must be used as an addendum document by Processor  SDK USer to the `SYSBIOS FAQs <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__ and `XDCtools/RTSC documentation <http://rtsc.eclipse.org/docs-tip/XDCtools_User's_Guide>`__ and `TI RTOS Training <https://training.ti.com/ti-rtos-workshop-series>`__
-
-RTSC Diagnostics: Understanding XDC build errors
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Some of the commonly observed XDC errors have been shown below. We try to explain how to understand and take corrective action.
-
-
-xdc.tools.configuro:  can't locate the package 'Package Name' along the path: ...
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-This indicates that one of the packages that you linked in your BIOS configuration, can`t be located under XDCPATH. The XDC tools uses XDC paths like library search path, so if you run into this issue check that all the component packages have been added to XDCPATH and there is no typo or non-existent paths that you have added to this variable. TI RTSC packages usually have the name ti.<package name>. The packages are named to also sometimes helps locate the package inside the component. For example '''ti.platforms.evmAM335x''' is located under BIOS_INSTALL_PATH/packages/'''ti/platforms/evmAM335x'''
-
-For example if you are using packages from PDK (SOC driver packages)and BIOS (TI RTOS kernel), IPC (Interprocessor Communication) and NDK (Network development kit) then your XDCPATH needs to have following:
-
-* BIOS_INSTALL_PATH/packages
-
-* PDK_INSTALL_PATH/packages
-
-* IPC_INSTALL_PATH/packages
-
-* NDK_INSTALL_PATH/packages
-
-xdc.cfg.SourceDir : Build of generated source libraries failed: exit status = 2:
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-A couple of different reasons could trigger this type of error
-
-* Make sure there are no whitespaces or non-ASCII characters in any paths referenced by the build tools. In other words, make sure all software packages are installed in paths without spaces, and workspace and project names also do not have spaces or non-ASCII characters. We use gmake to build makefiles, and gmake doesn't deal well with spaces in directory and file names.
-
-* Take a close look at the CCS build console and ensure that the sh.exe used for the build is the one from the CCS directory. Also check your system PATH variable and see if there is another sh.exe (or gmake.exe) in your system PATH earlier than the one from the CCS installation. If there is one, then that will be used for the build and could cause build errors such as this. Some toolchains that are known to include sh.exe and could cause a conflict are Cygwin, WinAVR, Yagarto.  In this case, remove those conflicting tools from the system PATH or modify the PATH so that the sh.exe and gmake.exe from CCS are seen first.
-
-* Another source of problems related to sh.exe runnig Windows 10 may be Windows Defender. In "Windows Defender Security Centre", "App and browser control", "Exploit protection settings" one can add exceptions under "Program settings". Adding a rule for "sh.exe" to disable/override "Force randomisation for images (Mandatory ASLR)", "Randomise memory allocations (Bottom-up ASLR)",  "Validate stack integrity (StackPivot)".
-
-
-
-xdc.tools.configuro: missing input config script
-"""""""""""""""""""""""""""""""""""""""""""""""""
-
-The XDCtools build command should normally have the configuration script (.cfg file) passed at the end of the command. If the .cfg is not getting passed correctly, then this message will appear in the CCS build console. This error will then result in other compiler errors further down in the build.
-
-You can confirm if the root cause is the .cfg file not getting passed correctly by looking at the subdir_rules.mk file in the directory Debug (or Release) in your project. The command line that runs configuro usually looks like this: <br>
-
-.. code:: console
-
-    "C:/ti/xdctools_3_xx_xx_xx/xs" --xdcpath="..." xdc.tools.configuro -o configPkg -t ti.targets.elf.C674 -p ti.platforms.evm6747
-    -r release -c "C:/ti/ccsv5/tools/compiler/c6000_x.x.x" --compileOptions "-g --optimize_with_debug" "$<"
-
-Schema files not found
-""""""""""""""""""""""""
-
-Usually after creating a RTSC package, developers are supposed to run xdc release to generate the package that contains the .sch files but if you accidentally delete the package or the developers requires xdc release to be run in user environment, you can run into this issue. This issue can be resolved by adding XDCtools to your environment PATH variable and running the command xdc release
-
-.. code:: console
-
-    set PATH=$PATH;<XDC_INSTALL_PATH>
-    xdc release
-
-Detailed list of '''XDC Error codes''' and Troubleshoot can be found here:
-
-* `XDCtools Error Codes <http://rtsc.eclipse.org/docs-tip/XDCtools_Error_Codes>`__
-* `Trouble Shooting <http://rtsc.eclipse.org/docs-tip/Trouble_Shooting>`__
-
-
-TI RTOS Platform configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Where does TI RTOS application get the Platform definition and memory sections on the SOC
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-When creating a TI RTOS project, the user is required to specify the Platform and target core as part of their RTSC setup as shown below. This shows an example that is created for evmAM335x platform.
-
-.. Image:: /images/Platfrom_configuration.png
-    :scale: 50 %
-
-Selection of the platform essentially tell the build tools that the platform defintion should be picked up from the platform for evmAM335x from the directory path bios_x_xx_xx_xx\packages\ti\platforms\evmAM3359. If you open the Platform.xdc file under the folder path, you can see the default settings provided for this platform. This file combines the baseline AM335x SOC definition under bios_x_xx_xx_xx\packages\ti\catalog\arm\cortexa with the board specific setting like clockrate, DDR memory range.
-
-How to create custom platform like DDRless platforms to use with TI RTOS projects
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-At some point in the application development process, most customers build their own boards, choosing a TI device and adding custom external memory.
-You will also need to create your own platform if any of the following items are true:
-* You want to customize cache sizes.
-* You want to manually override the default section placement.
-* You want application to run from on chip device memory.
-
-For such custom boards you will need to create a platform using the platform wizard. The platform wizard is a GUI tool that allows you to easily create a custom platform. Creating a custom platform gives you a lot of flexibility in terms of defining the memory map and selecting default memory segments for section placement. This has been described in detail in following User guides and training links:
-
-* `Section 7.2.2 in the TI RTOS User guide <http://www.ti.com/lit/ug/spruex3q/spruex3q.pdf>`__
-* `Section 10.9 of  Application development with Processor SDK RTOS <http://software-dl.ti.com/public/hpmp/software/app_dev_procsdk_rtos/index.html>`__
-
-How to place code and data sections in different memory location than set by default TI RTOS platform configuration
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-User can place specific code and data sections in desired location by using the following syntax in the configuration (.cfg)
-
-.. code:: txt
-
-    Program.sectMap[".data"] = new Program.SectionSpec();
-    /* Set the load address for .data section */
-    Program.sectMap[".data"].loadAddress = 0x82000000;
-    /* Set the run address for .data section */
-    Program.sectMap[".data"].runAddress = 0x82010000;
-
-Generic TI RTOS questions
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-What is relationship between TI RTOS and XDCtools and RTSC
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-`SYSBIOS <http://processors.wiki.ti.com/index.php?title=Category:SYSBIOS>`__ uses underlying technology provided by Real Time Software Components (RTSC).
-* RTSC is an open-source specification within the Eclipse.org ecosystem for providing reusable software components (called "packages") for use in embedded systems.
-* XDCtools is the actual product that contains all the tools necessary for you to use the SYS/BIOS components and configure your application. XDCtools is installed as part of Code Composer Studio (CCS). XDCtools is a separate software component provided by Texas Instruments that provides the underlying
-tooling needed for configuring and building SYS/BIOS, NDK, and UIA.
-
-RTSC and XDCtools are important to SYS/BIOS users because:
-
-* `SYS/BIOS_as_a_set_of_RTSC_packages <http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_2_40_00_32/docs/tirtos/sysbios/docs/cdoc/ti/sysbios/package.html>`__ containing the modules that make up the RTOS.
-
-* `XDCtools provides configuration tools <http://rtsc.eclipse.org/docs-tip/XDCtools_User's_Guide>`__ you use to create and build a static configuration as part of your application. This \*.cfg configuration file specifies:
-
-	* Which modules from XDCtools, SYS/BIOS, and other components to include in the run-time image.
-	* What static instances of RTOS objects to create. For example, these include tasks and semaphores.
-	* Settings for parameter values for modules and objects.
-
-* `XDCtools provides critical APIs <http://rtsc.eclipse.org/docs-tip/Overview_of_xdc.runtime#Using_This_Package>`__ that are used by SYS/BIOS and other related software components. These include memory allocation, logging, and system control.
-
-The `RTSC-pedia web site <http://rtsc.eclipse.org/docs-tip/Main_Page>`__ describes RTSC and XDCtools in more detail. In particular, it provides information for developers planning to create RTSC packages. It is also useful if you plan to edit configuration scripts with a text editor rather than using the XGCONF graphical editor provided withing CCS.
-
-
-Can you use any SYSBIOS version with any version of XDCTools when creating create or migrating to TI RTOS based application development environment
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-This is a frequent issue for new user of TI RTOS. SYSBIOS releases are usually validated with a specific version of XDCTools that is described in the Release notes. It is generally not recommended to mix and match SYSBIOS versions with older or newer than the versions described as you may run into incompatibility issues. TI simplifies this build environments by packaging the TI RTOS package with XDCtools or by providing SDKs with the compatible versions of SYSBIOS kernel and XDCtools.
-
-For customers using TI DSP and ARM Processors, it is recommended to use Processor SDK RTOS for TI RTOS development and to setup the CCS environment such its Preferences are set to use the versions included in the SDK. This process has been described:
-`Processor_SDK_RTOS_Setup_CCS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__
-
-Using SYSBIOS with GNU GCC (for ARM devices only)
-""""""""""""""""""""""""""""""""""""""""""""""""""
-The key care about of using SYSBIOS kernel on ARM based devices with GNU GCC compiler have been described in the article `SYS/BIOS_with_GCC_(CortexA) <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)>`__
-
-This wiki answers important questions about using SYSBIOS kernel with GNU GCC compiler like:
-* `Changing entry point to an application <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#How_do_I_change_the_address_where_the_entry_point_function_.28_c_int00.29_gets_placed_.3F>`__
-
-* `Recommended compiler and linker settings <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#Configure_SYS.2FBIOS>`__
-
-* `Getting System_printf/printf (adding Semihosting support) <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#Why_is_System_printf.28.29.2Fprintf.28.29_not_working_.3F>`__
-
-* `Creating make based TI RTOS application build using GNU GCC compiler and XDCtools <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#Build_Application_with_Configuration>`__
-
-* `Configuring ARM MMU and cache settings <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#How_do_I_add_a_4KB_granularity_MMU_pages_on_Cortex-A8.2C_Cortex-A9_and_Cortex-A15_devices_.3F>`__
-
-How do I port existing application developed on SYSBIOS application to SMP/BIOS
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-SYSBIOS supports SMP mode of operation on multi-core ARM and few dual core M3/M4 (IPU) subsytem present in Keystone and Sitara processors.
-
-**Training Slides**: `SMP SYSBIOS Overview presentation <http://processors.wiki.ti.com/index.php/File:Public_SmpBiosSlides.pdf>`__.
-
-To Porting existing SYS/BIOS applications to SMP/BIOS, you can use the follow steps described below:
-* Merge existing separate applications into a single application.
-* Merge separate platform memory definitions as necessary.
-* Add this to your existing application’s config script:
-
-.. code:: txt
-
-    BIOS.smpEnabled = true;
-
-* Use these SMP-aware clone modules in place of their xdc.runtime equivalents for SysMin, SysStd, LoggerBuf (in ti.sybios.smp package)
-
-.. note::
-    The existing Load module has been tweaked to provide minimal support for SMP.
-
-* For initial sanity testing, force all tasks to run on core 0:
-
-.. code:: txt
-
-    Task.defaultAffinity = 0;
-
-* Once basic functionality of the merged applications has been demonstrated, either remove Task.defaultAffinity setting or replace it with
-
-.. code:: txt
-
-    Task.defaultAffinity = Task.AFFINITY_NONE;
-
-The above statement will guide RTOS kernel to deploy tasks based on availability in the cluster of compute cores processing in SMP mode.
-
-Are there any Graphical tools to configure SYSBIOS configuration
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The easiest way for new users to add/configure new modules in the TI RTOS BIOS configuration is to use `XGCONF based graphical tool <http://rtsc.eclipse.org/docs-tip/RTSC%2BCCStudio_v4_QuickStart>`__
-
-
-Thread Types
-^^^^^^^^^^^^
-
-What is the difference between SWIs and Tasks
-"""""""""""""""""""""""""""""""""""""""""""""""
-
-* A Swi is a non-blocking thread that runs to completion and can only be pre-empted by a higher priority Swi or a Hwi (interrupt). Swi's can pre-empt a Task thread when posted and run on the ISR (system) stack (i.e. they do not have their own stack).
-
-* A Task thread on the other hand is a blocking thread and can be pre-empted by a higher priority Task or by Swi/Hwi. A task usually has a while loop that keeps the task executing continuously in the system as long as it is required in the application. Also, Tasks run on their own independent stack.
-
-How to add house keeping functions in the idle Task
-""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-If you want to use the idle time of the system to do some "housekeeping" jobs in the background, when the system is not active on interrupts or tasks, TI RTOS provides option to provide a task list or point to a housekeeping function which will run when no other thread is active in the system. The simplest syntax to add this to your code is shown below:
-
-::
-
-    Task.enableIdleTask = true;
-    var Idle = xdc.useModule('ti.sysbios.knl.Idle');
-    Idle.addFunc('&osTaskIdleFunc');
-
-If you open the BIOS configuration in XGCONF, you will notice that user are allowed to enter upto 8 function in the function list.
-
-Syntax to add idle functions is provided below
-
-::
-
-    var Idle = xdc.useModule('ti.sysbios.knl.Idle');
-    Idle.idleFxns[0] = "&myIdle1";
-
-
-Hardware Interrupts (HWI)
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-How to configure Crossbar when setting up interrupts on DRA7xx/TDA2xx/AM57xx
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-Some socs like AM571x and AM572x have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt lines from the subsystems are not needed at the same time, so they have to be muxed to the irq-controller appropriately. In such places a interrupt controllers are preceded by an CROSSBAR that provides flexibility in muxing the device requests to the controller inputs.
-
-Application developers have two options to setup interrupts on AM57xx/TDA2xx/DRA7xx devices which provide a crossbar mechanism to connect a given IRQ source to an IRQ line on the target cpu's interrupt controller. The device level chip support library provides functional APIs to map interrupt events to target core interrupt controller line.
-
-For example SPI3_IRQ to the CROSSBAR input on DSP and M4, you can use the following:
-
-DSP Core1 configuration of SPI3_IRQ to crossbar input 60:
-
-::
-
-    /* Configure xbar connect for MCSPI3: DSP_IRQ_43 (reserved) mapped to MCSPI3 intr */
-       CSL_xbarIrqConfigure (CSL_XBAR_IRQ_CPU_ID_DSP1,
-                             CSL_XBAR_INST_DSP1_IRQ_43, /* should match with C66 intc eventId used for event combiner that maps to DSP interrupts*/
-                             CSL_XBAR_MCSPI3_IRQ);
-
-IPU core1 configuration of SPI3_IRQ to crossbar input 43:
-
-::
-
-    /* Configure xbar connect for MCSPI3: IPU1_IRQ_60 (reserved) mapped to MCSPI3 intr */
-       CSL_xbarIrqConfigure (CSL_XBAR_IRQ_CPU_ID_IPU1,
-                             CSL_XBAR_INST_IPU1_IRQ_60, /* should match with M4 intNum used for HWI_create */
-                             CSL_XBAR_MCSPI3_IRQ);
-
-Here is how you would define the same interrupt handler for IPU statically in a configuration script:
-
-::
-
-    var Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
-    var IntXbar = xdc.useModule('ti.sysbios.family.shared.vayu.IntXbar');
-    // Connect IRQ 23 to Interrupt source index 86 (SPI3_IRQ)
-    IntXbar.connectIRQMeta(60, 86);
-    // Alternately, the connectIRQMeta API can be used. This
-    // API expects XBAR instance number as an argument.
-    //
-    // Connect Xbar Instance 1 (IRQ 60) to Interrupt
-    // source index 86 (MCSPI3_IRQ)
-    //
-    // IntXbar.connectMeta(1, 60);
-    var hwiParams = new Hwi.Params();
-    hwiParams.arg = 60;
-
-
-Clocks and Timers
-^^^^^^^^^^^^^^^^^^
-
-What are the different clock and timer modules in TI RTOS that you should be aware of?
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-
-* Timer Module
-	* Manages timer peripherals
-	* Provides target/device abstraction
-
-* Clock Module
-	* Manages BIOS “heartbeat”
-	* Can schedule functions to fire in the future (one-shot or periodically)
-	* Input can be configured to use Timer module “tick” or application “tick”
-
-* Timestamp Module
-	* Provides simple time stamping services for benchmarking code
-	* Allows time stamping RTA logs
-
-**BIOS Timer Architecture**
-
-.. Image:: /images/BIOS_Timer_Architecture.png
-   :scale: 50 %
-
-**BIOS Clock Architecture**
-
-.. Image:: /images/BIOS_Clock_Architecture.png
-   :scale: 50 %
-
-
-How to get accurate clock ticks from the clock module?
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The clock module uses the CPU clock setting that is provided by the default platform setting. For example, if the platform is set to AM335x, then the clock is assumed to be 550 MHz, so the clock ticks will be generated with period of 1.8 nanoseconds. '''TI RTOS doesn`t setup the device clocks, the device clock initiation is the responsibility of the initialization code''' (GEL file in debug environment and bootloader in production environment)
-
-After, the clocks are configured, it is the responsibility of the application developer to inform BIOS of the CPU frequency so that accurate system ticks can be generated.
-
-**Note:** For example if the core clock on AM335x is set to 720 MHz instead of default 550 Mhz, then users are required to add the following like the .cfg to inform BIOS kernel of the actual CPU setting.
-
-::
-
-   BIOS.cpuFreq.lo = 720000000;
-
-We reiterate that this doesn`t change the actual frequency but only informs the OS of the change from default CPU freq setting.
-
-How to set input frequency in SYSBIOS configuration and change timer used by clock module
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-Timer.intFreq[index] determines the input clock that drivers the timer. In most cases the input clock is assumed to be the input clock used in TI EVM  (Example: 24 Mhz used on AM335x EVM). If you have a different input on your custom board users are required to change the input Freqency setting in their configuration. To change the dmtimer frequency in SYS/BIOS you need to add the following to your config file:
-
-::
-
-   var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
-   Timer.intFreqs[index] = {hi: 0, lo: 19200000};
-
-Where index is the SYS/BIOS timer ID.  Please remember that timer IDs do not necessarily match the number in the peripheral name.  For example on AM335x SYS/BIOS Timer 0 actually corresponds to DMTimer2 on the device.  Use the `Timer Mapping Table <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_40_01_15/exports/bios_6_40_01_15/docs/cdoc/ti/sysbios/timers/dmtimer/doc-files/TimerTables.html>`__ to determine which timer corresponds to each Timer ID.
-
-The Clock module uses a Timer internally.  By default, the Clock module calls Timer_create() with "ANY" which will return one of the available timers.  You can specify the exact timer using the following (the default value for Clock.timerId is ANY).
-
-
-To set it to a specic timer Id, you can use the following syntax.
-
-::
-
-   Clock= xdc.useModule('ti.sysbios.knl.Clock');
-   Clock.timerId = 3;
-
-
-SemiHosting
-^^^^^^^^^^^^^
-
-Why can`t I see output of System_printf on CCS console?
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-When getting started with TI RTOS, you may notice that the printf from your code goes to CCS console but using non-intrusive System_printf doesn`t. If you want to have System_printf output go to the same place as printf, add the following three lines to your .cfg file and re-build:
-
-::
-
-   var System = xdc.useModule('xdc.runtime.System');
-   var SysStd = xdc.useModule('xdc.runtime.SysStd');
-   System.SupportProxy = SysStd;
-
-If you don't do this, the output will go to a circular buffer in memory. You can examine that buffer using the ROV tool (use the menu: Tools->ROV while in the debugger).
-
-How to enable printf/System_printf to go to CCS IO console on ARM devices
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-Application developers need to add the SemiHosting module to the .cfg manually by editing the config script. Add the following line:
-
-::
-
-   var SemiHostSupport = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');
-
-This module does the required setup (install SVC_Handler and do the required file handle init) to support SemiHosting.
-
-GNU GCC users on ARM platforms need to link to  "rdimon" library to the "GNU Linker" -> "Libraries" view. If the "nosys" library is already listed in the "Libraries" view then replace it with "rdimon". This will cause the application to link with librdimon.a library which is a Semi-Hosting enabled BSP library.
-
-
-Exception Handling
-^^^^^^^^^^^^^^^^^^
-
-How can I get dump of registers when an exception occurs ?
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-If you add this to your .cfg file:
-
-::
-
-   var Exception = xdc.useModule('ti.sysbios.family.c64p.Exception');
-   Exception.enablePrint = true;
-
-SYS/BIOS provides several target unique exception handlers:
-* ti.sysbios.family.arm.exc.Exception - used by all Arm9 and A8 targets
-* ti.sysbios.family.arm.m3.Hwi - used by all cortex-M3 targets
-* ti.sysbios.family.c64p.Exception - used by all C6x targets
-
-a complete exception register context should be dumped to the console in addition to the Error raised by the exception handler when an exception occurs.
-
-If you set a breakpoint at "ti_sysbios_family_c64p_Hwi_int1", this is the function vectored to on all exceptions. No exception processing will have been performed at this point. Using CCS' register dump, you can see the complete state of the processor. The NRP register should contain the PC at the time the exception occurred.
-
-
-How do I determine the call stack at the time of crash
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-A detailed view of analyzing the call stack using CCS tools when your TI RTOS application throws an exception has been described in the article:
-
-* `Exception_Dump_Decoding_Using_the_CCS_Register_View <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#Exception_Dump_Decoding_Using_the_CCS_Register_View>`__
-
-
-
-How can you route exception print to UART
-""""""""""""""""""""""""""""""""""""""""""
-
-The console I/O prints from TI-RTOS can be re-routed to UART. The console I/O messages are printed using the System module which can configured to call callback functions. These callback functions should be configured to write to UART. For example, in your .cfg add a configuration similar to the one below:
-
-::
-
-   /* ================ System configuration ================ */
-   var System = xdc.useModule('xdc.runtime.System');
-   var SysCallback = xdc.useModule('xdc.runtime.SysCallback');
-   SysCallback.abortFxn = "&myUARTAbort";
-   SysCallback.putchFxn = "&myUARTPutch";
-   SysCallback.readyFxn = "&myUARTReady";
-   System.SupportProxy = SysCallback;
-
-And define the functions myUARTAbort, myUARTPutch and myUARTReady in your application. For details about the SysCallback module's callback function signature, please see this link.
-
-For more details refer to the E2E discussion here: `Redirecting Exception logs to UART <https://e2e.ti.com/support/embedded/tirtos/f/355/t/459864>`__
-
-Logging and Trace
-^^^^^^^^^^^^^^^^^^
-
-How get UIA logging working with TI RTOS application?
-""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-In order to get the UIA loggging enabled, you need to include the UIA module and indicate the modules on which you would like obtain the logging information in your application. For example the following configuration will enable Load, Task, Swi and Hwi logging and will enable Task profiler so that you gain visual insight into the execution of the TI RTOS application using System analyzer tools in CCS:
-
-::
-
-   var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
-   LoggingSetup.loadLogging = true;
-   LoggingSetup.loadLoggerSize = 1024;
-   LoggingSetup.mainLoggerSize = 32768;
-   LoggingSetup.sysbiosLoggerSize = 32768;
-   LoggingSetup.sysbiosSwiLogging = true;
-   LoggingSetup.sysbiosHwiLogging = true;
-   LoggingSetup.sysbiosSemaphoreLogging = true;
-   LoggingSetup.loadTaskLogging = true;
-   LoggingSetup.loadSwiLogging = true;
-   LoggingSetup.loadHwiLogging = true;
-   LoggingSetup.enableTaskProfiler = true;
-   LoggingSetup.sysbiosHwiLoggingRuntimeControl = true;
-   LoggingSetup.sysbiosSwiLoggingRuntimeControl = true;
-   LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_JTAGSTOPMODE;
-
-
-**System analyzer view :**
-
-.. Image:: /images/System_Analyzer_Execution_log.png
-
-**For more information refer to :**
-`System Analyzer wiki <http://processors.wiki.ti.com/index.php/Multicore_System_Analyzer>`__
-
-To see how XGCONF graphical tool can be used to add Logging setup, refer to `TI RTOS User Section 2.2 <http://www.ti.com/lit/ug/spruhd4m/spruhd4m.pdf>`__
-
-What SYS/BIOS Debugging Tools do we have in CCS ?
-""""""""""""""""""""""""""""""""""""""""""""""""""
-
-* Real Time analysis(RTA) agent
-
-* RTOS Object View(ROV)
-
-
-Real Time analysis(RTA) agent
-""""""""""""""""""""""""""""""
-
-**Note:** Before Debugging the SYSBIOS Debugging options. It is recommended to set the Preferences under the Windows Tab in CCS to select the version of SYSBIOS, XDCTOOLS in Windows->Preferences->General->RTSC Options. Additionally set IPC and XDAIS if your application uses the components.
-
-#. Real time analysis can easily be turned on in a SYSBIOS based CCS project using the Grace tools. Select the configuration file (.cfg) in your project this will open an available Resources view inside SYSBIOS. Under diagnostics, select the RTA agent and enable it and save the configuration. Rebuild the project with the new settings.
-#. To run your project, choose **Target Debug Active Project** from the CCS menus. If this is the first time you are debugging a project for your target, you may need to set up a CCS Target Configuration. See the CCS help for details.
-#. In the Debug perspective, open the Runtime Object Viewer (ROV) tool by choosing **Tools ROV**. Also open the Raw Logs view by choosing **Tools RTA Raw Logs**. These tools allow you to see the activity of RTSC and SYS/BIOS modules.
-#. Set some breakpoints in the log.c source file. (You can do this by right-clicking on a line and choosing **New Breakpoint &gt; Breakpoint**.) For example, set a breakpoint on the last line of each function in log.c.
-#. Run the application.
-#. In the Raw Logs window, you can see the informational, warning, and error messages sent by the calls to Log module APIs in log.c. The messages that begin with **LM** are diagnostics provided by XDCtools. Messages that begin with “WARNING” come from calls to Log_warning2. Messages that begin with “ERROR” come from calls to Log_error2. Messages that begin with “../log.c” come from calls to Log_info0 and Log_info2 (depending on the number of arguments).</li>
-
-.. Image:: /images/SYSBIOS_Diag.jpg
-   :scale: 50 %
-
-.. Image:: /images/SYSBIOS_Rawlog.jpg
-   :scale: 50 %
-
-.. Image:: /images/Rta_exec2.png
-
-.. Image:: /images/SYSBIOS_CPUload.jpg
-   :scale: 50 %
-
-For advanced debugging options we recommend following the instructions on the `BIOS_6_Real-Time_Analysis_(RTA)_in_CCSv4 <http://processors.wiki.ti.com/index.php/BIOS_6_Real-Time_Analysis_(RTA)_in_CCSv4>`__ wiki
-
-
-RTOS Object View(ROV)
-"""""""""""""""""""""
-
-#. Load your application for debugging. Select the device you want to debug before opening ROV.
-#. In the ROV window, expand the tree to see the ti.sysbios.knl.Task module. The right pane shows a list of the Task threads in the application. As you advance from breakpoint to breakpoint, you see the run mode of the threads change.</li></ol>
-
-.. Image:: /images/1.7.6_Image.png
-   :scale: 50 %
-
-For more details on ROV tools, refer to the `Runtime Object Viewer(ROV) <http://rtsc.eclipse.org/docs-tip/Runtime_Object_Viewer>`__ article on RTSC website.
-
-Memory and Heap
-^^^^^^^^^^^^^^^^
-
-What kind of heap should I use in SYSBIOS application and how do I allocate Heap in my configuration
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-SYSBIOS Supports five different type of Heap implementation:
-
-* HeapMin. Very small code footprint implementation. Supports non blocking memory allocation, but does not support freeing memory.
-* HeapMem. Allocate variable-size blocks and uses Gate module to protect allocation and freeing of memory. typically Slower and non-deterministic
-* HeapBuf. Allocate fixed-size blocks. Fast deterministic and non-blocking as allocation uses same size.
-* HeapMultiBuf. Specify variable-size allocation, but internally allocate from a variety of fixed-size blocks. Good tradeoff for HeapMem and HeapBuf
-* HeapTrack. Used to detect memory allocation and deallocation problems. Good for debugging as it detects memory leaks and buffer overflows.
-
-Typical allocation of static heap within the SYSBIOS \*.cfg file is shown below:
-
-::
-
-   var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
-   /* Create a Heap. */
-   var heapMemParams = new HeapMem.Params();
-   heapMemParams.size = 0x8000000;                             // <-- edit this value to tune the size of the heap
-   heapMemParams.sectionName = "systemHeapMaster";
-   Program.global.heap0 = HeapMem.create(heapMemParams);
-   Memory.defaultHeapInstance = Program.global.heap0;
-
-
-Benchmarks
-^^^^^^^^^^^
-
-Where can I find Memory foot print, Interrupt latency and performance numbers of the TI RTOS when designing my system
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The Memory footprint and Interrupt latency for different processor architectures is provided in the SYSBIOS package. It can be located at
- bios_6_xx_xx_xx/packages/ti/sysbios/benchmarks/doc-files
-
-The Foot print of the OS depends on number of BIOS kernel modules used by the application but an estimate of the foot print can be computed by adding up the module footprint numbers to the base kernel footprint. The interrupt latency is mostly deterministic in the system but OS response may depend on priority of the interrupt setup. If the 2 or more interrupts occur simultaneously, the premptive BIOS scheduler will let the higher HWI to run before letting the one with lower priority so it may seem as the the lower priority interrupt response is slightly slower.
-
-Debugging
-^^^^^^^^^^
-
-How to debug common application issues like stack overflow, exception and memory leaks
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-Common Application debug scenarios like exception management, memory leak and stack issues have been described in the following training video:
-`Debugging Common Application Issues TI RTOS <https://training.ti.com/debugging-common-application-issues-ti-rtos>`__
-
-The training covers stack over flow, exception handling and memory management issues in detail with a Lab for TI MCU devices but the same concepts and features also apply for TI ARM and DSP processors.
-
-
-How to add Custom compiler options  and build custom BIOS library
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-Users are allowed to change the libType and specify the compiler options from their BIOS configuration using the following
-
-::
-
-   BIOS.libType = BIOS.LibType_Custom;
-   // For Cortex A8 device like AM335x
-   BIOS.customCCOpts = "--endian=little -mv7A8 --abi=eabi --neon --float_support=vfpv3 -q -ms --program_level_compile -o3 --opt_for_speed=3"
-   // For Cortex A9 device like AM437x
-   BIOS.customCCOpts ="-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -mabi=aapcs -O3 -Wunused -Wunknown-pragmas -ffunction-sections -fdata-sections -g "
-
-To remove a given compiler setting, you can use:
-
-::
-
-   BIOS.customCCOpts = BIOS.customCCOpts.replace(" -g ","");
-
diff --git a/source/rtos/How_to_Guides/Host/Setup/_Update_ENV_for_a_Custom_Path.rst b/source/rtos/How_to_Guides/Host/Setup/_Update_ENV_for_a_Custom_Path.rst
deleted file mode 100644
index b6c56dc36..000000000
--- a/source/rtos/How_to_Guides/Host/Setup/_Update_ENV_for_a_Custom_Path.rst
+++ /dev/null
@@ -1,482 +0,0 @@
-Update environment when installing to a custom path
------------------------------------------------------
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Install_In_Custom_Path
-
-Overview
-^^^^^^^^
-
-This page will provide configuration information if the SDK is installed
-in a custom path.
-
-**Useful Tip**
-
-To avoid changing environment variable for each new shell, modify
-environment variable file directly. This file is the *setupenv* file
-located in the SDK root directory.
-
-
-
-Changes to CCS Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing the SDK in a folder other than where CCS is installed will
-require modifications to CCS to be able to discover the SDK. See the
-`Setup CCS </index.php/Processor_SDK_RTOS_Setup_CCS>`__ **How To** page
-explaining how to update CCS configuration.
-
-
-
-Rebuilding the SDK RTOS
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing the SDK in a folder other than the default (``C:\TI`` for
-Windows, ``/home/[user]/ti`` for Linux) requires modifications to SDK
-RTOS scripts in order for recompilation and example/test creation to
-work properly.
-
-In all the commands below, replace *[version]* with the appropriate
-version of the software/tool.
-
-CCS in Custom Path and SDK RTOS in Default Path
-"""""""""""""""""""""""""""""""""""""""""""""""
-
-CCS installation and toolchain paths can be customized by setting the
-TOOLS_INSTALL_PATH environment variable prior to running the SDK level
-setupenv script. This feature is used if CCS and the toolchains are
-installed somewhere other than the default C:\\ti location.
-
-For example, environment configuration assuming CCS is installed to
-[os_base]\\ti_temp and SDK RTOS has been installed to default path,
-[os_base]\\ti :
-
--  Windows
-
-::
-
-    C:\> set TOOLS_INSTALL_PATH=C:\ti_temp
-
-::
-
-    C:\> cd C:\ti\processor_sdk_rtos_[soc]_[version]
-
-::
-
-    C:\ti\processor_sdk_rtos_[soc]_[version]> setupenv.bat
-
-Gives the output:
-
-::
-
-    Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
-    Optional parameter not configured : DOXYGEN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
-    **************************************************************************
-    Environment Configuration:
-        PDK Directory             : /ti/PDK_AM~3/packages/
-        CGTOOL INSTALL Directory  : C:/ti_temp/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-        TOOLCHAIN A15 Directory   : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A8 Directory    : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A9 Directory    : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN M4 Directory    : C:/ti_temp/ccsv6/tools/compiler/ti-cgt-arm_[version]
-        FPULIB_PATH               : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-        CROSS_TOOL_PRFX           : arm-none-eabi-
-        XDC_INSTALL_PATH          : C:/ti/xdctools_[version]_core
-        BIOS_INSTALL_PATH         : C:/ti/bios_[version]
-        IPC_INSTALL_PATH          : C:/ti/ipc_[version]
-        EDMA3LLD_BIOS6_INSTALLDIR : C:/ti/edma3_lld_[version]
-        NDK_INSTALL_PATH          : C:/ti/ndk_[version]
-        IMGLIB_INSTALL_PATH       : C:/ti/imglib_c66x_[version]
-        UIA_INSTALL_PATH          : C:/ti/uia_[version]
-        PROC_SDK_INSTALL_PATH     : C:/ti/processor_sdk_rtos_[soc]_[version]
-    **************************************************************************
-    Changing to short name to support directory names containing spaces
-    current directory: C:/ti/processor_sdk_rtos_[soc]_[version]
-    PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-    **************************************************************************
-
--  Linux
-
-::
-
-    $ export TOOLS_INSTALL_PATH=~/ti_temp
-
-::
-
-    $ cd ~/ti/processor_sdk_rtos_[soc]_[version]/
-
-::
-
-    ~/ti/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh
-
-Gives the output:
-
-::
-
-    Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
-    Optional parameter not configured : DOXYGEN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
-    **************************************************************************
-    Environment Configuration:
-        PDK Directory             : /home/[user]/ti/pdk_[soc]_[version]/packages
-        CGTOOL INSTALL Directory  : /home/[user]/ti_temp/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-        TOOLCHAIN A15 Directory   : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A8 Directory    : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A9 Directory    : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN M4 Directory    : /home/[user]/ti_temp/ccsv6/tools/compiler/ti-cgt-arm_[version]
-        FPULIB_PATH               : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-        CROSS_TOOL_PRFX           : arm-none-eabi-
-        XDC_INSTALL_PATH          : /home/[user]/ti/xdctools_[version]_core
-        BIOS_INSTALL_PATH         : /home/[user]/ti/bios_[version]
-        IPC_INSTALL_PATH          : /home/[user]/ti/ipc_[version]
-        EDMA3LLD_BIOS6_INSTALLDIR : /home/[user]/ti/edma3_lld_[version]
-        NDK_INSTALL_PATH          : /home/[user]/ti/ndk_[version]
-        IMGLIB_INSTALL_PATH       : /home/[user]/ti/imglib_c66x_[version]
-        UIA_INSTALL_PATH          : /home/[user]/ti/uia_[version]
-        PROC_SDK_INSTALL_PATH     : /home/[user]/ti/processor_sdk_rtos_[soc]_[version]
-
-    PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-    *******************************************************************************
-
-The `RTOS SDK top level
-Makefile <index_overview.html#top-level-makefile>`__
-can now be used to rebuild SDK RTOS components with CCS and toolchains
-installed in a custom installation path.
-
-CCS in Default Path and SDK RTOS in Custom Path
-"""""""""""""""""""""""""""""""""""""""""""""""
-
-SDK RTOS component installation paths can be customized by setting the
-SDK_INSTALL_PATH variable prior to running the SDK level setupenv
-script. This feature is used if the SDK is installed somewhere other
-than the default ``C:\ti`` location.
-
-For example, environment configuration assuming CCS is installed to the
-default path, ``[os_base]\ti`` and SDK RTOS has been installed to
-``[os_base]\ti_temp``:
-
--  Windows
-
-::
-
-    C:\> set SDK_INSTALL_PATH=C:/ti_temp
-
-::
-
-    C:\> cd C:\ti_temp\processor_sdk_rtos_[soc]_[version]
-
-::
-
-    C:\ti_temp\processor_sdk_rtos_[soc]_[version]> setupenv.bat
-
-Gives the output:
-
-::
-
-    Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
-    Optional parameter not configured : DOXYGEN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
-    **************************************************************************
-    Environment Configuration:
-        PDK Directory             : /ti_temp/PDK_AM~3/packages/
-        CGTOOL INSTALL Directory  : C:/ti/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-        TOOLCHAIN A15 Directory   : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A8 Directory    : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A9 Directory    : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN M4 Directory    : C:/ti/ccsv6/tools/compiler/ti-cgt-arm_[version]
-        FPULIB_PATH               : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-        CROSS_TOOL_PRFX           : arm-none-eabi-
-        XDC_INSTALL_PATH          : C:/ti_temp/xdctools_[version]_core
-        BIOS_INSTALL_PATH         : C:/ti_temp/bios_[version]
-        IPC_INSTALL_PATH          : C:/ti_temp/ipc_[version]
-        EDMA3LLD_BIOS6_INSTALLDIR : C:/ti_temp/edma3_lld_[version]
-        NDK_INSTALL_PATH          : C:/ti_temp/ndk_[version]
-        IMGLIB_INSTALL_PATH       : C:/ti_temp/imglib_c66x_[version]
-        UIA_INSTALL_PATH          : C:/ti_temp/uia_[version]
-        PROC_SDK_INSTALL_PATH     : C:/ti_temp/processor_sdk_rtos_[soc]_[version]
-    **************************************************************************
-    Changing to short name to support directory names containing spaces
-    current directory: C:/ti_temp/processor_sdk_rtos_[soc]_[version]
-    PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-    **************************************************************************
-
--  Linux
-
-::
-
-    $ export SDK_INSTALL_PATH=~/ti_temp
-
-::
-
-    $ cd ~/ti_temp/processor_sdk_rtos_[soc]_[version]/
-
-::
-
-    ~/ti_temp/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh
-
-Gives the output:
-
-::
-
-    Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
-    Optional parameter not configured : DOXYGEN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
-    **************************************************************************
-    Environment Configuration:
-        PDK Directory             : /home/[user]/ti_temp/pdk_[soc]_[version]/packages
-        CGTOOL INSTALL Directory  : /home/[user]/ti/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-        TOOLCHAIN A15 Directory   : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A8 Directory    : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A9 Directory    : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN M4 Directory    : /home/[user]/ti/ccsv6/tools/compiler/ti-cgt-arm_[version]
-        FPULIB_PATH               : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-        CROSS_TOOL_PRFX           : arm-none-eabi-
-        XDC_INSTALL_PATH          : /home/[user]/ti_temp/xdctools_[version]_core
-        BIOS_INSTALL_PATH         : /home/[user]/ti_temp/bios_[version]
-        IPC_INSTALL_PATH          : /home/[user]/ti_temp/ipc_[version]
-        EDMA3LLD_BIOS6_INSTALLDIR : /home/[user]/ti_temp/edma3_lld_[version]
-        NDK_INSTALL_PATH          : /home/[user]/ti_temp/ndk_[version]
-        IMGLIB_INSTALL_PATH       : /home/[user]/ti_temp/imglib_c66x_[version]
-        UIA_INSTALL_PATH          : /home/[user]/ti_temp/uia_[version]
-        PROC_SDK_INSTALL_PATH     : /home/[user]/ti_temp/processor_sdk_rtos_[soc]_[version]
-
-    PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-    *******************************************************************************
-
-The `RTOS SDK top level
-Makefile <index_overview.html#top-level-makefile>`__
-can now be used to rebuild SDK RTOS components installed in the custom
-installation path.
-
-.. note::
-   The following known issue impacts this step:
-   **PRSDK-1263**: PDK AM437x: Make fails on Windows if CCS is installed in
-   custom path. **Workaround:** Edit the UTILS_INSTALL_DIR variable in
-   <pdk_root_dir>/packages/ti/starterware/Rules.make to point to the CCS
-   installation on your Windows PC.
-
-CCS and SDK RTOS in Custom Path
-"""""""""""""""""""""""""""""""
-
-When CCS and the SDK RTOS are both installed to custom paths the SDK can
-be rebuilt by setting the SDK_INSTALL_PATH and TOOLS_INSTALL_PATH
-variables prior to running the SDK RTOS top level environment setup
-script. The Windows and Linux environment setup scripts can be found in
-the following locations, respectively:
-
--  Windows -
-   C:\\custom\\install\\path\\processor_sdk_rtos_[soc]_[version]\\setupenv.bat
--  Linux -
-   /home/[user]/custom/install/path/processor_sdk_rtos_[soc]_[version]/setupenv.sh
-
-The SDK_INSTALL_PATH and TOOLS_INSTALL_PATH environment variables must
-be set to the custom install path **prior to running** the environment
-setup script.
-
-For example, environment configuration assuming CCS and the SDK have
-been installed to [os_base]\\new_sdk_release\\ :
-
--  Windows
-
-::
-
-    C:\> set SDK_INSTALL_PATH=C:\new_sdk_release
-    C:\> set TOOLS_INSTALL_PATH=C:\new_sdk_release
-
-::
-
-    C:\> cd C:\new_sdk_release\processor_sdk_rtos_[soc]_[version]
-
-::
-
-    C:\new_sdk_release\processor_sdk_rtos_[soc]_[version]> setupenv.bat
-
-Gives the output:
-
-::
-
-    Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
-    Optional parameter not configured : DOXYGEN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
-    **************************************************************************
-    Environment Configuration:
-        PDK Directory             : /NEW_SD~1/PDK_AM~1/packages/
-        CGTOOL INSTALL Directory  : C:/new_sdk_release/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-        TOOLCHAIN A15 Directory   : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A8 Directory    : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A9 Directory    : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN M4 Directory    : C:/new_sdk_release/ccsv6/tools/compiler/ti-cgt-arm_[version]
-        FPULIB_PATH               : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-        CROSS_TOOL_PRFX           : arm-none-eabi-
-        XDC_INSTALL_PATH          : C:/new_sdk_release/xdctools_[version]_core
-        BIOS_INSTALL_PATH         : C:/new_sdk_release/bios_[version]
-        IPC_INSTALL_PATH          : C:/new_sdk_release/ipc_[version]
-        EDMA3LLD_BIOS6_INSTALLDIR : C:/new_sdk_release/edma3_lld_[version]
-        NDK_INSTALL_PATH          : C:/new_sdk_release/ndk_[version]
-        IMGLIB_INSTALL_PATH       : C:/new_sdk_release/imglib_c66x_[version]
-        UIA_INSTALL_PATH          : C:/new_sdk_release/uia_[version]
-        PROC_SDK_INSTALL_PATH     : C:/new_sdk_release/processor_sdk_rtos_[soc]_[version]
-    **************************************************************************
-    Changing to short name to support directory names containing spaces
-    current directory: C:/new_sdk_release/processor_sdk_rtos_[soc]_[version]
-    PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-    **************************************************************************
-
--  Linux
-
-::
-
-    $ export SDK_INSTALL_PATH=~/new_sdk_release
-    $ export TOOLS_INSTALL_PATH=~/new_sdk_release
-
-::
-
-    $ cd ~/new_sdk_release/processor_sdk_rtos_[soc]_[version]/
-
-::
-
-    ~/new_sdk_release/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh
-
-Gives the output:
-
-::
-
-    Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
-    Optional parameter not configured : DOXYGEN_INSTALL_PATH
-    REQUIRED for xdc release build
-    Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
-    **************************************************************************
-    Environment Configuration:
-        PDK Directory             : /home/[user]/new_sdk_release/pdk_[soc]_[version]/packages
-        CGTOOL INSTALL Directory  : /home/[user]/new_sdk_release/ccsv6/tools/compiler/ti-cgt-c6000_[version]
-        TOOLCHAIN A15 Directory   : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A8 Directory    : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN A9 Directory    : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
-        TOOLCHAIN M4 Directory    : /home/[user]/new_sdk_release/ccsv6/tools/compiler/ti-cgt-arm_[version]
-        FPULIB_PATH               : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
-        CROSS_TOOL_PRFX           : arm-none-eabi-
-        XDC_INSTALL_PATH          : /home/[user]/new_sdk_release/xdctools_[version]_core
-        BIOS_INSTALL_PATH         : /home/[user]/new_sdk_release/bios_[version]
-        IPC_INSTALL_PATH          : /home/[user]/new_sdk_release/ipc_[version]
-        EDMA3LLD_BIOS6_INSTALLDIR : /home/[user]/new_sdk_release/edma3_lld_[version]
-        NDK_INSTALL_PATH          : /home/[user]/new_sdk_release/ndk_[version]
-        IMGLIB_INSTALL_PATH       : /home/[user]/new_sdk_release/imglib_c66x_[version]
-        UIA_INSTALL_PATH          : /home/[user]/new_sdk_release/uia_[version]
-        PROC_SDK_INSTALL_PATH     : /home/[user]/new_sdk_release/processor_sdk_rtos_[soc]_[version]
-
-    PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-    *******************************************************************************
-
-The `RTOS SDK top level Makefile <index_overview.html#top-level-makefile>`__
-can now be used to rebuild SDK RTOS components installed in the custom
-installation path using CCS and toolchains installed in a custom path as
-well.
-
-
-Rebuilding the PDK
-^^^^^^^^^^^^^^^^^^
-
-Installing the PDK in a folder other than the default (C:\TI for
-Windows, /home/[user]/ti for Linux) requires modifications to PDK
-scripts in order for recompilation and example/test creation to work
-properly.
-
-CCS in Custom Path and PDK in Default Path
-""""""""""""""""""""""""""""""""""""""""""
-
-The instructions provided in the `CCS in Custom Path and SDK RTOS in
-Default
-Path </index.php/Processor_SDK_RTOS_Install_In_Custom_Path#CCS_in_Custom_Path_and_SDK_RTOS_in_Default_Path>`__
-section can be used to rebuild components at the PDK level. The only
-difference is the PDK level setup script should be used instead of the
-SDK RTOS level setup script. The PDK level setup scripts are found in
-the following locations on Windows and Linux, respectively:
-
--  Windows -
-   C:\\custom\\install\\path\\pdk_[soc]_[version]\\packages\\pdksetupenv.bat
--  Linux -
-   /home/[user]/custom/install/path/pdk_[soc]_[version]/packages/pdksetupenv.sh
-
-CCS in Default Path and PDK in Custom Path
-""""""""""""""""""""""""""""""""""""""""""
-
-The instructions provided in the `CCS in Default Path and SDK RTOS in
-Custom
-Path </index.php/Processor_SDK_RTOS_Install_In_Custom_Path#CCS_in_Default_Path_and_SDK_RTOS_in_Custom_Path>`__
-section can be used to rebuild components at the PDK level. The only
-difference is the PDK level setup script should be used instead of the
-SDK RTOS level setup script. The PDK level setup scripts are found in
-the following locations on Windows and Linux, respectively:
-
--  Windows -
-   C:\\custom\\install\\path\\pdk_[soc]_[version]\\packages\\pdksetupenv.bat
--  Linux -
-   /home/[user]/custom/install/path/pdk_[soc]_[version]/packages/pdksetupenv.sh
-
-CCS and PDK in Custom Path
-""""""""""""""""""""""""""
-
-The instructions provided in the `CCS and SDK RTOS in Custom
-Path </index.php/Processor_SDK_RTOS_Install_In_Custom_Path#CCS_and_SDK_RTOS_in_Custom_Path>`__
-section can be used to rebuild components at the PDK level. The only
-difference is the PDK level setup script should be used instead of the
-SDK RTOS level setup script. The PDK level setup scripts are found in
-the following locations on Windows and Linux, respectively:
-
--  Windows -
-   C:\\custom\\install\\path\\pdk_[soc]_[version]\\packages\\pdksetupenv.bat
--  Linux -
-   /home/[user]/custom/install/path/pdk_[soc]_[version]/packages/pdksetupenv.sh
-
-
-Creating PDK Example/Test Projects When CCS is Installed to Custom Path
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The pdkProjectCreate scripts must be modified in order to build PDK
-example and test projects only if CCS has been installed to a custom
-path. The modification is the same for both Windows and Linux. Inside
-the pdkProjectCreate scripts is a CCS_INSTALL_PATH variable which points
-to the Code Composer Studio root directory. This variable must be
-redefined to the new location of the CCS root directory if CCS is
-installed to a custom path.
-
--  Windows
-
-::
-
-    REM Install Location for CCS
-    set CCS_INSTALL_PATH="C:\ti\ccsv6"
-
--  Linux
-
-::
-
-    # Install Location for CCS
-    export CCS_INSTALL_PATH=~/ti/ccsv6
-
-.. note::
-   Prior to invoking the pdkProjectCreate script, make sure to start CCS
-   and register the SDK RTOS components installed. Project creation will
-   fail if the RTOS SDK components installed to the custom path have not
-   been registered with CCS. Please see `CCS and SDK installed in different
-   directories </index.php/Processor_SDK_RTOS_Setup_CCS#CCS_and_SDK_installed_in_different_directories>`__
-   for instructions on how to register SDK RTOS components installed to a
-   custom path with CCS
-
diff --git a/source/rtos/How_to_Guides/Host/System_Integration/K3_Resource_Partitioning_Tool.rst b/source/rtos/How_to_Guides/Host/System_Integration/K3_Resource_Partitioning_Tool.rst
deleted file mode 100644
index a7dd129fc..000000000
--- a/source/rtos/How_to_Guides/Host/System_Integration/K3_Resource_Partitioning_Tool.rst
+++ /dev/null
@@ -1 +0,0 @@
-.. include:: /common/Tools/_K3_Resource_Partitioning.rst
diff --git a/source/rtos/How_to_Guides/Host/System_Integration/_Create_DSP_and_IPU_FW_using_PDK_and_IPC_to_load_from_ARM_AM57xx.rst b/source/rtos/How_to_Guides/Host/System_Integration/_Create_DSP_and_IPU_FW_using_PDK_and_IPC_to_load_from_ARM_AM57xx.rst
deleted file mode 100644
index bf0c1188a..000000000
--- a/source/rtos/How_to_Guides/Host/System_Integration/_Create_DSP_and_IPU_FW_using_PDK_and_IPC_to_load_from_ARM_AM57xx.rst
+++ /dev/null
@@ -1,2010 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Linux_IPC_on_AM57xx#Adding_IPC_to_an_Existing_TI-RTOS_Application
-
-Introduction
-^^^^^^^^^^^^
-
-This article is geared toward AM57xx users that are running Linux on the
-Cortex A15. The goal is to help users understand how to gain entitlement
-to the DSP (c66x) and IPU (Cortex M4) subsystems of the AM57xx.
-
-AM572x device has two IPU subsystems (IPUSS), each of which has 2 cores.
-IPU2 is used as a controller in multi-media applications, so if you have
-Processor SDK Linux running, chances are that IPU2 already has firmware
-loaded. However, IPU1 is open for general purpose programming to offload
-the ARM tasks.
-
-There are many facets to this task: building, loading, debugging, MMUs,
-memory sharing, etc. This article intends to take incremental steps
-toward understanding all of those pieces.
-
-.. rubric:: Software Dependencies to Get Started
-   :name: software-dependencies-to-get-started
-
-Prerequisites
-
--  `Processor SDK Linux for
-   AM57xx <http://software-dl.ti.com/processor-sdk-linux/esd/AM57X/latest/index_FDS.html>`__
-   (Version 3.01 or newer needed)
--  `Processor SDK RTOS for
-   AM57xx <http://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/latest/index_FDS.html>`__
--  `Code Composer
-   Studio <http://processors.wiki.ti.com/index.php/Download_CCS>`__
-   (choose version as specified on Proc SDK download page)
-
-.. note::
-   Please be sure that you have the same version number
-   for both Processor SDK RTOS and Linux.
-
-For reference within the context of this wiki page, the Linux SDK is
-installed at the following location:
-
-::
-
-    /mnt/data/user/ti-processor-sdk-linux-am57xx-evm-xx.xx.xx.xx
-    ├── bin
-    ├── board-support
-    ├── docs
-    ├── example-applications
-    ├── filesystem
-    ├── ipc-build.txt
-    ├── linux-devkit
-    ├── Makefile
-    ├── Rules.make
-    └── setup.sh
-
-The RTOS SDK is installed at:
-
-::
-
-    /mnt/data/user/my_custom_install_sdk_rtos_am57xx_xx.xx
-    ├── bios_6_xx_xx_xx
-    ├── cg_xml
-    ├── ctoolslib_x_x_x_x
-    ├── dsplib_c66x_x_x_x_x
-    ├── edma3_lld_2_xx_xx_xx
-    ├── framework_components_x_xx_xx_xx
-    ├── imglib_c66x_x_x_x_x
-    ├── ipc_3_xx_xx_xx
-    ├── mathlib_c66x_3_x_x_x
-    ├── ndk_2_xx_xx_xx
-    ├── opencl_rtos_am57xx_01_01_xx_xx
-    ├── openmp_dsp_am57xx_2_04_xx_xx
-    ├── pdk_am57xx_x_x_x
-    ├── processor_sdk_rtos_am57xx_x_xx_xx_xx
-    ├── uia_2_xx_xx_xx
-    ├── xdais_7_xx_xx_xx
-
-CCS is installed at:
-
-::
-
-    /mnt/data/user/ti/my_custom_ccs_x.x.x_install
-    ├── ccsvX
-    │   ├── ccs_base
-    │   ├── doc
-    │   ├── eclipse
-    │   ├── install_info
-    │   ├── install_logs
-    │   ├── install_scripts
-    │   ├── tools
-    │   ├── uninstall_ccs
-    │   ├── uninstall_ccs.dat
-    │   ├── uninstallers
-    │   └── utils
-    ├── Code Composer Studio x.x.x.desktop
-    └── xdctools_x_xx_xx_xx_core
-        ├── bin
-        ├── config.jar
-        ├── docs
-        ├── eclipse
-        ├── etc
-        ├── gmake
-        ├── include
-        ├── package
-        ├── packages
-        ├── package.xdc
-        ├── tconfini.tcf
-        ├── xdc
-        ├── xdctools_3_xx_xx_xx_manifest.html
-        ├── xdctools_3_xx_xx_xx_release_notes.html
-        ├── xs
-        └── xs.x86U
-
-|
-
-.. rubric:: Typical Boot Flow on AM572x for ARM Linux users
-   :name: typical-boot-flow-on-am572x-for-arm-linux-users
-
-AM57xx SOC's have multiple processor cores - Cortex A15, C66x DSP's and
-ARM M4 cores. The A15 typically runs a HLOS like Linux/QNX/Android and
-the remotecores(DSP's and M4's) run a RTOS. In the normal operation,
-boot loader(U-Boot/SPL) boots and loads the A15 with the HLOS. The A15
-boots the DSP and the M4 cores.
-
-.. Image:: /images/Normal-boot.png
-
-In this sequence, the interval between the Power on Reset and the
-remotecores (i.e. the DSP's and the M4's) executing is dependent on the
-HLOS initialization time.
-
-|
-
-Getting Started with IPC Linux Examples
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The figure below illustrates how remoteproc/rpmsg driver from ARM Linux
-kernel communicates with IPC driver on slave processor (e.g. DSP, IPU,
-etc) running RTOS.
-
-.. Image:: /images/LinuxIPC_with_RTOS_Slave.png
-
-In order to setup IPC on slave cores, we provide some pre-built examples
-in IPC package that can be run from ARM Linux. The subsequent sections
-describe how to build and run this examples and use that as a starting
-point for this effort.
-
-.. rubric:: Building the Bundled IPC Examples
-   :name: building-the-bundled-ipc-examples
-
-The instructions to build IPC examples found under
-ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf have been provided in the
-**`Processor_SDK IPC Quick Start
-Guide <http://processors.wiki.ti.com/index.php/Processor_SDK_IPC_Quick_Start_Guide#Build_IPC_Linux_examples>`__.**
-
-Let's focus on one example in particular, ex02_messageq, which is
-located at
-**<rtos-sdk-install-dir>/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq**.
-Here are the key files that you should see after a successful build:
-
-::
-
-    ├── dsp1
-    │   └── bin
-    │       ├── debug
-    │       │   └── server_dsp1.xe66
-    │       └── release
-    │           └── server_dsp1.xe66
-    ├── dsp2
-    │   └── bin
-    │       ├── debug
-    │       │   └── server_dsp2.xe66
-    │       └── release
-    │           └── server_dsp2.xe66
-    ├── host
-    │       ├── debug
-    │       │   └── app_host
-    │       └── release
-    │           └── app_host
-    ├── ipu1
-    │   └── bin
-    │       ├── debug
-    │       │   └── server_ipu1.xem4
-    │       └── release
-    │           └── server_ipu1.xem4
-    └── ipu2
-        └── bin
-            ├── debug
-            │   └── server_ipu2.xem4
-            └── release
-                └── server_ipu2.xem4
-
-|
-
-|
-
-.. rubric:: Running the Bundled IPC Examples
-   :name: running-the-bundled-ipc-examples
-
-On the target, let's create a directory called ipc-starter:
-
-::
-
-    root@am57xx-evm:~# mkdir -p /home/root/ipc-starter
-    root@am57xx-evm:~# cd /home/root/ipc-starter/
-
-You will need to copy the ex02_messageq directory of your host PC to
-that directory on the target (through SD card, NFS export, SCP, etc.).
-You can copy the entire directory, though we're primarily interested in
-these files:
-
--  dsp1/bin/debug/server_dsp1.xe66
--  dsp2/bin/debug/server_dsp2.xe66
--  host/bin/debug/app_host
--  ipu1/bin/debug/server_ipu1.xem4
--  ipu2/bin/debug/server_ipu2.xem4
-
-The remoteproc driver is hard-coded to look for specific files when
-loading the DSP/M4. Here are the files it looks for:
-
--  /lib/firmware/dra7-dsp1-fw.xe66
--  /lib/firmware/dra7-dsp2-fw.xe66
--  /lib/firmware/dra7-ipu1-fw.xem4
--  /lib/firmware/dra7-ipu2-fw.xem4
-
-These are generally a soft link to the intended executable. So for
-example, let's update the DSP1 executable on the target:
-
-::
-
-    root@am57xx-evm:~# cd /lib/firmware/
-    root@am57xx-evm:/lib/firmware# rm dra7-dsp1-fw.xe66
-    root@am57xx-evm:/lib/firmware# ln -s /home/root/ipc-starter/ex02_messageq/dsp1/bin/debug/server_dsp1.xe66 dra7-dsp1-fw.xe66
-
-To reload DSP1 with this new executable, we perform the following steps:
-
-::
-
-    root@am57xx-evm:/lib/firmware# cd /sys/bus/platform/drivers/omap-rproc/
-    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > unbind
-    [27639.985631] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
-    [27639.991534] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
-    [27639.997610] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
-    [27640.017557] omap_hwmod: mmu1_dsp1: _wait_target_disable failed
-    [27640.030571] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
-    [27640.036605]  remoteproc2: stopped remote processor 40800000.dsp
-    [27640.042805]  remoteproc2: releasing 40800000.dsp
-    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > bind
-    [27645.958613] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
-    [27645.966452]  remoteproc2: 40800000.dsp is available
-    [27645.971410]  remoteproc2: Note: remoteproc is still under development and considered experimental.
-    [27645.980536]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
-    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# [27646.008171]  remoteproc2: powering up 40800000.dsp
-    [27646.013038]  remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 4706800
-    [27646.028920] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
-    [27646.034819] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
-    [27646.040772] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
-    [27646.058323]  remoteproc2: remote processor 40800000.dsp is now up
-    [27646.064772] virtio_rpmsg_bus virtio2: rpmsg host is online
-    [27646.072271]  remoteproc2: registered virtio2 (type 7)
-    [27646.078026] virtio_rpmsg_bus virtio2: creating channel rpmsg-proto addr 0x3d
-
-More info related to loading firmware to the various cores can be found
-`here </index.php/Processor_Training:_Multimedia#Firmware_Loading_and_Unloading>`__.
-
-Finally, we can run the example on DSP1:
-
-::
-
-    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# cd /home/root/ipc-starter/ex02_messageq/host/bin/debug
-    root@am57xx-evm:~/ipc-starter/ex02_messageq/host/bin/debug# ./app_host DSP1
-    --> main:
-    [33590.700700] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
-    [33590.706609] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
-    [33590.718798] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
-    --> Main_main:
-    --> App_create:
-    App_create: Host is ready
-    <-- App_create:
-    --> App_exec:
-    App_exec: sending message 1
-    App_exec: sending message 2
-    App_exec: sending message 3
-    App_exec: message received, sending message 4
-    App_exec: message received, sending message 5
-    App_exec: message received, sending message 6
-    App_exec: message received, sending message 7
-    App_exec: message received, sending message 8
-    App_exec: message received, sending message 9
-    App_exec: message received, sending message 10
-    App_exec: message received, sending message 11
-    App_exec: message received, sending message 12
-    App_exec: message received, sending message 13
-    App_exec: message received, sending message 14
-    App_exec: message received, sending message 15
-    App_exec: message received
-    App_exec: message received
-    App_exec: message received
-    <-- App_exec: 0
-    --> App_delete:
-    <-- App_delete:
-    <-- Main_main:
-    <-- main:
-
-|
-The similar procedure can be used for DSP2/IPU1/IPU2 also to update
-the soft link of the firmware, reload the firmware at run-time, and
-run the host binary from A15.
-
-Understanding the Memory Map
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: Overall Linux Memory Map
-   :name: overall-linux-memory-map
-
-::
-
-    root@am57xx-evm:~# cat /proc/iomem
-    [snip...]
-    58060000-58078fff : core
-    58820000-5882ffff : l2ram
-    58882000-588820ff : /ocp/mmu@58882000
-    80000000-9fffffff : System RAM
-    80008000-808d204b : Kernel code
-    80926000-809c96bf : Kernel data
-    a0000000-abffffff : CMEM
-    ac000000-ffcfffff : System RAM
-
-|
-
-.. rubric:: CMA Carveouts
-   :name: cma-carveouts
-
-::
-
-    root@am57xx-evm:~# dmesg | grep -i cma
-    [    0.000000] Reserved memory: created CMA memory pool at 0x0000000095800000, size 56 MiB
-    [    0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
-    [    0.000000] Reserved memory: created CMA memory pool at 0x0000000099000000, size 64 MiB
-    [    0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
-    [    0.000000] Reserved memory: created CMA memory pool at 0x000000009d000000, size 32 MiB
-    [    0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
-    [    0.000000] Reserved memory: created CMA memory pool at 0x000000009f000000, size 8 MiB
-    [    0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
-    [    0.000000] cma: Reserved 24 MiB at 0x00000000fe400000
-    [    0.000000] Memory: 1713468K/1897472K available (6535K kernel code, 358K rwdata, 2464K rodata, 332K init, 289K bss, 28356K reserved, 155648K  cma-reserved, 1283072K highmem)
-    [    5.492945] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
-    [    5.603289] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
-    [    5.713411] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@9b000000
-    [    5.771990] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
-
-From the output above, we can derive the location and size of each CMA
-carveout:
-
-+----------------+------------------+-------+
-| Memory Section | Physical Address | Size  |
-+================+==================+=======+
-| IPU2 CMA       | 0x95800000       | 56 MB |
-+----------------+------------------+-------+
-| DSP1 CMA       | 0x99000000       | 64 MB |
-+----------------+------------------+-------+
-| IPU1 CMA       | 0x9d000000       | 32 MB |
-+----------------+------------------+-------+
-| DSP2 CMA       | 0x9f000000       | 8 MB  |
-+----------------+------------------+-------+
-| Default CMA    | 0xfe400000       | 24 MB |
-+----------------+------------------+-------+
-
-For details on how to adjust the sizes and locations of the DSP/IPU CMA
-carveouts, please see the corresponding section for changing the DSP or
-IPU memory map.
-
-To adjust the size of the "Default CMA" section, this is done as part of
-the Linux config:
-
-linux/arch/arm/configs/tisdk_am57xx-evm_defconfig
-
-::
-
-    #
-    # Default contiguous memory area size:
-    #
-    CONFIG_CMA_SIZE_MBYTES=24
-    CONFIG_CMA_SIZE_SEL_MBYTES=y
-
-|
-
-.. rubric:: CMEM
-   :name: cmem
-
-To view the allocation at run-time:
-
-::
-
-    root@am57xx-evm:~# cat /proc/cmem
-
-    Block 0: Pool 0: 1 bufs size 0xc000000 (0xc000000 requested)
-
-    Pool 0 busy bufs:
-
-    Pool 0 free bufs:
-    id 0: phys addr 0xa0000000
-
-This shows that we have defined a CMEM block at physical base address of
-0xA0000000 with total size 0xc000000 (192 MB). This block contains a
-buffer pool consisting of 1 buffer. Each buffer in the pool (only one in
-this case) is defined to have a size of 0xc000000 (192 MB).
-
-Here is where those sizes/addresses were defined for the AM57xx EVM:
-
-linux/arch/arm/boot/dts/am57xx-evm-cmem.dtsi
-
-::
-
-    {
-           reserved-memory {
-                   #address-cells = <2>;
-                   #size-cells = <2>;
-                   ranges;
-
-                   cmem_block_mem_0: cmem_block_mem@a0000000 {
-                           reg = <0x0 0xa0000000 0x0 0x0c000000>;
-                           no-map;
-                           status = "okay";
-                   };
-
-                   cmem_block_mem_1_ocmc3: cmem_block_mem@40500000 {
-                           reg = <0x0 0x40500000 0x0 0x100000>;
-                           no-map;
-                           status = "okay";
-                   };
-           };
-
-           cmem {
-                   compatible = "ti,cmem";
-                   #address-cells = <1>;
-                   #size-cells = <0>;
-
-                   #pool-size-cells = <2>;
-
-                   status = "okay";
-
-                   cmem_block_0: cmem_block@0 {
-                           reg = <0>;
-                           memory-region = <&cmem_block_mem_0>;
-                           cmem-buf-pools = <1 0x0 0x0c000000>;
-                   };
-
-                   cmem_block_1: cmem_block@1 {
-                           reg = <1>;
-                           memory-region = <&cmem_block_mem_1_ocmc3>;
-                   };
-           };
-    };
-
-|
-
-.. rubric:: Changing the DSP Memory Map
-   :name: changing-the-dsp-memory-map
-
-First, it is important to understand that there are a pair of Memory
-Management Units (MMUs) that sit between the DSP subsystems and the L3
-interconnect. One of these MMUs is for the DSP core and the other is for
-its local EDMA. They both serve the same purpose of translating virtual
-addresses (i.e. the addresses as viewed by the DSP subsystem) into
-physical addresses (i.e. addresses as viewed from the L3 interconnect).
-
-.. Image:: /images/LinuxIpcDspMmu.png
-
-.. rubric:: DSP Physical Addresses
-   :name: dsp-physical-addresses
-
-The physical location where the DSP code/data will actually reside is
-defined by the CMA carveout. To change this location, you must change
-the definition of the carveout. **The DSP carveouts are defined in the
-Linux dts file.** For example for the AM57xx EVM:
-
-|
-linux/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
-
-::
-
-	   {
-                   dsp1_cma_pool: dsp1_cma@99000000 {
-                           compatible = "shared-dma-pool";
-                           reg = <0x0 0x99000000 0x0 0x4000000>;
-                           reusable;
-                           status = "okay";
-                   };
-
-                   dsp2_cma_pool: dsp2_cma@9f000000 {
-                           compatible = "shared-dma-pool";
-                           reg = <0x0 0x9f000000 0x0 0x800000>;
-                           reusable;
-                           status = "okay";
-                   };
-           };
-
-|
-You are able to change both the size and location. **Be careful not to
-overlap any other carveouts!**
-
-.. note::
-   The **two** location entries for a given DSP must be
-   identical!
-
-|
-Additionally, when you change the carveout location, there is a
-corresponding change that must be made to the resource table. For
-starters, if you're making a memory change you will need a **custom**
-resource table. The resource table is a large structure that is the
-"bridge" between physical memory and virtual memory. This structure is
-utilized for configuring the MMUs that sit in front of the DSP
-subsystem. There is detailed information available in the article `IPC
-Resource customTable <index_Foundational_Components.html#resource-custom-table>`__.
-
-Once you've created your custom resource table, you must update the
-address of PHYS_MEM_IPC_VRING to be the same base address as your
-corresponding CMA.
-
-.. code-block:: c
-
-	#if defined (VAYU_DSP_1)
-	#define PHYS_MEM_IPC_VRING      0x99000000
-	#elif defined (VAYU_DSP_2)
-	#define PHYS_MEM_IPC_VRING      0x9F000000
-	#endif
-
-|
-
-.. note::
-   The PHYS_MEM_IPC_VRING definition from the resource
-   table must match the address of the associated CMA carveout!
-
-.. rubric:: DSP Virtual Addresses
-   :name: dsp-virtual-addresses
-
-These addresses are the ones seen by the DSP subsystem, i.e. these will
-be the addresses in your linker command files, etc.
-
-You must ensure that the sizes of your sections are consistent with the
-corresponding definitions in the resource table. You should create your
-own resource table in order to modify the memory map. This is describe
-in the wiki page `IPC Resource
-customTable <index_Foundational_Components.html#resource-custom-table>`__. You can look at an
-existing resource table inside IPC:
-
-ipc/packages/ti/ipc/remoteproc/rsc_table_vayu_dsp.h
-
-.. code-block:: c
-
-        {
-            TYPE_CARVEOUT,
-            DSP_MEM_TEXT, 0,
-            DSP_MEM_TEXT_SIZE, 0, 0, "DSP_MEM_TEXT",
-        },
-     
-        {
-            TYPE_CARVEOUT,
-            DSP_MEM_DATA, 0,
-            DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
-        },
-     
-        {
-            TYPE_CARVEOUT,
-            DSP_MEM_HEAP, 0,
-            DSP_MEM_HEAP_SIZE, 0, 0, "DSP_MEM_HEAP",
-        },
-     
-        {
-            TYPE_CARVEOUT,
-            DSP_MEM_IPC_DATA, 0,
-            DSP_MEM_IPC_DATA_SIZE, 0, 0, "DSP_MEM_IPC_DATA",
-        },
-     
-        {
-            TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:dsp",
-        },
-     
-     
-        {
-            TYPE_DEVMEM,
-            DSP_MEM_IPC_VRING, PHYS_MEM_IPC_VRING,
-            DSP_MEM_IPC_VRING_SIZE, 0, 0, "DSP_MEM_IPC_VRING",
-        },
-
-|
-
-Let's have a look at some of these to understand them better. For
-example:
-
-.. code-block:: c
-
-        {
-            TYPE_CARVEOUT,
-            DSP_MEM_TEXT, 0,
-            DSP_MEM_TEXT_SIZE, 0, 0, "DSP_MEM_TEXT",
-        },
-
-|
-
-Key points to note are:
-
-#. The "TYPE_CARVEOUT" indicates that the physical memory backing this
-   entry will come from the associated CMA pool.
-#. DSP_MEM_TEXT is a #define earlier in the code providing the address
-   for the code section. It is 0x95000000 by default. **This must
-   correspond to a section from your DSP linker command file, i.e.
-   EXT_CODE (or whatever name you choose to give it) must be linked to
-   the same address.**
-#. DSP_MEM_TEXT_SIZE is the size of the MMU pagetable entry being
-   created (1MB in this particular instance). **The actual amount of
-   linked code in the corresponding section of your executable must be
-   less than or equal to this size.**
-
-Let's take another:
-
-.. code-block:: c
-
-        {
-            TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:dsp",
-        },
-
-|
-
-Key points are:
-
-#. The "TYPE_TRACE" indicates this is for trace info.
-#. The TRACEBUFADDR is defined earlier in the file as
-   &ti_trace_SysMin_Module_State_0_outbuf__A. That corresponds to the
-   symbol used in TI-RTOS for the trace buffer.
-#. The "0x8000" is the size of the MMU mapping. The corresponding size
-   in the cfg file should be the same (or less). It looks like this:
-   ``SysMin.bufSize  = 0x8000;``
-
-Finally, let's look at a TYPE_DEVMEM example:
-
-.. code-block:: c
-
-        {
-            TYPE_DEVMEM,
-            DSP_PERIPHERAL_L4CFG, L4_PERIPHERAL_L4CFG,
-            SZ_16M, 0, 0, "DSP_PERIPHERAL_L4CFG",
-        },
-
-|
-
-Key points:
-
-#. The "TYPE_DEVMEM" indicates that we are making an MMU mapping, but
-   this *does not come from the CMA pool*. This is intended for mapping
-   peripherals, etc. that already exist in the device memory map.
-#. DSP_PERIPHERAL_L4CFG (0x4A000000) is the virtual address while
-   L4_PERIPHERAL_L4CFG (0x4A000000) is the physical address. **This is
-   an identity mapping, meaning that peripherals can be referenced by
-   the DSP using their physical address.**
-
-.. rubric:: DSP Access to Peripherals
-   :name: dsp-access-to-peripherals
-
-The default resource table creates the following mappings:
-
-+-----------------+------------------+-------+-------------------+
-| Virtual Address | Physical Address | Size  | Comment           |
-+=================+==================+=======+===================+
-| 0x4A000000      | 0x4A000000       | 16 MB | L4CFG + L4WKUP    |
-+-----------------+------------------+-------+-------------------+
-| 0x48000000      | 0x48000000       | 2 MB  | L4PER1            |
-+-----------------+------------------+-------+-------------------+
-| 0x48400000      | 0x48400000       | 4 MB  | L4PER2            |
-+-----------------+------------------+-------+-------------------+
-| 0x48800000      | 0x48800000       | 8 MB  | L4PER3            |
-+-----------------+------------------+-------+-------------------+
-| 0x54000000      | 0x54000000       | 16 MB | L3_INSTR + CT_TBR |
-+-----------------+------------------+-------+-------------------+
-| 0x4E000000      | 0x4E000000       | 1 MB  | DMM config        |
-+-----------------+------------------+-------+-------------------+
-
-In other words, the peripherals can be accessed at their physical
-addresses since we use an identity mapping.
-
-.. rubric:: Inspecting the DSP IOMMU Page Tables at Run-Time
-   :name: inspecting-the-dsp-iommu-page-tables-at-run-time
-
-You can dump the DSP IOMMU page tables with the following commands:
-
-+------+------+---------------------------------------------------------+
-| DSP  | MMU  | Command                                                 |
-+======+======+=========================================================+
-| DSP1 | MMU0 | cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable |
-+------+------+---------------------------------------------------------+
-| DSP1 | MMU1 | cat /sys/kernel/debug/omap_iommu/40d02000.mmu/pagetable |
-+------+------+---------------------------------------------------------+
-| DSP2 | MMU0 | cat /sys/kernel/debug/omap_iommu/41501000.mmu/pagetable |
-+------+------+---------------------------------------------------------+
-| DSP2 | MMU1 | cat /sys/kernel/debug/omap_iommu/41502000.mmu/pagetable |
-+------+------+---------------------------------------------------------+
-
-In general, MMU0 and MMU1 are being programmed identically so you really
-only need to take a look at one or the other to understand the mapping
-for a given DSP.
-
-For example:
-
-::
-
-    root@am57xx-evm:~# cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
-    L:      da:     pte:
-    --------------------------
-    1: 0x48000000 0x48000002
-    1: 0x48100000 0x48100002
-    1: 0x48400000 0x48400002
-    1: 0x48500000 0x48500002
-    1: 0x48600000 0x48600002
-    1: 0x48700000 0x48700002
-    1: 0x48800000 0x48800002
-    1: 0x48900000 0x48900002
-    1: 0x48a00000 0x48a00002
-    1: 0x48b00000 0x48b00002
-    1: 0x48c00000 0x48c00002
-    1: 0x48d00000 0x48d00002
-    1: 0x48e00000 0x48e00002
-    1: 0x48f00000 0x48f00002
-    1: 0x4a000000 0x4a040002
-    1: 0x4a100000 0x4a040002
-    1: 0x4a200000 0x4a040002
-    1: 0x4a300000 0x4a040002
-    1: 0x4a400000 0x4a040002
-    1: 0x4a500000 0x4a040002
-    1: 0x4a600000 0x4a040002
-    1: 0x4a700000 0x4a040002
-    1: 0x4a800000 0x4a040002
-    1: 0x4a900000 0x4a040002
-    1: 0x4aa00000 0x4a040002
-    1: 0x4ab00000 0x4a040002
-    1: 0x4ac00000 0x4a040002
-    1: 0x4ad00000 0x4a040002
-    1: 0x4ae00000 0x4a040002
-    1: 0x4af00000 0x4a040002
-
-The first column tells us whether the mapping is a Level 1 or Level 2
-descriptor. All the lines above are a first level descriptor, so we look
-at the associated format from the TRM:
-
-.. Image:: /images/LinuxIpcPageTableDescriptor1.png
-
-The "da" ("device address") column reflects the virtual address. It is
-*derived* from the index into the table, i.e. there does not exist a
-"da" register or field in the page table. Each MB of the address space
-maps to an entry in the table. The "da" column is displayed to make it
-easy to find the virtual address of interest.
-
-The "pte" ("page table entry") column can be decoded according to Table
-20-4 shown above. For example:
-
-::
-
-    1: 0x4a000000 0x4a040002
-
-The 0x4a040002 shows us that it is a Supersection with base address
-0x4A000000. This gives us a 16 MB memory page. Note the repeated entries
-afterward. That's a requirement of the MMU. Here's an excerpt from the
-TRM:
-
-.. note::
-   Supersection descriptors must be repeated 16 times,
-   because each descriptor in the first level translation table describes 1
-   MiB of memory. If an access points to a descriptor that is not
-   initialized, the MMU will behave in an unpredictable way.
-
-.. rubric:: Changing Cortex M4 IPU Memory Map
-   :name: changing-cortex-m4-ipu-memory-map
-
-In order to fully understand the memory mapping of the Cortex M4 IPU
-Subsystems, it's helpful to recognize that there are two
-distinct/independent levels of memory translation. Here's a snippet from
-the TRM to illustrate:
-
-.. Image:: /images/LinuxIpcIpuMmu.png
-
-.. rubric:: Cortex M4 IPU Physical Addresses
-   :name: cortex-m4-ipu-physical-addresses
-
-The physical location where the M4 code/data will actually reside is
-defined by the CMA carveout. To change this location, you must change
-the definition of the carveout. **The M4 carveouts are defined in the
-Linux dts file.** For example for the AM57xx EVM:
-
-linux/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
-
-::
-
-	{
-		ipu2_cma_pool: ipu2_cma@95800000 {
-			compatible = "shared-dma-pool";
-			reg = <0x0 95800000 0x0 0x3800000>;
-			reusable;
-			status = "okay";
-		};
-
-		ipu1_cma_pool: ipu1_cma@9d000000 {
-			compatible = "shared-dma-pool";
-			reg = <0x0 9d000000 0x0 0x2000000>;
-			reusable;
-			status = "okay";
-		};
-	};
-
-
-You are able to change both the size and location. **Be careful not to
-overlap any other carveouts!**
-
-.. note::
-   The **two** location entries for a given carveout
-   must be identical!
-
-Additionally, when you change the carveout location, there is a
-corresponding change that must be made to the resource table. For
-starters, if you're making a memory change you will need a **custom**
-resource table. The resource table is a large structure that is the
-"bridge" between physical memory and virtual memory. This structure is
-utilized for configuring the IPUx_MMU (not the Unicache MMU). There is
-detailed information available in the article `IPC Resource
-customTable <index_Foundational_Components.html#resource-custom-table>`__.
-
-Once you've created your custom resource table, you must update the
-address of PHYS_MEM_IPC_VRING to be the same base address as your
-corresponding CMA.
-
-::
-
-    #if defined(VAYU_IPU_1)
-    #define PHYS_MEM_IPC_VRING      0x9D000000
-    #elif defined (VAYU_IPU_2)
-    #define PHYS_MEM_IPC_VRING      0x95800000
-    #endif
-
-.. note::
-   The PHYS_MEM_IPC_VRING definition from the resource
-   table must match the address of the associated CMA carveout!
-
-.. rubric:: Cortex M4 IPU Virtual Addresses
-   :name: cortex-m4-ipu-virtual-addresses
-
-.. rubric:: Unicache MMU
-   :name: unicache-mmu
-
-The Unicache MMU sits closest to the Cortex M4. It provides the first
-level of address translation. The Unicache MMU is actually "self
-programmed" by the Cortex M4. The Unicache MMU is also referred to as
-the Attribute MMU (AMMU). There are a fixed number of small, medium and
-large pages. Here's a snippet showing some of the key mappings:
-
-ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/ipu1/IpuAmmu.cfg
-
-::
-
-    /*********************** Large Pages *************************/
-    /* Instruction Code: Large page  (512M); cacheable */
-    /* config large page[0] to map 512MB VA 0x0 to L3 0x0 */
-    AMMU.largePages[0].pageEnabled = AMMU.Enable_YES;
-    AMMU.largePages[0].logicalAddress = 0x0;
-    AMMU.largePages[0].translationEnabled = AMMU.Enable_NO;
-    AMMU.largePages[0].size = AMMU.Large_512M;
-    AMMU.largePages[0].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
-    AMMU.largePages[0].L1_posted = AMMU.PostedPolicy_POSTED;
-     
-    /* Peripheral regions: Large Page (512M); non-cacheable */
-    /* config large page[1] to map 512MB VA 0x60000000 to L3 0x60000000 */
-    AMMU.largePages[1].pageEnabled = AMMU.Enable_YES;
-    AMMU.largePages[1].logicalAddress = 0x60000000;
-    AMMU.largePages[1].translationEnabled = AMMU.Enable_NO;
-    AMMU.largePages[1].size = AMMU.Large_512M;
-    AMMU.largePages[1].L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
-    AMMU.largePages[1].L1_posted = AMMU.PostedPolicy_POSTED;
-     
-    /* Private, Shared and IPC Data regions: Large page (512M); cacheable */
-    /* config large page[2] to map 512MB VA 0x80000000 to L3 0x80000000 */
-    AMMU.largePages[2].pageEnabled = AMMU.Enable_YES;
-    AMMU.largePages[2].logicalAddress = 0x80000000;
-    AMMU.largePages[2].translationEnabled = AMMU.Enable_NO;
-    AMMU.largePages[2].size = AMMU.Large_512M;
-    AMMU.largePages[2].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
-    AMMU.largePages[2].L1_posted = AMMU.PostedPolicy_POSTED;
-
-
-+--------------+-----------------------+-----------------------+--------+-------------+
-| Page         | Cortex M4 Address     | Intermediate Address  | Size   | Comment     |
-+==============+=======================+=======================+========+=============+
-| Large Page 0 | 0x00000000-0x1fffffff | 0x00000000-0x1fffffff | 512 MB | Code        |
-+--------------+-----------------------+-----------------------+--------+-------------+
-| Large Page 1 | 0x60000000-0x7fffffff | 0x60000000-0x7fffffff | 512 MB | Peripherals |
-+--------------+-----------------------+-----------------------+--------+-------------+
-| Large Page 2 | 0x80000000-0x9fffffff | 0x80000000-0x9fffffff | 512 MB | Data        |
-+--------------+-----------------------+-----------------------+--------+-------------+
-
-These 3 pages are "identity" mappings, performing a passthrough of
-requests to the associated address ranges. These intermediate addresses
-get mapped to their physical addresses in the next level of translation
-(IOMMU).
-
-The AMMU ranges for code and data *need* to be identity mappings because
-otherwise the remoteproc loader wouldn't be able to match up the
-sections from the ELF file with the associated IOMMU mapping. These
-mappings should suffice for any application, i.e. no need to adjust
-these. The more likely area for modification is the resource table in
-the next section. The AMMU mappings are needed mainly to understand the
-full picture with respect to the Cortex M4 memory map.
-
-|
-
-.. rubric:: IOMMU
-   :name: iommu
-
-The IOMMU sits closest to the L3 interconnect. It takes the intermediate
-address output from the AMMU and translates it to the physical address
-used by the L3 interconnect. The IOMMU is programmed by the ARM based on
-the associated resource table. If you're planning any memory changes
-then you'll want to make a custom resource table as described in the
-wiki page `IPC Resource
-customTable <index_Foundational_Components.html#resource-custom-table>`__.
-
-The default resource table (which can be adapted to make a custom table)
-can be found at this location:
-
-ipc/packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h
-
-.. code-block:: c
-
-    #define IPU_MEM_TEXT            0x0
-    #define IPU_MEM_DATA            0x80000000
-     
-    #define IPU_MEM_IOBUFS          0x90000000
-     
-    #define IPU_MEM_IPC_DATA        0x9F000000
-    #define IPU_MEM_IPC_VRING       0x60000000
-    #define IPU_MEM_RPMSG_VRING0    0x60000000
-    #define IPU_MEM_RPMSG_VRING1    0x60004000
-    #define IPU_MEM_VRING_BUFS0     0x60040000
-    #define IPU_MEM_VRING_BUFS1     0x60080000
-     
-    #define IPU_MEM_IPC_VRING_SIZE  SZ_1M
-    #define IPU_MEM_IPC_DATA_SIZE   SZ_1M
-     
-    #if defined(VAYU_IPU_1)
-    #define IPU_MEM_TEXT_SIZE       (SZ_1M)
-    #elif defined(VAYU_IPU_2)
-    #define IPU_MEM_TEXT_SIZE       (SZ_1M * 6)
-    #endif
-     
-    #if defined(VAYU_IPU_1)
-    #define IPU_MEM_DATA_SIZE       (SZ_1M * 5)
-    #elif defined(VAYU_IPU_2)
-    #define IPU_MEM_DATA_SIZE       (SZ_1M * 48)
-    #endif
-
-|
-
-<snip...>
-
-.. code-block:: c
-
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_TEXT, 0,
-            IPU_MEM_TEXT_SIZE, 0, 0, "IPU_MEM_TEXT",
-        },
-     
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_DATA, 0,
-            IPU_MEM_DATA_SIZE, 0, 0, "IPU_MEM_DATA",
-        },
-     
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_IPC_DATA, 0,
-            IPU_MEM_IPC_DATA_SIZE, 0, 0, "IPU_MEM_IPC_DATA",
-        },
-
-
-The 3 entries above from the resource table all come from the associated
-IPU CMA pool (i.e. as dictated by the TYPE_CARVEOUT). The second
-parameter represents the virtual address (i.e. input address to the
-IOMMU). **These addresses must be consistent with both the AMMU mapping
-as well as the linker command file.** The ex02_messageq example from ipc
-defines these memory sections in the file
-examples/DRA7XX_linux_elf/ex02_messageq/shared/config.bld.
-
-You can dump the IPU IOMMU page tables with the following commands:
-
-+------+---------------------------------------------------------+
-| IPU  | Command                                                 |
-+======+=========================================================+
-| IPU1 | cat /sys/kernel/debug/omap_iommu/58882000.mmu/pagetable |
-+------+---------------------------------------------------------+
-| IPU2 | cat /sys/kernel/debug/omap_iommu/55082000.mmu/pagetable |
-+------+---------------------------------------------------------+
-
-Please see the `corresponding DSP
-documentation </index.php/Linux_IPC_on_AM57xx#Inspecting_the_DSP_IOMMU_Page_Tables_at_Run-Time>`__
-for more details on interpreting the output.
-
-|
-
-.. rubric:: Cortex M4 IPU Access to Peripherals
-   :name: cortex-m4-ipu-access-to-peripherals
-
-The default resource table creates the following mappings:
-
-+-------------+-------------+-------------+-------------+-------------+
-| Virtual     | Address at  | Address at  | Size        | Comment     |
-| Address     | output of   | output of   |             |             |
-| used by     | Unicache    | IOMMU       |             |             |
-| Cortex M4   | MMU         |             |             |             |
-+=============+=============+=============+=============+=============+
-| 0x6A000000  | 0x6A000000  | 0x4A000000  | 16 MB       | L4CFG +     |
-|             |             |             |             | L4WKUP      |
-+-------------+-------------+-------------+-------------+-------------+
-| 0x68000000  | 0x68000000  | 0x48000000  | 2 MB        | L4PER1      |
-+-------------+-------------+-------------+-------------+-------------+
-| 0x68400000  | 0x68400000  | 0x48400000  | 4 MB        | L4PER2      |
-+-------------+-------------+-------------+-------------+-------------+
-| 0x68800000  | 0x68800000  | 0x48800000  | 8 MB        | L4PER3      |
-+-------------+-------------+-------------+-------------+-------------+
-| 0x74000000  | 0x74000000  | 0x54000000  | 16 MB       | L3_INSTR +  |
-|             |             |             |             | CT_TBR      |
-+-------------+-------------+-------------+-------------+-------------+
-
-Example: Accessing UART5 from IPU
-
-#. For this example, it's assumed the pin-muxing was already setup in
-   the bootloader. If that's not the case, you would need to do that
-   here.
-#. The UART5 module needs to be enabled via the CM_L4PER_UART5_CLKCTRL
-   register. This is located at physical address 0x4A009870. So from the
-   M4 we would program this register at virtual address 0x6A009870.
-   Writing a value of 2 to this register will enable the peripheral.
-#. After completing the previous step, the UART5 registers will become
-   accessible. Normally UART5 is accessible at physical base address
-   0x48066000. This would correspondingly be accessed from the IPU at
-   0x68066000.
-
-Power Management
-^^^^^^^^^^^^^^^^
-
-The IPUs and DSPs auto-idle by default. This can prevent you from being
-able to connect to the device using JTAG or from accessing local memory
-via devmem2. There are some options sprinkled throughout sysfs that are
-needed in order to force these subsystems on, as is sometimes needed for
-development and debug purposes.
-
-There are some hard-coded device names that originate in the device tree
-(dra7.dtsi) that are needed for these operations:
-
-+-------------+-------------------------+----------------+
-| Remote Core | Definition in dra7.dtsi | System FS Name |
-+=============+=========================+================+
-| IPU1        | ipu@58820000            | 58820000.ipu   |
-+-------------+-------------------------+----------------+
-| IPU2        | ipu@55020000            | 55020000.ipu   |
-+-------------+-------------------------+----------------+
-| DSP1        | dsp@40800000            | 40800000.dsp   |
-+-------------+-------------------------+----------------+
-| DSP2        | dsp@41000000            | 41000000.dsp   |
-+-------------+-------------------------+----------------+
-| ICSS1-PRU0  | pru@4b234000            | 4b234000.pru0  |
-+-------------+-------------------------+----------------+
-| ICSS1-PRU1  | pru@4b238000            | 4b238000.pru1  |
-+-------------+-------------------------+----------------+
-| ICSS2-PRU0  | pru@4b2b4000            | 4b2b4000.pru0  |
-+-------------+-------------------------+----------------+
-| ICSS2-PRU1  | pru@4b2b8000            | 4b2b8000.pru1  |
-+-------------+-------------------------+----------------+
-
-To map these System FS names to the associated remoteproc entry, you can
-run the following commands:
-
-::
-
-    root@am57xx-evm:~# ls -l /sys/kernel/debug/remoteproc/
-    root@am57xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc*/name
-
-The results of the commands will be a one-to-one mapping. For example,
-58820000.ipu corresponds with remoteproc0.
-
-Similarly, to see the power state of each of the cores:
-
-::
-
-    root@am57xx-evm:~# cat /sys/class/remoteproc/remoteproc*/state
-
-The state can be suspended, running, offline, etc. You can only attach
-JTAG if the state is "running". If it shows as "suspended" then you must
-force it to run. For example, let's say DSP0 is "suspended". You can run
-the following command to force it on:
-
-::
-
-    root@am57xx-evm:~# echo on > /sys/bus/platform/devices/40800000.dsp/power/control
-
-The same is true for any of the cores, but replace 40800000.dsp with the
-associated System FS name from the chart above.
-
-Adding IPC to an Existing TI-RTOS Application on slave cores
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: Adding IPC to an existing TI RTOS application on the DSP
-   :name: adding-ipc-to-an-existing-ti-rtos-application-on-the-dsp
-
-|
-A common thing people want to do is take an existing DSP application
-and add IPC to it. This is common when migrating from a DSP only
-solution to a heterogeneous SoC with an Arm plus a DSP. This is the
-focus of this section.
-
-|
-In order to describe this process, we need an example test case to
-work with. For this purpose, we'll be using the
-GPIO_LedBlink_evmAM572x_c66xExampleProject example that's part of the
-PDK (installed as part of the Processor SDK RTOS). You can find it at
-c:/ti/pdk_am57xx_1_0_4/packages/MyExampleProjects/GPIO_LedBlink_evmAM572x_c66xExampleProject.
-This example uses SYS/BIOS and blinks the USER0 LED on the AM572x GP
-EVM, it's labeled D4 on the EVM silkscreen just to the right of the
-blue reset button.
-
-|
-
-There were several steps taken to make this whole process work, each of
-which will be described in following sections
-
-#. Build and run the out-of-box LED blink example on the EVM using Code
-   Composer Studio (CCS)
-#. Take the ex02_message example from the IPC software bundle and turn
-   it into a CCS project. Build it and modify the Linux startup code to
-   use this new image. This is just a sanity check step to make sure we
-   can build the IPC examples in CCS and have them run at boot up on the
-   EVM.
-#. In CCS, make a clone of the out-of-box LED example and rename it to
-   denote it's the IPC version of the example. Then using the
-   ex02_messageq example as a reference, add in the IPC pieces to the
-   LED example. Build from CCS then add it to the Linux firmware folder.
-
-|
-
-.. rubric:: Add IPC to the LED Blink Example
-   :name: add-ipc-to-the-led-blink-example
-
-The first step is to clone our out-of-box LED blink CCS project and
-rename it to denote it's using IPC. The easiest way to do this is using
-CCS. Here are the steps...
-
--  In the *Edit* perspective, go into your *Project Explorer* window and
-   right click on your GPIO_LedBlink_evmAM572x+c66xExampleProject
-   project and select *copy* from the pop-up menu. Maske sure the
-   project is not is a closed state.
--  Rick click in and empty area of the project explorer window and
-   select past.
--  A dialog box pops up, modify the name to denote it's using IPC. A
-   good name is GPIO_LedBlink_evmAM572x+c66xExampleProjec_with_ipc.
-
-|
-
-This is the project we'll be working with from here on. The next thing
-we want to do is select the proper RTSC platform and other components.
-To do this, follow these steps.
-
--  Right click on the GPIO_LedBlink_evmAM572x+c66xExampleProjec_with_ipc
-   project and select *Properties*
--  In the left hand pane, click on *CCS General*.
--  On the right hand side, click on the *RTSC* tab
--  For *XDCtools version:* select 3.32.0.06_core
--  In the list of *Products and Repositories*, *check* the following...
-
-   -  IPC 3.43.2.04
-   -  SYS/BIOS 6.45.1.29
-   -  am57xx PDK 1.0.4
-
--  For *Target*, select ti.targets.elf.C66
--  For *Platform*, select ti.platforms.evmDRA7XX
--  Once the platform is selected, edit its name buy hand and
-   append :dsp1 to the end. After this it should be
-   ti.platforms.evmDRA7XX:dsp1
--  Go ahead and leave the *Build-profile* set to debug.
--  Hit the OK button.
-
-|
-Now we want to copy configuration and source files from the
-ex02_messageq IPC example into our project. The IPC example is located
-at *C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq*. To
-copy files into your CCS project, you can simply select the files you
-want in Windows explorer then drag and drop them into your project in
-CCS.
-
-Copy these files into your CCS project...
-
--  C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/shared/AppCommon.h
--  C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/shared/config.bld
--  C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/shared/ipc.cfg.xs
-
-|
-Now copy these files into your CCS project...
-
--  C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/Dsp1.cfg
--  C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/MainDsp1.c
--  C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/Server.c
--  C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/Server.h
-
-.. note::
-   When you copy Dsp1.cfg into your CCS project, it
-   should show up greyed out. This is because the LED blink example
-   already has a cfg file (gpio_test_evmAM572x.cfg). The Dsp1.cfg will be
-   used for copying and pasting. When it's all done, you can delete it
-   from your project.
-
-Finally, you will likely want to use a custom resource table so copy
-these files into your CCS project...
-
--  C:/ti/ipc_3_43_02_04/packages/ti/ipc/remoteproc/rsc_table_vayu_dsp.h
--  C:/ti/ipc_3_43_02_04/packages/ti/ipc/remoteproc/rsc_types.h
-
-The rsc_table_vayu_dsp.h file defines an initialized structure so let's
-make a *.c* source file.
-
--  In your CCS project, rename rsc_table_vayu_dsp.h to
-   rsc_table_vayu_dsp.c
-
-|
-| Now we want to *merge* the IPC example configuration file with the LED
-  blink example configuration file. Follow these steps...
-
--  Open up *Dsp1.cfg* using a text editor (don't open it using the GUI).
-   Right click on it and select *Open With -> XDCscript Editor*
--  We want to copy the entire contents into the clipboard. Select all
-   and copy.
--  Now just like above, open the gpio_test_evmAM572x.cfg config file in
-   the text editor. Go to the very bottom and *paste* in the contents
-   from the Dsp1.cfg file. Basically we've appended the contents of
-   Dsp1.cfg into gpio_test_evmAM572x.cfg.
-
-|
-We've now added in all the necessary configuration and source files
-into our project. Don't expect it to build at this point, we have to
-make edits first. These edits are listed below.
-
-.. note::
-   You can download the full CCS project with source files to use as a reference.
-   See link towards the end of this section.
-
--  Edit **gpio_test_evmAM572x.cfg**
-
-|
-Add the following to the beginning of your configuration file
-
-.. code-block:: javascript
-
-    var Program = xdc.useModule('xdc.cfg.Program');
-
-
-Comment out the Memory sections configuration as shown below
-
-.. code-block:: javascript
-
-    /* ================ Memory sections configuration ================ */
-    //Program.sectMap[".text"] = "EXT_RAM";
-    //Program.sectMap[".const"] = "EXT_RAM";
-    //Program.sectMap[".plt"] = "EXT_RAM";
-    /* Program.sectMap["BOARD_IO_DELAY_DATA"] = "OCMC_RAM1"; */
-    /* Program.sectMap["BOARD_IO_DELAY_CODE"] = "OCMC_RAM1"; */
-
-|
-
-Since we are no longer using a shared folder, make the following change
-
-.. code-block:: javascript
-
-    //var ipc_cfg = xdc.loadCapsule("../shared/ipc.cfg.xs");
-    var ipc_cfg = xdc.loadCapsule("../ipc.cfg.xs");
-
-|
-
-Comment out the following. We'll be calling this function directly from
-main.
-
-.. code-block:: javascript
-
-    //BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');
-
-|
-
-Increase the system stack size
-
-.. code-block:: javascript
-
-    //Program.stack = 0x1000;
-    Program.stack = 0x8000;
-
-|
-
-Comment out the entire TICK section
-
-.. code-block:: javascript
-
-    /* --------------------------- TICK --------------------------------------*/
-    // var Clock = xdc.useModule('ti.sysbios.knl.Clock');
-    // Clock.tickSource = Clock.TickSource_NULL;
-    // //Clock.tickSource = Clock.TickSource_USER;
-    // /* Configure BIOS clock source as GPTimer5 */
-    // //Clock.timerId = 0;
-    //
-    // var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
-    //
-    // /* Skip the Timer frequency verification check. Need to remove this later */
-    // Timer.checkFrequency = false;
-    //
-    // /* Match this to the SYS_CLK frequency sourcing the dmTimers.
-    //  * Not needed once the SYS/BIOS family settings is updated. */
-    // Timer.intFreq.hi = 0;
-    // Timer.intFreq.lo = 19200000;
-    //
-    // //var timerParams = new Timer.Params();
-    // //timerParams.period = Clock.tickPeriod;
-    // //timerParams.periodType = Timer.PeriodType_MICROSECS;
-    // /* Switch off Software Reset to make the below settings effective */
-    // //timerParams.tiocpCfg.softreset = 0x0;
-    // /* Smart-idle wake-up-capable mode */
-    // //timerParams.tiocpCfg.idlemode = 0x3;
-    // /* Wake-up generation for Overflow */
-    // //timerParams.twer.ovf_wup_ena = 0x1;
-    // //Timer.create(Clock.timerId, Clock.doTick, timerParams);
-    //
-    // var Idle = xdc.useModule('ti.sysbios.knl.Idle');
-    // var Deh = xdc.useModule('ti.deh.Deh');
-    //
-    // /* Must be placed before pwr mgmt */
-    // Idle.addFunc('&ti_deh_Deh_idleBegin');
-
-|
-
-Make configuration change to use custom resource table. Add to the end
-of the file.
-
-.. code-block:: javascript
-
-    /* Override the default resource table with my own */
-    var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
-    Resource.customTable = true;
-
-|
-
-|
--  Edit **main_led_blink.c**
-
-|
-
-Add the following external declarations
-
-.. code-block:: c
-
-    extern Int ipc_main();
-    extern Void IpcMgr_ipcStartup(Void);
-
-|
-
-In main(), add a call to ipc_main() and IpcMgr_ipcStartup() just before
-BIOS_start()
-
-.. code-block:: c
-
-        ipc_main();
-     
-        if (callIpcStartup) {
-            IpcMgr_ipcStartup();
-        }
-     
-        /* Start BIOS */
-        BIOS_start();
-        return (0);
-
-|
-
-Comment out the line that calls Board_init(boardCfg). This call is in
-the original example because it assumes TI-RTOS is running on the Arm
-but in our case here, we are running Linux and this call is
-destructive so we comment it out.
-
-.. code-block:: c
-
-	    #if defined(EVM_K2E) || defined(EVM_C6678)
-		boardCfg = BOARD_INIT_MODULE_CLOCK |
-		BOARD_INIT_UART_STDIO;
-	    #else
-		boardCfg = BOARD_INIT_PINMUX_CONFIG |
-		BOARD_INIT_MODULE_CLOCK |
-		BOARD_INIT_UART_STDIO;
-	    #endif
-		//Board_init(boardCfg);
-
-|
-
-|
-
--  Edit **MainDsp1.c**
-
-|
-
-The app now has it's own main(), so rename this one and get rid of args
-
-.. code-block:: c
-
-    //Int main(Int argc, Char* argv[])
-    Int ipc_main()
-    {
-
-|
-
-No longer using args so comment these lines
-
-::
-
-        //taskParams.arg0 = (UArg)argc;
-        //taskParams.arg1 = (UArg)argv;
-|
-
-
-BIOS_start() is done in the app main() so comment it out here
-
-::
-
-        /* start scheduler, this never returns */
-        //BIOS_start();
-|
-
-
-Comment this out
-
-::
-
-        //Log_print0(Diags_EXIT, "<-- main:");
-|
-
--  Edit **rsc_table_vayu_dsp.c**
-
-|
-
-Set this #define before it's used to select PHYS_MEM_IPC_VRING value
-
-::
-
-    #define VAYU_DSP_1
-|
-
-Add this extern declaration prior to the symbol being used
-
-::
-
-	extern char ti_trace_SysMin_Module_State_0_outbuf__A;
-|
-
--  Edit **Server.c**
-
-|
-
-|
-No longer have shared folder so change include path
-
-::
-
-    /* local header files */
-    //#include "../shared/AppCommon.h"
-    #include "../AppCommon.h"
-
-|
-
-.. rubric:: Download the Full CCS Project
-   :name: download-the-full-ccs-project
-
-|
-`GPIO_LedBlink_evmAM572x_c66xExampleProject_with_ipc.zip <http://processors.wiki.ti.com/images/c/c9/GPIO_LedBlink_evmAM572x_c66xExampleProject_with_ipc.zip>`__
-
-.. rubric:: Adding IPC to an existing TI RTOS application on the IPU
-   :name: adding-ipc-to-an-existing-ti-rtos-application-on-the-ipu
-
-|
-A common thing people want to do is take an existing IPU application
-that may be controlling serial or control interfaces and add IPC to it
-so that the firmware can be loaded from the ARM. This is common when
-migrating from a IPU only solution to a heterogeneous SoC with an
-MPUSS (ARM) and IPUSS. This is the focus of this section.
-
-|
-In order to describe this process, we need an example TI RTOS test
-case to work with. For this purpose, we'll be using the
-UART_BasicExample_evmAM572x_m4ExampleProject example that's part of
-the PDK (installed as part of the Processor SDK RTOS). This example
-uses TI RTOS and does serial IO using UART3 port on the AM572x GP EVM,
-it's labeled Serial Debug on the EVM silkscreen.
-
-|
-
-There were several steps taken to make this whole process work, each of
-which will be described in following sections
-
-#. Build and run the out-of-box UART M4 example on the EVM using Code
-   Composer Studio (CCS)
-#. Build and run the ex02_messageQ example from the IPC software bundle
-   and turn it into a CCS project. Build it and modify the Linux startup
-   code to use this new image. This is just a sanity check step to make
-   sure we can build the IPC examples in CCS and have them run at boot
-   up on the EVM.
-#. In CCS, make a clone of the out-of-box UART M4 example and rename it
-   to denote it's the IPC version of the example. Then using the
-   ex02_messageq example as a reference, add in the IPC pieces to the
-   UART example code. Build from CCS then add it to the Linux firmware
-   folder.
-
-.. rubric:: Running UART Read/Write PDK Example from CCS
-   :name: running-uart-readwrite-pdk-example-from-ccs
-
-Developers are required to run pdkProjectCreate script to generate this
-example as described in the `Processor SDK RTOS wiki
-article <index_how_to_guides.html#rebuild-drivers-from-pdk-directory>`__.
-
-For the UART M4 example run the script with the following arguments:
-
-::
-
-    pdkProjectCreate.bat AM572x evmAM572x little uart m4
-
-|
-|
-After you run the script, you can find the UART M4 example project at
-<SDK_INSTALL_PATH>/pdk_am57xx_1_0_4/packages/MyExampleProjects/UART_BasicExample_evmAM572x_m4ExampleProject.
-
-Import the project in CCS and build the example. You can now connect to
-the EVM using an emulator and CCS using the instructions provided here:
-http://processors.wiki.ti.com/index.php/AM572x_GP_EVM_Hardware_Setup
-
-Connect to the ARM core and make sure GEL runs multicore initialization
-and brings the IPUSS out of reset. Connect to IPU2 core0 and load and
-run the M4 UART example. When you run the code you should see the
-following log on the serial IO console:
-
-::
-
-    uart driver and utils example test cases :
-    Enter 16 characters or press Esc
-    1234567890123456  <- user input
-    Data received is
-    1234567890123456  <- loopback from user input
-    uart driver and utils example test cases :
-    Enter 16 characters or press Esc
-
-|
-
-|
-
-.. rubric:: Build and Run ex02_messageq IPC example
-   :name: build-and-run-ex02_messageq-ipc-example
-
-Follow instructions described in Article `Run IPC Linux
-Examples <http://processors.wiki.ti.com/index.php/Processor_SDK_IPC_Quick_Start_Guide#Run_IPC_Linux_examples>`__
-
-.. rubric:: Update Linux Kernel device tree to remove UART that will be
-   controlled by M4
-   :name: update-linux-kernel-device-tree-to-remove-uart-that-will-be-controlled-by-m4
-
-Linux kernel enables all SOC HW modules which are required for its
-configuration. Appropriate drivers configure required clocks and
-initialize HW registers. For all unused IPs clocks are not configured.
-
-The uart3 node is disabled in kernel using device tree. Also this
-restricts kernel to put those IPs to sleep mode.
-
-::
-
-    &uart3 {
-        status = "disabled";
-        ti,no-idle;
-    };
-
-.. rubric:: Add IPC to the UART Example
-   :name: add-ipc-to-the-uart-example
-
-The first step is to clone our out-of-box UART example CCS project and
-rename it to denote it's using IPC. The easiest way to do this is using
-CCS. Here are the steps...
-
--  In the *Edit* perspective, go into your *Project Explorer* window and
-   right click on your UART_BasicExample_evmAM572x_m4ExampleProject
-   project and select *copy* from the pop-up menu. Maske sure the
-   project is not is a closed state.
--  Rick click in and empty area of the project explorer window and
-   select past.
--  A dialog box pops up, modify the name to denote it's using IPC. A
-   good name is UART_BasicExample_evmAM572x_m4ExampleProject_with_ipc.
-
-|
-
-This is the project we'll be working with from here on. The next thing
-we want to do is select the proper RTSC platform and other components.
-To do this, follow these steps.
-
--  Right click on the
-   UART_BasicExample_evmAM572x_m4ExampleProject_with_ipc project and
-   select *Properties*
--  In the left hand pane, click on *CCS General*.
--  On the right hand side, click on the *RTSC* tab
--  For *XDCtools version:* select 3.xx.x.xx_core
--  In the list of *Products and Repositories*, *check* the following...
-
-   -  IPC 3.xx.x.xx
-   -  SYS/BIOS 6.4x.x.xx
-   -  am57xx PDK x.x.x
-
--  For *Target*, select **ti.targets.arm.elf.M4**
--  For *Platform*, select **ti.platforms.evmDRA7XX**
--  Once the platform is selected, edit its name buy hand and
-   append :ipu2 to the end. After this it should be
-   ti.platforms.evmDRA7XX:ipu2
--  Go ahead and leave the *Build-profile* set to debug.
--  Hit the OK button.
-
-|
-
-Now we want to copy configuration and source files from the
-ex02_messageq IPC example into our project. The IPC example is located
-at *C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq*. To
-copy files into your CCS project, you can simply select the files you
-want in Windows explorer then drag and drop them into your project in
-CCS.
-
-Copy these files into your CCS project...
-
--  C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/shared/AppCommon.h
--  C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/shared/config.bld
--  C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/shared/ipc.cfg.xs
-
-|
-Now copy these files into your CCS project...
-
--  C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/Ipu2.cfg
--  C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/MainIpu2.c
--  C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/Server.c
--  C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/Server.h
-
-.. note::
-   When you copy Ipu2.cfg into your CCS project, it
-   should show up greyed out. If not, right click and exclude it from
-   build. This is because the UART example already has a cfg file
-   (uart_m4_evmAM572x.cfg). The Ipu2.cfg will be used for copying and
-   pasting. When it's all done, you can delete it from your project.
-
-Finally, you will likely want to use a custom resource table so copy
-these files into your CCS project...
-
--  C:/ti/ipc_3_xx_xx_xx/packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h
--  C:/ti/ipc_3_xx_xx_xx/packages/ti/ipc/remoteproc/rsc_types.h
-
-The rsc_table_vayu_dsp.h file defines an initialized structure so let's
-make a *.c* source file.
-
--  In your CCS project, rename rsc_table_vayu_ipu.h to
-   rsc_table_vayu_ipu.c
-
-|
-
-Now we want to *merge* the IPC example configuration file with the LED
-blink example configuration file. Follow these steps...
-
--  Open up *Ipu2.cfg* using a text editor (don't open it using the GUI).
-   Right click on it and select *Open With -> XDCscript Editor*
--  We want to copy the entire contents into the clipboard. Select all
-   and copy.
--  Now just like above, open the uart_m4_evmAM572x.cfg config file in
-   the text editor. Go to the very bottom and *paste* in the contents
-   from the Ipu2.cfg file. Basically we've appended the contents of
-   Ipu2.cfg into uart_m4_evmAM572x.cfg.
-
-|
-
-We've now added in all the necessary configuration and source files
-into our project. Don't expect it to build at this point, we have to
-make edits first. These edits are listed below.
-
-.. note::
-   You can download the full CCS project with source files to use as a reference.
-   See link towards the end of this section.
-
--  Edit **uart_m4_evmAM572x.cfg**
-
-|
-Add the following to the beginning(at the top) of your configuration
-file
-
-::
-
-    var Program = xdc.useModule('xdc.cfg.Program');
-
-|
-
-|
-Since we are no longer using a shared folder, make the following
-change
-
-::
-
-    //var ipc_cfg = xdc.loadCapsule("../shared/ipc.cfg.xs");
-    var ipc_cfg = xdc.loadCapsule("../ipc.cfg.xs");
-
-|
-
-Comment out the following. We'll be calling this function directly from
-main.
-
-::
-
-    //BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');
-
-|
-
-Increase the system stack size
-
-::
-
-    //Program.stack = 0x1000;
-    Program.stack = 0x8000;
-
-|
-
-Comment out the entire TICK section
-
-::
-
-    /* --------------------------- TICK --------------------------------------*/
-    // var Clock = xdc.useModule('ti.sysbios.knl.Clock');
-    // Clock.tickSource = Clock.TickSource_NULL;
-    // //Clock.tickSource = Clock.TickSource_USER;
-    // /* Configure BIOS clock source as GPTimer5 */
-    // //Clock.timerId = 0;
-    //
-    // var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
-    //
-    // /* Skip the Timer frequency verification check. Need to remove this later */
-    // Timer.checkFrequency = false;
-    //
-    // /* Match this to the SYS_CLK frequency sourcing the dmTimers.
-    //  * Not needed once the SYS/BIOS family settings is updated. */
-    // Timer.intFreq.hi = 0;
-    // Timer.intFreq.lo = 19200000;
-    //
-    // //var timerParams = new Timer.Params();
-    // //timerParams.period = Clock.tickPeriod;
-    // //timerParams.periodType = Timer.PeriodType_MICROSECS;
-    // /* Switch off Software Reset to make the below settings effective */
-    // //timerParams.tiocpCfg.softreset = 0x0;
-    // /* Smart-idle wake-up-capable mode */
-    // //timerParams.tiocpCfg.idlemode = 0x3;
-    // /* Wake-up generation for Overflow */
-    // //timerParams.twer.ovf_wup_ena = 0x1;
-    // //Timer.create(Clock.timerId, Clock.doTick, timerParams);
-    //
-    // var Idle = xdc.useModule('ti.sysbios.knl.Idle');
-    // var Deh = xdc.useModule('ti.deh.Deh');
-    //
-    // /* Must be placed before pwr mgmt */
-    // Idle.addFunc('&ti_deh_Deh_idleBegin');
-
-|
-
-Make configuration change to use custom resource table. Add to the end
-of the file.
-
-::
-
-    /* Override the default resource table with my own */
-    var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
-    Resource.customTable = true;
-
-|
-
-|
-
--  Edit **main_uart_example.c**
-
-|
-
-Add the following external declarations
-
-::
-
-    extern Int ipc_main();
-    extern Void IpcMgr_ipcStartup(Void);
-
-|
-
-In main(), add a call to ipc_main() and IpcMgr_ipcStartup() just before
-BIOS_start()
-
-.. code-block:: c
-
-    ipc_main();
-    if (callIpcStartup) {
-       IpcMgr_ipcStartup();
-     }
-     /* Start BIOS */
-     BIOS_start();
-     return (0);
-
-|
-
-Comment out the line that calls Board_init(boardCfg). This call is in
-the original example because it assumes TI-RTOS is running on the Arm
-but in our case here, we are running Linux and this call is destructive
-so we comment it out. The board init call does all pinmux configuration,
-module clock and UART peripheral initialization.
-
-In order to run the UART Example on M4, you need to disable the UART in
-the Linux DTB file and interact with the Linux kernel using Telnet (This
-will be described later in the article). Since Linux will be running
-uboot performs the pinmux configuration but clock and UART Stdio setup
-needs to be performed by the M4.
-
-|
-**Original code**
-
-.. code-block:: c
-
-    #if defined(EVM_K2E) || defined(EVM_C6678)
-        boardCfg = BOARD_INIT_MODULE_CLOCK | BOARD_INIT_UART_STDIO;
-    #else
-        boardCfg = BOARD_INIT_PINMUX_CONFIG | BOARD_INIT_MODULE_CLOCK | BOARD_INIT_UART_STDIO;
-    #endif
-        Board_init(boardCfg);
-
-|
-
-|
-**Modified Code :**
-
-.. code-block:: c
-
-           boardCfg = BOARD_INIT_UART_STDIO;
-	   Board_init(boardCfg);
-
-|
-
-We are not done yet as we still need to configure turn the clock control
-on for the UART without impacting the other clocks. We can do that by
-adding the following code before Board_init API call:
-
-::
-
-       CSL_l4per_cm_core_componentRegs *l4PerCmReg =
-           (CSL_l4per_cm_core_componentRegs *)CSL_MPU_L4PER_CM_CORE_REGS;
-       CSL_FINST(l4PerCmReg->CM_L4PER_UART3_CLKCTRL_REG,
-           L4PER_CM_CORE_COMPONENT_CM_L4PER_UART3_CLKCTRL_REG_MODULEMODE, ENABLE);
-       while(CSL_L4PER_CM_CORE_COMPONENT_CM_L4PER_UART3_CLKCTRL_REG_IDLEST_FUNC !=
-          CSL_FEXT(l4PerCmReg->CM_L4PER_UART3_CLKCTRL_REG,
-           L4PER_CM_CORE_COMPONENT_CM_L4PER_UART3_CLKCTRL_REG_IDLEST));
-
--  Edit **MainIpu2.c**
-
-|
-
-The app now has it's own main(), so rename this one and get rid of args
-
-.. code-block:: c
-
-    //Int main(Int argc, Char* argv[])
-    Int ipc_main()
-    {
-
-No longer using args so comment these lines
-
-::
-
-       //taskParams.arg0 = (UArg)argc;
-       //taskParams.arg1 = (UArg)argv;
-
-BIOS_start() is done in the app main() so comment it out here
-
-::
-
-    /* start scheduler, this never returns */
-    //BIOS_start();
-
-|
-
-Comment this out
-
-::
-
-       //Log_print0(Diags_EXIT, "<-- main:");
-
-|
-
--  Edit **rsc_table_vayu_ipu.c**
-
-|
-
-Set this #define before it's used to select PHYS_MEM_IPC_VRING value
-
-::
-
-    #define VAYU_IPU_2
-
-|
-
-Add this extern declaration prior to the symbol being used
-
-::
-
-    extern char ti_trace_SysMin_Module_State_0_outbuf__A;
-
-|
-
-|
-
--  Edit **Server.c**
-
-|
-
-No longer have shared folder so change include path
-
-::
-
-    /* local header files */
-    //#include "../shared/AppCommon.h"
-    #include "../AppCommon.h"
-
-|
-
-.. rubric:: Handling AMMU (L1 Unicache MMU) and L2 MMU
-   :name: handling-ammu-l1-unicache-mmu-and-l2-mmu
-
-There are two MMUs inside each of the IPU1, and IPU2 subsystems. The L1
-MMU is referred to as IPU_UNICACHE_MMU or AMMU and L2 MMU. The
-description of how this is configured in IPC-remoteproc has been
-described in section
-`Changing_Cortex_M4_IPU_Memory_Map <http://processors.wiki.ti.com/index.php/Linux_IPC_on_AM57xx#Changing_Cortex_M4_IPU_Memory_Map>`__.
-IPC handling of L1 and L2 MMU is different from how the PDK driver
-examples setup the memory access using these MMUs which the users need
-to manage when integrating the components. This difference is
-highlighted below:
-
-.. Image:: /images/IPU_MMU_Peripheral_access.png
-
--  PDK examples use addresses (0x4X000000) to peripheral registers and
-   use following MMU setting
-
-   -  L2 MMU uses default 1:1 Mapping
-   -  AMMU configuration translates physical 0x4X000000 access to
-      logical 0x4X000000
-
--  IPC+ Remote Proc ARM+M4 requires IPU to use logical address
-   (0x6X000000) and uses following MMU setting
-
-   -  L2 MMU is configured such that MMU translates 0x6X000000 access to
-      addresss 0x4X000000
-   -  AMMU is configured for 1:1 mapping 0x6X000000 and 0x6X000000
-
-Therefore after integrating IPC with PDK drivers, it is recommended that
-the alias addresses are used to access peripherals and PRCM registers.
-This requires changes to the addresses used by PDK drivers and in
-application code.
-
-The following changes were then made to the IPU application source code:
-
-Add UART_soc.c file to the project and modify the base addresses for all
-IPU UART register instance in the UART_HwAttrs to use alias addresses:
-
-.. code-block:: c
-
-    #ifdef _TMS320C6X
-        CSL_DSP_UART3_REGS,
-        OSAL_REGINT_INTVEC_EVENT_COMBINER,
-    #elif defined(__ARM_ARCH_7A__)
-        CSL_MPU_UART3_REGS,
-        106,
-    #else
-        (CSL_IPU_UART3_REGS + 0x20000000),    //Base Addr = 0x48000000 + 0x20000000 = 0x68000000
-        45,
-    #endif
-
-Adding custom SOC configuration also means that you should use the
-generic UART driver instead of driver with built in SOC setup. To do
-this comment the following line in .cfg:
-
-::
-
-    var Uart              = xdc.loadPackage('ti.drv.uart');
-    //Uart.Settings.socType = socType;
-
-There is also an instance in the application code where we added pointer
-to PRCM registers that need to be changed as follows.
-
-::
-
-       CSL_l4per_cm_core_componentRegs *l4PerCmReg =
-      (CSL_l4per_cm_core_componentRegs *) 0x6a009700; //CSL_MPU_L4PER_CM_CORE_REGS;
-
-Now, you are ready to build the firmware. After the .out is built,
-change the extension to .xem4 and copy it over to the location in the
-filesystem that is used to load M4 firmware.
-
-.. rubric:: Download the Full CCS Project
-   :name: download-the-full-ccs-project-1
-
-`UART_BasicExample_evmAM572x_m4ExampleProject_with_ipc.zip
-<http://processors.wiki.ti.com/index.php/File:UART_BasicExample_evmAM572x_m4ExampleProject_with_ipc.zip>`__
-
diff --git a/source/rtos/How_to_Guides/Host/System_Integration/_IPC_Debugging_Tools_and_Techniques_on_AM57xx.rst b/source/rtos/How_to_Guides/Host/System_Integration/_IPC_Debugging_Tools_and_Techniques_on_AM57xx.rst
deleted file mode 100644
index c9a5d720b..000000000
--- a/source/rtos/How_to_Guides/Host/System_Integration/_IPC_Debugging_Tools_and_Techniques_on_AM57xx.rst
+++ /dev/null
@@ -1,726 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Running_IPC_Examples_on_DRA7xx/AM572x
-
-The sections relevant to AM57xx have been pulled from the `Debugging Tools and Techniques With IPC3.x Application Note <http://www.ti.com/lit/an/sprac12/sprac12.pdf>`_ and placed here.
-
-Introduction
-^^^^^^^^^^^^
-During development of software, it is common to encounter issues that must be debugged to provide a
-robust software offering. When developing software that uses the IPC3.x product for inter-processor
-communication, there are tools and techniques available to aid in the debugging process. These tools and
-techniques help to more quickly understand and debug the issue. This document addresses all three
-HLOS’s supported by IPC3.x: Android™ platform, Linux®, and QNX®. Where applicable, differences
-between the OS's are noted.
-This document aims to provide tools, techniques, and resources for debugging issues encountered when
-using the IPC3.x to communicate with remote core software.
-
-Debug Tools
-^^^^^^^^^^^
-There are several tools that can be leveraged for debugging the IPC, from simple tracing to using Code
-Composer Studio™ (CCS) to attach to the remote cores. Each provides different advantages in
-the debugging process.
-
-Tracing
-"""""""
-When an issue occurs, checking the traces is often the first thing done. The traces can give quick insight
-into what may be happening. In normal, non-error cases, you might see little to no traces from the IPC.
-But when there is an error, there often is an error trace that can be used to shed light on the issue. An
-error trace often gives an error code and a module or function name that can be used to identify where the
-error was thrown.
-
-Linux and Android - Debugfs
-"""""""""""""""""""""""""""
-Another useful place to look for debug info is in the debugfs. Information for each remote processor can
-be found there, as well as remote core traces, state information, and more.
-
-Code Composer Studio
-""""""""""""""""""""
-Connecting over JTAG using Code Composer Studio provides the ability to see exactly what is happening
-on the remote core, providing access to a wealth of information including viewing memory, registers, and
-stepping through the code.
-
-Traces
-^^^^^^
-The first place to check when an issue occurs is the traces. Often an error code or a trace regarding an
-error gives some clue. Both the remote core traces and the HLOS-side traces can be checked.
-
-Linux and Android - Enabling IPC Traces
-"""""""""""""""""""""""""""""""""""""""
-By default, the IPC only prints error traces. To enable additional tracing, use the IPC_DEBUG
-environment variable at runtime. This feature is only supported on Linux and is available starting in IPC
-3.22.00.05. Table 1 lists the two levels of tracing supported.
-
-Table 1. IPC_DEBUG Trace Levels
-
-+-------------+------------------------------------------------------------------+
-| Trace Level | Description                                                      |
-+=============+==================================================================+
-| 1           | Enables all warnings and errors to be printed                    |
-+-------------+------------------------------------------------------------------+
-| 2           | Turns on all tracing (including socket and LAD client tracing).  |
-+-------------+------------------------------------------------------------------+
-
-QNX – Enabling IPC Traces
-"""""""""""""""""""""""""
-When using QNX, additional traces are enabled by setting environment variables. There are separate
-environment variables for enabling traces in the resource manager and the user libraries.
-
-**Resource Manager Traces**
-
-Enable additional traces in the slog by setting the environment variable IPC_DEBUG_SLOG_LEVEL at
-runtime. By default, only errors and warnings are printed. The IPC_DEBUG_SLOG_LEVEL can be set
-before launching IPC to enable more traces. Setting the level to 7 enables all IPC traces. The default level
-is 2.
-::
-
-	export IPC_DEBUG_SLOG_LEVEL=7
-
-These traces are printed to the slog, and can be viewed by using the sloginfo command. All IPC traces
-use 42 as identification in the slog, and you can filter the slog to view only these traces::
-
-	sloginfo –m42
-
-**User Library Traces**
-
-User library traces can be enabled by using the variable IPC_DEBUG when launching the application.
-Valid levels are 1 to 3, with 3 being the most verbose. For example::
-
-	IPC_DEBUG=<level> app_host
-
-Linux and Android - Remote Core Traces
-""""""""""""""""""""""""""""""""""""""
-The remote core traces can be checked by using debugfs. Run the following command, replacing the “X”
-with the core-id for the remote core to be checked.
-::
-
-	cat /sys/kernel/debug/remoteproc/remoteprocX/trace0
-
-Check the following when checking the traces after an error recovery has occurred::
-
-	cat /sys/kernel/debug/remoteproc/remoteprocX/trace0_last
-
-This provides the last traces that happened before error recovery was triggered. For more information
-about debugging remote core faults and exceptions, see `Debugging MMU Faults and Exceptions`_.
-
-The core-id, “X”, starts at 0 and increments to include all of the remote cores supported by the remoteproc
-module in the dts file. Because the number of remoteprocs supported can vary depending on the dts
-configuration, it is not ensured that a certain remote core will always have a certain core-id if the
-remoteprocs supported in the dts file changes.
-
-The core associated with a particular core-id can be found by checking the name of the remoteproc (see `Linux and Android - Remoteproc`_). Table 2 associates the remoteproc name with the common name of the
-remote processor.
-::
-
-	cat /sys/kernel/debug/remoteproc/remoteprocX/name
-
-Table 2. Remoteproc Names for AM57xx
-
-+--------------+--------------------+
-| Debugfs Name |  Remote Core Name  |
-+==============+====================+
-| 58820000.ipu | IPU1               |
-+--------------+--------------------+
-| 55020000.ipu | IPU2               |
-+--------------+--------------------+
-| 40800000.dsp | DSP1               |
-+--------------+--------------------+
-| 41000000.dsp | DSP2               |
-+--------------+--------------------+
-
-QNX - Remote Core Traces
-""""""""""""""""""""""""
-The remote core traces can be checked by using sysfs. Run the following command, replacing <core
-name> with the core name for the remote core to check. Valid core names for AM57xx are IPU1, IPU2,
-DSP1, and DSP2.
-::
-
-	cat /dev/ipc-trace/<core name>
-
-When checking the traces after error recovery has happened, check the logfile specified at IPC startup, if
-one was specified. When starting IPC, specify a logfile using the “-c” option. When an error recovery
-happens, the last traces are dumped to this log file. For more information about debugging remote core
-faults and exceptions, see `Debugging MMU Faults and Exceptions`_.
-
-QNX - Adding Traces
-"""""""""""""""""""
-In some cases, you may want to add traces to get more information about the issue. If the issue is reliably
-reproducible, one technique is to add additional traces to get more information. If the issue is timing-related, this technique may not be helpful, as it may mask the issue
-
-**SYS-BIOS**
-
-You can add traces in the SYS-BIOS IPC code that come to the trace buffer by using the System_printf()
-API. After adding traces to the SYS-BIOS IPC and rebuilding the IPC, you must rebuild the remote core
-image. The traces come to the remote core trace buffer and can be viewed by following the instructions in
-`Linux and Android - Remote Core Traces`_.
-
-**Linux**
-
-Additionally, traces can be added in the Linux code. The modules of interest when adding traces are the
-remoteproc, iommu, and rpmsg modules in the kernel, and the MessageQ, MMRPC, and LAD modules in
-the user space.
-
-In the kernel are these modules in the following paths:
-
-* drivers/remoteproc/
-* drivers/iommu/
-* drivers/rpmsg/
-
-Most of the user space code can be found in the IPC package, in the linux folder. The MMRPC code is
-found in the packages/ti/ipc/mm/ folder.
-
-Remote Core Status Information
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Useful information about the status of the remote cores can be found in debugfs.
-
-Linux and Android - Remoteproc
-""""""""""""""""""""""""""""""
-Information about each remote core can be found in the following, where the “X” can be replaced with the
-remote core id.
-::
-
-	cat /sys/kernel/debug/remoteproc/remoteprocX/<entry>
-
-Table 3 lists what can be found for each core.
-
-Table 3. Remoteproc Debugfs Entries
-
-+--------------+-------------------------------------------------------------------------------------------+
-| Entry        |  Description                                                                              |
-+==============+===========================================================================================+
-| name         | Processor name, comprised of the RAM address and the processor type,                      |
-|              | (for example, 58820000.ipu for IPU1). For a complete list of names, see Table 2.          |
-+--------------+-------------------------------------------------------------------------------------------+
-| recovery     | Returns either “enabled” or “disabled”, indicating if recovery is enabled or disabled for |
-|              | the remote processor.                                                                     |
-+--------------+-------------------------------------------------------------------------------------------+
-| state        | Gives the state of the remote processor. State is one of:                                 |
-|              | * offline (0)                                                                             |
-|              | * suspended (1)                                                                           |
-|              | * running (2)                                                                             |
-|              | * crashed (3)                                                                             |
-+--------------+-------------------------------------------------------------------------------------------+
-| trace0       | Returns the contents of the remote processor trace buffer.                                |
-+--------------+-------------------------------------------------------------------------------------------+
-| trace0_last  | Created after recovering the remote core. Returns the contents of the remote processor    |
-|              | trace buffer before recovery was triggered.                                               |
-+--------------+-------------------------------------------------------------------------------------------+
-| version      | Returns the version. Currently returns nothing.                                           |
-+--------------+-------------------------------------------------------------------------------------------+
-
-Linux and Android - IOMMU Info
-""""""""""""""""""""""""""""""
-Information about the IOMMU can also be found in debugfs. It can be found in the following path, where
-“XXXXXXXX” is replaced by the register address for the remote core MMU registers.
-::
-
-	cat /sys/kernel/debug/omap_iommu/XXXXXXXX.mmu/<entry>
-
-Table 4 gives the corresponding core name for each MMU for AM57xx, and the register address in the TRM.
-
-Table 4. IOMMU Entry Names
-
-+--------------+-------------+
-| IOMMU Entry  |  Core Name  |
-+==============+=============+
-| 58882000.mmu | IPU1        |
-+--------------+-------------+
-| 55082000.mmu | IPU2        |
-+--------------+-------------+
-| 40d01000.mmu | DSP1 (MMU1) |
-+--------------+-------------+
-| 40d02000.mmu | DSP1 (MMU2) |
-+--------------+-------------+
-| 41501000.mmu | DSP2 (MMU1) |
-+--------------+-------------+
-| 41502000.mmu | DSP2 (MMU2) |
-+--------------+-------------+
-
-Some of this information is inaccessible from a suspended state. Table 5 lists what can be found for each core.
-
-Table 5. IOMMU Debugfs Entries
-
-+----------------+---------------------------------------+
-|     Entry      | Description                           |
-+================+=======================================+
-| nr_tlb_entries | Gives the number of tlb entries       |
-+----------------+---------------------------------------+
-| pagetable      | Dumps the pagetable entries           |
-+----------------+---------------------------------------+
-| regs           | Gives the values of the MMU registers |
-+----------------+---------------------------------------+
-| tlb            | Lists the tlb entries.                |
-+----------------+---------------------------------------+
-
-QNX – Remote Core State Information
-"""""""""""""""""""""""""""""""""""
-Find out the current state of the remote core by issuing the following command:
-::
-
-	cat /dev/ipc-state/<core_name>
-
-The “core_name” is the name of the remote core. Valid names for AM57xx are IPU1, IPU2, DSP1, and
-DSP2. The current state will show as “running” or “reset”.
-
-Using Code Composer Studio
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-A useful tool for debugging issues is Code Composer Studio. CCS allows easy connection to the remote
-core in order to see the state of the remote core.
-
-Debug Symbols
-"""""""""""""
-The remote core image must be built with debug symbols to see information such as the call stack and
-variables. Once attached, load the symbols. The symbols are built into the executable itself. When loading
-symbols, point to the same executable that is loaded on the target (or the unstripped version locally, if it is stripped to save space when loading to the target.)
-
-Linux and Android - Disabling Remoteproc Auto-Suspend
-"""""""""""""""""""""""""""""""""""""""""""""""""""""
-You may want to disable auto-suspend of the remote cores (provided that is not what is being debugged).
-When the core is suspended, you will not be able to connect to the remote core using CCS. Auto-suspend
-can be disabled by setting the power control to “on” for the remote core.
-::
-
-	echo on > /sys/bus/platform/devices/<device>/power/control
-
-The remote core device name for each remote core can be found in Table 2.
-
-Linux and Android – Disabling Watchdog
-""""""""""""""""""""""""""""""""""""""
-You may decide to disable the watchdog timers when debugging and using CCS. Otherwise, while
-connected to the target, the watchdog may expire, triggering an abort sequence. Disable the watchdog
-timers for a remote core by removing their definitions from the dts file. For example, to disable the
-watchdog timers for IPU1, change the dts file as below::
-
-	&ipu1 {
-            status = "okay";
-
-            memory-region = <&ipu1_cma_pool>;
-
-            mboxes = <&mailbox5 &mbox_ipu1_legacy>;
-
-            timers = <&timer11>;
-
-           - watchdog-timers = <&timer7>, <&timer8>;
-
-           + /*watchdog-timers = <&timer7>, <&timer8>;*/
-
-
-SYS/BIOS – Disabling Watchdog
-"""""""""""""""""""""""""""""
-When using QNX, you can disable the watchdog from within the remote core image itself.
-If using Linux or Android, this step is not required; simply follow the instructions in `Linux and Android – Disabling Watchdog`_.
-
-To disable the usage of the watchdog from the remote core without completely disabling the device
-exception module (DEH), comment out the calls to Watchdog_init in the SYS/BIOS IPC code. These calls
-can be found in packages/ti/deh/Deh.c, packages/ti/deh/DehDsp.c, and packages/ti/ipc/ipcmgr/IpcMgr.c.
-
-packages/ti/deh/Deh.c::
-
-	/*
-	* ======== Deh_Module_startup ========
-	*/
-	Int Deh_Module_startup(Int phase)
-	{
-	if (AMMU_Module_startupDone() == TRUE) {
-	- Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
-	+ //Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
-	return Startup_DONE;
-	}
-	return Startup_NOTDONE;
-	}
-
-
-packages/ti/deh/DehDsp.c::
-
-	Int Deh_Module_startup(Int phase)
-	{
-	#if defined(HAS_AMMU)
-	if (AMMU_Module_startupDone() == TRUE) {
-	- Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
-	+ //Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
-	return Startup_DONE;
-	}
-	return Startup_NOTDONE;
-	#else
-	- Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
-	+ //Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
-	return Startup_DONE;
-	#endif
-
-packages/ti/ipc/ipcmgr/IpcMgr.c::
-
-	Void IpcMgr_rpmsgStartup(Void)
-	{
-	Assert_isTrue(MultiProc_self() != MultiProc_getId("HOST"), NULL);
-	RPMessage_init(MultiProc_getId("HOST"));
-	-#ifdef IpcMgr_USEDEH
-	+#if 0
-	/*
-	* When using DEH, initialize the Watchdog timers if not already done
-	* (i.e. late-attach)
-	*/
-	#ifdef IpcMgr_DSP
-	Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
-	#elif IpcMgr_IPU
-	Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
-	#endif
-	#endif
-	}
-	[...]
-	Void IpcMgr_ipcStartup(Void)
-	{
-	UInt procId = MultiProc_getId("HOST");
-	Int status;
-	/* TransportRpmsgSetup will busy wait until host kicks ready to recv: */
-	status = TransportRpmsgSetup_attach(procId, 0);
-	Assert_isTrue(status >= 0, NULL);
-	/* Sets up to communicate with host's NameServer: */
-	status = NameServerRemoteRpmsg_attach(procId, 0);
-	Assert_isTrue(status >= 0, NULL);
-	-#ifdef IpcMgr_USEDEH
-	+#if 0
-	/*
-	* When using DEH, initialize the Watchdog timers if not already done
-	* (i.e. late-attach)
-	*/
-	#ifdef IpcMgr_DSP
-	Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
-	#elif IpcMgr_IPU
-	Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
-	#endif
-	#endif
-	}
-
-Following this, rebuild the IPC and the remote core image to have an image with DEH, but without
-watchdog enabled.
-
-Attaching Before the Issue
-""""""""""""""""""""""""""
-In certain cases, you may want to attach to the remote core before the issue has occurred. If the issue is
-reliably reproducible and always occurs at the same location, then adding a breakpoint close to where the
-issue happens could be a good way to get a better picture of what is happening.
-
-One instance where it may be difficult is if the issue is happening during boot-up of the remote core. In
-this case, it may be necessary to add a while loop in the main function, to attach before the issue occurs.
-Add a loop similar to this::
-
-	{
-	volatile int foo = 1;
-	while (foo);
-	}
-
-Then, after attaching, load the symbols, add the breakpoints, change “foo” to 0, and continue running.
-
-Attaching After the Issue
-"""""""""""""""""""""""""
-You can also attach to the core after the issue, load the symbols, and see the state and view memory.
-You can view the Exception module’s exception CallStack ROV view and the task module’s per task
-CallStack ROV view. For more information about the runtime object viewer (ROV) in the RTSC
-documentation online, see `Runtime Object Viewer <http://rtsc.eclipse.org/docs-tip/Runtime_Object_Viewer/>`_.
-
-Viewing the State of the Remote Core
-""""""""""""""""""""""""""""""""""""
-Once attached and with symbols loaded, the state of the processor can be inspected. You can see the
-program counter, memory windows, registers, call stack, and the ROV, among other things.
-
-Debugging MMU Faults and Exceptions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Errors commonly manifest as MMU faults, exceptions, and watchdog errors (if using a version of IPC with
-watchdog available and enabled).
-
-Linux and Android - Disabling Error Recovery
-""""""""""""""""""""""""""""""""""""""""""""
-To debug an error, it may be necessary to turn of error recovery. Error recovery can be disabled by giving
-the following command::
-
-	echo disabled > /sys/kernel/debug/remoteproc/remoteprocX/recovery
-
-See `Linux and Android - Remoteproc`_ for more information.
-
-QNX – Disabling Error Recovery
-""""""""""""""""""""""""""""""
-To disable error recovery on QNX using IPC version 3.22 and above, give the -d option when launching
-the ipc binary. For example::
-
-	ipc –d IPU2 dra7x-ipu2-fw.xem4
-
-Crash Dump
-""""""""""
-If any of these three errors are encountered, you will get a crash dump from the remote core which is
-visible in the remote core traces. If error recovery is disabled, the dump can be found in trace0 (when
-using Linux/Android) or in /dev/ipc-trace/<core_name> (when using QNX); otherwise, the trace is found in
-trace0_last (when using Linux/Android) and in the logfile (when using QNX).
-
-An example of the crash dump will look like this::
-
- [0] [ 91.045] Exception occurred at (PC) = 0000c976
-
- [0] [ 91.045] CPU context: thread
-
- [0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.
-
- [0] [ 91.045] BIOS Task stack base: 0x800600e0.
-
- [0] [ 91.045] BIOS Task stack size: 0x800.
-
- [0] [ 91.045] [t=0x18f6df13] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1078: E_hardFault: FORCED
-
- [0] [ 91.045] ti.sysbios.family.arm.m3.Hwi: line 1078: E_hardFault: FORCED
-
- [0] [ 91.045] [t=0x18f9a0cb] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1155: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 96000000
-
- [0] [ 91.045] ti.sysbios.family.arm.m3.Hwi: line 1155: E_busFault: PRECISERR: Immediate Bus
-
- Fault, exact addr known, address: 96000000
-
- [0] [ 91.045] R0 = 0x96000000 R8 = 0xffffffff
-
- [0] [ 91.045] R1 = 0x00000000 R9 = 0xffffffff
-
- [0] [ 91.045] R2 = 0x00000000 R10 = 0xffffffff
-
- [0] [ 91.045] R3 = 0x80060814 R11 = 0xffffffff
-
- [0] [ 91.045] R4 = 0x00013098 R12 = 0x8006074c
-
- [0] [ 91.045] R5 = 0x0000000a SP(R13) = 0x80060820
-
- [0] [ 91.045] R6 = 0xffffffff LR(R14) = 0x0000c973
-
- [0] [ 91.045] R7 = 0xffffffff PC(R15) = 0x0000c976
-
- [0] [ 91.045] PSR = 0x61000000
-
- [0] [ 91.045] ICSR = 0x00438803
-
- [0] [ 91.045] MMFSR = 0x00
-
- [0] [ 91.045] BFSR = 0x82
-
- [0] [ 91.045] UFSR = 0x0000
-
- [0] [ 91.045] HFSR = 0x40000000
-
- [0] [ 91.045] DFSR = 0x00000000
-
- [0] [ 91.045] MMAR = 0x96000000
-
- [0] [ 91.045] BFAR = 0x96000000
-
- [0] [ 91.045] AFSR = 0x00000000
-
- [0] [ 91.045] Stack trace
-
- [0] [ 91.045] 00 [op faaaf00e] 00006abd (ret from call to 00015010)
-
- [0] [ 91.045] 01 [op ff49f005] 00006ac3 (ret from call to 0000c954)
-
- [0] [ 91.045] -- [op 98009000] 000154c9
-
- [0] [ 91.045] -- [op 00000000] 000a0001
-
- [0] [ 91.045] -- [op 80084a64] 0000fec9
-
- [0] [ 91.045] -- [op 0001a75c] 000068b9
-
- [0] [ 91.045] -- [op 80084a64] 0000fec9
-
- [0] [ 91.045] -- [op bd0ef919] 00015b91
-
- [0] [ 91.045] Stack dump base 800600e0 size 2048 sp 80060820:
-
- [0] [ 91.045] 80060820: 00000001 00006abd 96000000 00000000 ffffffff 00006ac3 0000000a 00006bf4
-
- [0] [ 91.045] 80060840: 00000000 00000000 80041800 80060ab0 00000080 56414c53 50495f45 be003155
-
- [0] [ 91.045] 80060860: bebebebe bebebebe bebebebe bebebebe bebebebe bebebebe bebebebe bebebebe
-
- [0] [ 91.045] 80060880: bebebebe bebebebe bebebebe bebebebe bebebebe 00000000 00000000 00000001
-
- [0] [ 91.045] 800608a0: 00000001 000154c9 0001309a 0000000a 00000000 80041820 00000001 ffffffff
-
- [0] [ 91.045] 800608c0: ffffffff 0000fec9 00000000 00000000 000068b9 0000fec9 00015b91 bebebebe
-
- [0] [ 91.045] Terminating execution...
-
-Exception Dump Decoding
-"""""""""""""""""""""""
-Some useful information that can be found in the dump is the fault address, PC address, register contents, and call stack.
-
-When an error occurs, you gets a crash dump from the remote core that looks similar to the one in `Crash Dump`_.
-
-The particular dump example above is from a MMU read fault. This dump provides important information
-in helping to understand what has happened. Some of the useful parts are broken down in the following
-section.
-
-**Timestamp**
-
-All traces (not just exception dumps) provide a timestamp for each trace. The time starts from the booting
-of the remote core.
-
- [0] **[ 91.045]** Exception occurred at (PC) = 0000c976
-
- [0] **[ 91.045]** CPU context: thread
-
- [0] **[ 91.045]** BIOS Task name: {empty-instance-name} handle: 0x80060090.
-
-The timestamp information can be useful even in non-crash situations, indicating the amount of time taken
-between two events. You can add traces at each event and then see when the events run.
-
-For example, to check that a certain event is happening every second, put a trace at that event, then
-check the timestamps to see that it is happening as expected.
-
-**PC Address**
-
-The PC address where the exception occurred is also provided. This can be used, in
-conjunction with the map file or CCS, to identify the line of code where the exception happened.
-
- [0] [ 91.045] **Exception occurred at (PC) = 0000c976**
-
- [0] [ 91.045] CPU context: thread
-
- [0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.
-
-**Task Information**
-
-The information about the task that was executing when the exception occurred is also provided.
-
- [0] [ 91.045] Exception occurred at (PC) = 0000c976
-
- [0] [ 91.045] CPU context: thread
-
- [0] **[ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.**
-
- [0] **[ 91.045] BIOS Task stack base: 0x800600e0.**
-
- [0] **[ 91.045] BIOS Task stack size: 0x800.**
-
-**Fault Information**
-
-The information about the fault is also provided. This can look different depending on the
-type of exception that occurred, but often provides a fault address to identify the source of the fault.
-
- [0] [ 91.045] Exception occurred at (PC) = 0000c976
-
- [0] [ 91.045] CPU context: thread
-
- [0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.
-
- [0] [ 91.045] BIOS Task stack base: 0x800600e0.
-
- [0] [ 91.045] BIOS Task stack size: 0x800.
-
- [0] [ 91.045] **[t=0x18f6df13] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1078: E_hardFault: FORCED**
-
- [0] [ 91.045] **ti.sysbios.family.arm.m3.Hwi: line 1078: E_hardFault: FORCED**
-
- [0] [ 91.045] **[t=0x18f9a0cb] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1155: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 96000000**
-
- [0] [ 91.045] **ti.sysbios.family.arm.m3.Hwi: line 1155: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 96000000**
-
-**Registers**
-
-A dump of the register contents at the time of the exception is also provided.
-
-.. image:: /images/RegisterDump.PNG
-
-**Stack Trace**
-
-The stack trace is also provided (see Figure 6). This can be used in conjunction with the source code and
-the map file or CCS to get more information about what was executing at the time of the crash.
-
-.. image:: /images/StackTraceDump.PNG
-
-MMU Faults
-""""""""""
-
-MMU faults occur when an address that is not mapped to the remote core MMU is accessed. This can be
-due to a read, write, or an attempt to execute the address. When an MMU fault occurs, a crash dump from
-the remote core occurs that looks similar to the example provided in `Crash Dump`_.
-
-Some debugging techniques, as well as common times when an MMU fault occurs, are given as
-examples in the following sections.
-
-**Using CCS to Halt the Code When the Fault Happens**
-
-If the fault always happens at the same address, pre-map the location and then set up CCS with a
-breakpoint for that address. In this way, you can view the state of the remote core when the fault happens
-and see the call stack. From there, put a breakpoint at the surrounding code and step through to see
-where the fault happens.
-
-Pre-mapping the address can be done either through the remote core resource table, or through CCS.
-With CCS, you can connect to the debug DAP and then bring up a memory window to inspect the MMU
-registers. Directly program the MMU from here to map some unused memory to the fault address location.
-
-For example:
-
-* MMU CAM: 0x9600000E (Change the most significant 20 bits here to match the fault address. For example, it would be 96000 if the fault address is 0x96000010)
-* MMU RAM: 0xBA300000 (Change the most significant 20 bits here to match an unused 4-KB physical region in the memory map)
-* MMU Lock: 0x00000400
-* MMU LD: 0x00000001
-
-**Using the Crash Dump to Find the Location of the Fault**
-
-The crash dump call stack can indicate where the crash occurred. Using that information, connect to the
-remote core with CCS and put a breakpoint in the code at the most recent function in the call stack before
-the crash. From there, step through the code until the crash happens.
-
-**Example – Accessing a Memory Region That is Not Mapped**
-
-When using the L2 MMU, every address accessed by the remote core must be mapped. An attempt to
-access an un-mapped address results in an MMU fault. The following example explores the crash dump of
-an access to an un-mapped area.
-
-Here is an example fault dump:
-
-.. image:: /images/StackTraceDump2.PNG
-
-From the crash dump, the fault address is 0x96000000. The address will not be found in the resource
-table, which is why the fault occurred.
-
-Avoid hard-coding of virtual addresses for peripherals and memory blocks with a one-time physical to
-virtual address lookup using the resource table. There is an API available for this called
-Resource_physToVirt() in the resource module. This alerts that the address is not mapped in the resource
-table when the translation fails.
-
-From here, either use the crash dump to see the PC and call stack or follow the instructions under the section "Using CCS to Halt the Code When the Fault Happens." Error recovery, watchdog timers, and remoteproc autosuspend
-may need to be disabled to connect CCS. See `Linux and Android - Disabling Error Recovery`_, `Linux and Android – Disabling Watchdog`_, and `Linux and Android - Disabling Remoteproc Auto-Suspend`_ for more
-information on disabling these.
-
-For this example, use the PC address which, as seen in the crash dump, is at 0xcfa6
-
-::
-
-	[0] [ 107.092] Exception occurred at (PC) = 0000cfa6
-
-Find the corresponding function by looking this address up in the map file for the remote core image. If the
-PC address is invalid due to an issue such as stack corruption, then this may not yield useful results. In
-this case, something useful is found:
-
-.. image:: /images/SourceInsightCrashDump.PNG
-
-Alternatively, use CCS to see the location of the fault. If CCS was already connected to the remote core
-before the fault happened, the core will have halted in the abort function. From here, directly set the PC
-address and see the line that caused the fault:
-
-.. image:: /images/CCSFault.PNG
-
-Use this technique at any time after booting the remote core to see what a PC address corresponds to. It
-will display the line that caused the error. This may, however, prevent proper execution because the
-registers and call stack won’t have proper values.
-
-You can now isolate the particular line in the fxnFault() function that was executing. That code is found in
-the file <ipc_package>/packages/ti/ipc/tests/fault.c::
-
-    case 1:
-            System_printf("Generating read MMU Fault...\n");
-            a = *(volatile int *) (0x96000000);
-            break;
-
-Figure 8 clearly shows what caused the fault in this code, but when it is not clear, use CCS to see the fault in action. Once connected and the symbols are loaded, put a breakpoint in this function (if this function does not happen often). Once the breakpoint is hit, step through the code to find what is causing the fault.
-
-Upon stepping through, observe that the variable, a, is being set to the contents of 0x96000000, which is
-equal to the fault address. This is the fault in this example.
-
-Next, decide if this is a valid value that needs mapping, or if this is an invalid value that passed due to
-some error in the code. If it is still not known where the value is coming from, use CCS to trace it back
-through the call stack to fix the code. If it turns out that the address is an address that must be accessible to the remote core, then map it through the resource table to the appropriate physical memory.
-
diff --git a/source/rtos/How_to_Guides/Target/Run_apps_from_DDR_on_R5.rst b/source/rtos/How_to_Guides/Target/Run_apps_from_DDR_on_R5.rst
deleted file mode 100644
index 53b99e595..000000000
--- a/source/rtos/How_to_Guides/Target/Run_apps_from_DDR_on_R5.rst
+++ /dev/null
@@ -1,75 +0,0 @@
-.. _run-apps-from-ddr-on-r5-cores:
-
-Once the R5 core is out of reset, the R5 defaults to no execute permissions for
-the DDR memory space. The side effect of this is,  that all code, from entry point
-till the code that sets up the MPU (Memory Protection Unit), has to be run from
-internal memory.
-
-.. _run-bios-app-from-ddr-on-r5:
-
-Run BIOS Applications from DDR on R5
--------------------------------------
-
-In BIOS, the application sets up the MPU as per the memory configuration specified
-in the *.xs file (that is referred to in the applications bios config file).  Once the
-MPU is setup by the app, the rest of the code can run from DDR.
-
-To ensure that all code from entry point to MPU setup is run from internal memory, the
-text sections of the following libs must be placed in internal memory using the application's linker
-command file.
-
-* *sysbios.aer5f(.text)
-
-* *boot.aer5f(.text)
-
-* *auto_init.aer5f(.text)
-
-* *<app>_per5f.oer5f(.text)
-
-Refer `emac_linker_r5.lds <https://git.ti.com/keystone-rtos/emac-lld/blobs/master/test/EmacLoopbackTest/am65xx/emac_linker_r5.lds>`__
-for an example.
-
-.. note::  Please note that you need to replace *<app>_per5f.oer5f with the corresponding
-           file for your application. For eg, if the application's .cfg file is emacUnitTest_r5.cfg,
-           then the .oer5f file will be named emacUnitTest_r5_per5f.oer5f
-
-
-You also need to update the *.xs file referred to by the applications .cfg file
-to make sure that the DDR has execute privileges. Please refer `r5_mpu.xs <http://git.ti.com/keystone-rtos/processor-pdk-build/blobs/master/am65xx/r5_mpu.xs>`__
-for an example memory configuration. You could also make the applications .cfg
-file refer to the common .xs file, as shown in the example
-`emacUnitTest_r5.cfg <https://git.ti.com/keystone-rtos/emac-lld/blobs/master/test/EmacLoopbackTest/am65xx/emacUnitTest_r5.cfg>`__.
-
-.. warning::   Once you update the .xs file, please note remember to delete *<app>_per5f.oer5f
-               from the applications *configuro directory, so that it is autogenerated again.
-               If you simply do a clean build, *<app>_per5f.oer5f will not be updated to reflect the
-               changes in the *.xs file.
-
-
-
-.. _run-baremetal-app-from-ddr-on-r5:
-
-Run Baremetal Applications from DDR on R5
-------------------------------------------
-
-Baremetal applications have similar restrictions on running code from
-internal memory till the MPU is configured, just like BIOS applications.
-For best comaptibility, however, make sure that the entry point is
-always the reset vector, and that the code that sets up the DDR access
-permissions in the MPU resides completely within 0x100 bytes of the
-entry point.
-
-For applications that find the default R5 configuration setup by the
-CSL sufficient, there is another method that can be used to execute
-an application from DDR. If the bootloader (SBL) is re-built using the
-SBL_SKIP_MCU_RESET compile option (by enabling the corresponding line
-in `sbl_component.mk <https://git.ti.com/keystone-rtos/sbl/blobs/master/sbl_component.mk#line399>`__,
-then SBL will branch to the application entry point without resetting the R5 core.
-
-In this scenario, as the  R5 core was already setup when the SBL
-invoked CSL init, the app can execute directly from DDR, right from its
-entry point. However, the app must take care not to redo the R5 initialization
-using CSL init, as the CSL initialization code assumes that the R5 registers are at their
-reset default values. This can be done by simply defining an empty __mpu_init function in the
-baremetal application. Refer `sbl_smp_r5.asm <https://git.ti.com/keystone-rtos/sbl/blobs/master/example/k3MulticoreApp/sbl_smp_r5.asm>`__
-for an example.
diff --git a/source/rtos/How_to_Guides/Target/_C66x_Reset_from_A15_Running_Linux.rst b/source/rtos/How_to_Guides/Target/_C66x_Reset_from_A15_Running_Linux.rst
deleted file mode 100644
index b04b46fbe..000000000
--- a/source/rtos/How_to_Guides/Target/_C66x_Reset_from_A15_Running_Linux.rst
+++ /dev/null
@@ -1,58 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Taking_the_C66x_Out_Of_Reset_with_Linux_Running_on_the_ARM_A15
-
-How to take the C66x DSP out of reset with Linux running on A15
----------------------------------------------------------------
-
-This document describes the procedure to bring the C66x core out of reset after
-booting Linux, or at the u-boot prompt.These steps are necessary in to order to
-load an application on the C66x core, without interfering with the operation of
-Linux running on the A15.
-
-.. note::
-   Prior to proceeding with the below instructions, please ensure that the latest :ref:`Emulation Package<>`
-   is downloaded/installed through CCS. This will ensure the GEL files in your machine
-   has the reset routines described below.
-
-1) Once Linux has booted, launch the target configuration.
-
-.. Image:: /images/Outofreset_1_lali.JPG
-
-2) With the target configuration launched, right click on K2x.ccxml and select
-   “Show all cores”
-
-.. Image:: /images/Outofreset_2_lali.JPG
-
-3) This will bring up the Non-Debuggable Devices section.
-   Right click and connect the CS_DAP_Debug_SS core.
-
-.. Image:: /images/Outofreset_3_lali.JPG
-
-4) Go to Tools>GEL files and load the evmk2x.gel file by right clicking on the GEL file window.
-   The Gel file would typically be located in the CCS installation under
-   \\ccsv6\\ccs_base\\emulation\\boards\\evmk2x\\gel\\
-
-.. Image:: /images/Outofreset_4_lali.png
-
-5) Once the GEL has been successfully loaded, go to Scripts>default and select K2x_TakeDSPOutofReset.
-
-.. Image:: /images/Outofreset_5_lali.png
-
-6) At this point the console would indicate that the DSP is out of reset.
-
-.. Image:: /images/Outofreset_6_lali.png
-
-7) Now the DSP cores can be right-clicked and connected successfully.
-
-.. Image:: /images/Outofreset_7_lali.png
-
-Target Configuration
---------------------
-
-.. note::
-   Once the DSP core is connected following the above out of reset routine, the DDR and PLL settings
-   done by u-boot would be overwritten by what's in the GEL. In order to avoid this, please ensure that
-   the gel is NOT preloaded on the DSP core in the ccxml by leaving the initialization script blank.
-
-
-.. Image:: /images/Outofreset_8_lali.JPG
-
diff --git a/source/rtos/How_to_Guides/Target/_External_Input_Trigger_Interrupt_AM57x.rst b/source/rtos/How_to_Guides/Target/_External_Input_Trigger_Interrupt_AM57x.rst
deleted file mode 100644
index fb5dece50..000000000
--- a/source/rtos/How_to_Guides/Target/_External_Input_Trigger_Interrupt_AM57x.rst
+++ /dev/null
@@ -1,150 +0,0 @@
-
-
-This note explains how to develop an example using a General-Purpose Input/Output (GPIO) pin to capture an external input event and generate an interrupt by modifying an existing RTOS GPIO driver LED blinking example. The hardware setup, software development procedures and testing are done using TI AM572x IDK EVM. The same process can be extended to other TI Sitara devices, TI EVMs or custom platforms as well.
-
-Hardware
----------
-`The AM572x Industrial Development
-Kit (IDK) <http://www.ti.com/tool/TMDXIDK5728>`__ is used here for developing the example. The same expect to work with the `AM574x
-IDK <http://www.ti.com/tool/TMDSIDK574>`__ as well.
-
-From the `AM572x IDK EVM hardware
-user guide <http://www.ti.com/lit/ug/sprui64c/sprui64c.pdf>`__, the card has 3 push buttons: SW1, SW2 and SW3, but they all are used for different purposes. However, the card has a 60-pin female expansion connector J21, pins that are not used may be dedicated for GPIO input test purpose. Here J21 pin 4 is selected based on the following analysis:
-
-•	The Pin 4 signal is labeled as GPMC_CS0 and is connected to AM572x chip ball T1 as shown in the schematic:
-
-.. Image:: /images/J21_gpio_input.png
-.. Image:: /images/gpmc_cs0_t1.png
-
-•	From the AM5728 datasheet, T1 ball can be configured as GPMC_CS0 or GPIO2_19 based on different PINMUX modes.
-
-Software
----------
-The GPIO LED blink example is served as the reference example and the test is developed on the ARM A15 core, it should work for other cores. This section discusses several typical steps involved in the software development work:
-
-•	PinMux configuration
-•	PRCM setup
-•	Re-build board library
-•	Application software development
-
-**PinMux configuration**
-
-The default PinMux file has to be modified for GPIO2_19 pin usage:
-
-•	Use the PinMux Utility to open the default PinMux file pdk_am57xx_1_0_x\\packages\\ti\\board\\src\\idkAM572x\\idkAM572x_SR2.0.pinmux (for the latest Rev 1.3B EVM)
-•	Select GPIO, then MyGPIO2:
-
-.. Image:: /images/pinmux_gpio_1.png
-
-•	Then, scroll down, set gpio2_19 with ball #T1, pull up and Rx direction.
-•	Finally, select Category filter as “SR2.0 – Platform Development Kit (PDK) and download the generated files.
-
-.. Image:: /images/pinmux_gpio_2.png
-
-•	Four new files should be generated, with the only difference  being a new pin configuration added in boardPadDelayInit.c file:
-
-.. code-block:: c
-
-      /* GPIO2 - gpio2_19 on T1 - MyGPIO2 */
-     {0x14B4, 0x6000E, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
-
-•	Replace the same files under pdk_am57xx_1_0_x\\packages\\ti\\board\\src\\idkAM572x with the new ones.
-
-**PRCM setup**
-
-Setup of the Power, Reset and Clock Management (PRCM) domain for newly added GPIO2 is required. The application code calls Board_init() API with a BOARD_INIT_MODULE_CLOCK flag to enable the clock domain. It is implemented in the Board_moduleClockInit() function inside pdk_am57xx_1_0_x\\packages\\ti\\board\\source\\idkAM572x\\idkAM572x_clock.c. It is found that GPIO2 is enabled already and no further code needed.
-
-**Re-build board library**
-
-The board library must be recompiled for the changes to take effect. This has several major steps:
-
-•	Setup the build environment by running setupenv script
-•	Build the library with make command (e.g. “make board”) and the output will be under pdk_am57xx_1_0_x\\packages\\ti\\board\\lib\\idkAM572x\\a15\\release
-
-Application software development
------------------------------------
-The GPIO LED blinking example (GPIO_LedBlink_idkAM572x_armTestProject) is used as the reference. The CCS project can be created by using pdkprojectcreate script, such as “pdkprojectcreate AM572x idkAM572x little gpio all arm”. Check `PDK Example and Test Project Creation <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#rebuilding-components>`_ for details.
-
-This LED blink example uses 2 GPIO pins. The first pin is used to periodically generate an interrupt. The second pin is an output pin connected to an onboard LED, which toggles between low and high inside the interrupt ISR, thus driving the LED. Note the first pin doesn’t accept any external input, but using software to write a register (GPIO_IRQSTATUS_RAW_n) to generate interrupt.
-
-Also note from GPIO_idkAM572x_board.c, the rising edge is configured to generate interrupt:
-
-.. code-block:: c
-
-  GPIO_PinConfig gpioPinConfigs_1p3[] = {
-    /* Input pin with interrupt enabled */
-    GPIO_DEVICE_CONFIG(GPIO_GRN_LED_PORT_NUM_1P3, GPIO_GRN_LED_PIN_NUM_1P3) |
-    GPIO_CFG_IN_INT_RISING | GPIO_CFG_INPUT,
-   }
-
-After understanding how the reference example works, the code can be modified to use the first pin to receive external input and trigger the interrupt, then the second pin works the same way to toggle the LED, visualizing the event input.
-
-Code modifications:
-•	GPIO_board.h: this file defines the GPIO pins for the test, the first pin needs to be updated
-
-.. code-block:: c
-
-  #define GPIO_INTR_LED_BASE_ADDR_1P3      (CSL_MPU_GPIO2_REGS)
-  #define GPIO_LED_PIN_NUM_1P3             (0x13U)
-
-•	GPIO_idkAM572x_board.c: this file also defines the GPIO pins for the test, the first pin needs to be updated
-
-.. code-block:: c
-
-  /* GPIO Definitions specific Rev1p3 Board */
-  /* GPIO pin number connected to the green LED */
-  #define GPIO_GRN_LED_PIN_NUM_1P3    (0x13)
-
-  /* GPIO port number connected to the green LED */
-  #define GPIO_GRN_LED_PORT_NUM_1P3   (0x02)
-
-•	main_led_blink.c: this is the main test program. The change is high-lighted in black, while the original code is in grey.
-
-1) Inside void gpio_test(UArg arg0, UArg arg1) routine there is a while(1) loop that continuously triggers the interrupt by software write. Since the new example relies on the external input event to trigger it, one can simply add another while(1) in front of it to block the original loop:
-
-.. code-block:: c
-
-    while(1);  //New added loop
-    while(1)
-	{
-		if defined(SOC_AM574x) || defined(SOC_AM572x) || defined(SOC_AM571x)|| defined(SOC_AM335x) || defined(SOC_AM437x)
-		#if defined (idkAM572x) || defined (idkAM574x)
-                  ….
-    }
-
-2) Also inside the same void gpio_test(UArg arg0, UArg arg1) routine, one may add a debounce control before the test loop:
-
-.. code-block:: c
-
-    /* Write high to gpio pin to control LED1 */
-    GPIO_write((USER_LED1), GPIO_PIN_VAL_HIGH);
-
-    /* Add new debounce code here */
-    GPIOAppUpdateConfig(&gpioBaseAddr, &gpioPin);
-    GPIODebounceFuncControl(gpioBaseAddr, gpioPin, 1);
-    GPIODebounceTimeConfig(gpioBaseAddr, 255);
-
-    AppDelay(DELAY_VALUE);
-
-    GPIO_log("\n GPIO Led Blink Application \n");
-
-After all the code changes, rebuild the test application. A GPIO_LedBlink_idkAM572x_armTestProject.out should be generated.
-
-Test
----------
-
-**Test Setup**
-The test setup using AM572x IDK EVM is depicted below:
-
-.. Image:: /images/gpio_test.png
-
-•	The EVM is powered with a +5V power supply
-•	A micro USB cable is connected to the host PC for on-board XDS100v2 JTAG connection and UART console.
-•	A wire is connected to J21 pin4 as the event input. Another wire is connected to J21 pin 60 as the digital ground. When the two wires touch each other, pin 4 goes low, creating a GPIO falling edge. On the other hand, when the two wires are not touching, pin 4 goes high, creating a GPIO rising edge.
-
-**Test Procedure**
-
-•	Connect to the A15_0 with a JTAG emulator and use the default GEL file to initialize the SOC.
-•	Load the test application (GPIO_LedBlink_idkAM572x_armTestProject.out) and run.
-•	Touch the two wires, then un-touch, the LED should flip the status and keep steady until next touch, un-touch cycle.
-
diff --git a/source/rtos/How_to_Guides/Target/_Run_IPC_Examples_on_AM572x.rst b/source/rtos/How_to_Guides/Target/_Run_IPC_Examples_on_AM572x.rst
deleted file mode 100644
index 0df7f0976..000000000
--- a/source/rtos/How_to_Guides/Target/_Run_IPC_Examples_on_AM572x.rst
+++ /dev/null
@@ -1,441 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Running_IPC_Examples_on_DRA7xx/AM572x
-
-DRA7xx/AM572xx IPC Examples
----------------------------
-
-.. rubric:: IPC Hello Example:
-   :name: ipc-hello-example
-
-**ex01_hello**
-
-|
-
-The following examples demonstrate some of the rudimentary IPC
-capabilities. They are mostly two processors examples. These examples
-may be built for any two processors on your device, but only for two
-at a time. An IPC Ping example using three processors is also
-presented at the end.
-
-Hello example uses the reader/writer design pattern. One processor will
-be the reader and the other will be the writer. The reader creates a
-message queue and waits on it for messages. The writer opens the
-reader's message queue and sends messages to it. The writer allocates
-the message from a shared message pool and the reader returns the
-message to the pool. Thus, messages are sent in only one direction.
-Default settings of the Hello world example configures DSP1 as the
-writer and DSP2 as the reader.
-
-.. note::
-   if Windows 7 machine is used for building these examples,
-   **GnuWin32** make utility needs to be installed to run make which can be
-   downloaded from this link
-   `http://gnuwin32.sourceforge.net/packages/make.htm <http://gnuwin32.sourceforge.net/packages/make.htm>`__
-
-
-Set **GnuWin32\\bin** folder on file path and add a system variable
-**XDCTOOLS_JAVA_HOME** to point to "**c:\\ti\\ccsv6\\eclipse\\jre**"
-
-::
-
-    set PATH=<YOUR_PROCEEDING_PATH>\GnuWin32\bin;%PATH%
-    set XDCTOOLS_JAVA_HOME=c:\ti\ccsv6\eclipse\jre
-
-1. Change to the example folder by entering: cd
-~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/\ **ex01_hello**
-
-2. Open readme.txt file and follow build instructions step-by-step. If
-build this example on Ubuntu PC, make sure there is no spaces between
-variable name and its value.
-
-|
-
-::
-
-      DEPOT (your depository folder ex: DEPOT=/Your_Ubuntu_home_folder/ti)
-
-::
-
-      BIOS_INSTALL_DIR=$(DEPOT)/bios_n_nn_nn_nn
-
-::
-
-      IPC_INSTALL_DIR=$(DEPOT)/ipc_n_nn_nn_nn
-
-::
-
-      XDC_INSTALL_DIR=$(DEPOT)/xdctools_n_nn_nn_nn
-
-::
-
-      gnu.targets.arm.A15F=$(DEPOT)/ccsv6/tools/compiler/gcc-arm-none-eabi-4_8-2014q3
-
-::
-
-      ti.targets.elf.C66=$(DEPOT)/ccsv6/tools/compiler/c6000_7.4.14
-
-::
-
-      ti.targets.arm.elf.M4=$(DEPOT)/ccsv6/tools/compiler/arm_5.2.4
-
-::
-
-      ti.targets.arp32.elf.ARP32_far=$(DEPOT)/ccsv6/tools/compiler/arm_5.2.4
-
-::
-
-      See the following example, and ensure you are using the latest version
-      of folder names present in ~/ti folder:
-
-      DEPOT=/home/Your_Ubuntu_home_folder/ti
-
-      # Use the following environment assignment  (Note you must use 32 bit Java even in Ubuntu 14.04 64 bit OS environment)
-      export XDCTOOLS_JAVA_HOME=/home/Your_Ubuntu_home_folder/ti/ccsv6/eclipse/jre
-
-      #### BIOS-side dependencies ####
-      BIOS_INSTALL_DIR=$(DEPOT)/bios_6_41_04_54
-      IPC_INSTALL_DIR=$(DEPOT)/ipc_3_36_01_11
-      XDC_INSTALL_DIR=$(DEPOT)/xdctools_3_31_02_38
-
-      #### BIOS-side toolchains ####
-      gnu.targets.arm.A15F=$(DEPOT)/ccsv6/tools/compiler/gcc-arm-none-eabi-4_8-2014q3
-      ti.targets.elf.C66=$(DEPOT)/ti-cgt-c6000_8.0.3
-      ti.targets.arm.elf.M4=$(DEPOT)/ccsv6/tools/compiler/ti-cgt-arm_5.2.4
-      ti.targets.arp32.elf.ARP32_far=$(DEPOT)/ccsv6/tools/compiler/ti-cgt-arm_5.2.4
-
-3. Run make command in current folder to build DSP1 and DSP2 hello examples. Output files are created under debug sub folders.
-
- - ex01_hello\\dsp1\\bin\\debug
- - ex01_hello\\dsp2\\bin\\debug
-
-4. Launch target configurations.
-
-5. Right click CortexA15_0 and connect target.
-
-6. On CCS --> Scripts --> AM572 Multicore Initialization --> Run AM572x Multicore EnableAllCore
-
-7. Initialize DDR configuration. On CCS --> Scripts --> DDR configurations --> AM572_DDR3_532MHz_config
-
-8. Load DSP1 Hello Example hello_dsp1.xe66 (writer)file on DSP1.
-
-9. Load DSP2 Hello Example hello_dsp2.xe66 (reader) file on DSP2.
-
-10. Run both DSP1 and DSP2.
-
-11. On CCS --> Tools --> RTOS Object view (ROV).
-
-12. Suspend (halt) DSP1 to view test messages on ROV Viewable Modules -->LoggerBuf Refer below image of ROV log messages.
-
-.. Image:: /images/Hello_dsp2.png
-
-13. Suspend (halt) DSP2 and click on ROV icon to view log messages.
-
-|
-
-.. rubric:: IPC Message Queue Example:
-   :name: ipc-message-queue-example
-
-**ex02_messageq**
-
-Message queue example sends round-trip message from client to server and
-back. MessageQ example uses client/server pattern. It is a two
-processors example: the HOST and DSP processors. Either DSP1 or DSP2 can
-be built for testing.
-
-The DSP processor is configured as server. It creates a named message
-queue. The server does not open any queues because it extracts the
-return address from the message header. The server returns all messages
-to the sender. It does not access the message pool.
-
-The HOST processor is configured as client application. The client
-creates an anonymous message queue. The client also creates and manages
-the message pool. The client's return address is set in the message
-header for each message before sending it to the server.
-
-1. Change to messageQ folder example by enter:
-    cd  ~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/\ **ex02_messageQ**
-
-2. Open readme.txt file and follow build instructions step-by-step. Make
-sure there is no spaces between variable name and its value. See Hello
-World example environment varaible settings for reference.
-
-3. Run make command in current folder to build DSP1 and HOST hello examples. Output files are created under debug sub folders
-
- - ex02_messageq\\host\\bin\\debug : HOST A15 binary
- - ex02_messageq\\dsp1\\bin\\debug : C66x binary
-
-4. Launch target configurations. Note that BH560USB_M is emulator is used to connect to AM572X EVM.
-
-5. Right click CortexA15_0 and connect target.
-
-6. On CCS --> Scripts --> AM572 Multicore Initialization --> Run AM572x Multicore EnableAllCore
-
-7. Initialize DDR configuration. On CCS --> Scripts --> DDR configurations --> AM572_DDR3_532MHz_config
-
-8. **Load DSP1** messageQ Example out file(server_dsp1.xe66) onto DSP1.
-
-9. **Load HOST** messageQ Example out file(app_host.xa15fg) onto ARM CortexA15_0.
-
-10. Run both DSP1 and HOST.
-
-11. On CCS --> Tools --> RTOS Object view (ROV).
-
-12. Suspend (halt) ARM Cortex_A15 to view test messages on ROV Viewable Modules -->LoggerBuf Refer the following ROV message queue screenshot
-
-.. Image:: /images/MesgQ_arm0.png
-
-13. Suspend (halt) DSP1 and click on ROV icon to view log messages.
-
-|
-
-.. rubric:: IPC Notify Peer Example:
-   :name: ipc-notify-peer-example
-
-**ex13_notifypeer**
-
-Notify peer example only uses notify to communicate to a peer processor.
-This is an example of IPC Scalability. It uses the client/server design
-pattern. Initially, the example builds only for two processors: HOST and
-DSP1. The client runs on HOST and the server runs on DSP1.
-
-The client (HOST) creates an anonymous message queue. The client also
-creates and manages its own message pool. And it opens the server
-message queue using its name. The client initiates the data flow by
-allocating a message from the pool, placing its return address in the
-message header and sending the message to the server. It then waits for
-the message to be returned. When it receives the return message, the
-message is returned to the pool. The client repeats this in a loop.
-
-The server (DSP1) creates a named message queue, then waits on it for
-messages. When a message arrives, the server performs the requested
-work. When the work is done, the server extracts the return address from
-the message header and sends the message back to the client. The server
-never opens any message queues and does not access the message pool.
-
-Since DSP1 will need to wait on both the message queue and the notify
-queue, we introduce events. The SYS/BIOS event object can be used to
-wait on multiple input sources.
-
-
-1. Change to notify_peer folder example by enter: cd ~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/\ **ex13_notifypeer**
-
-2. Open readme.txt file and follow build instructions step-by-step. Make sure there is no spaces between variable name and its value.
-
-3. Run make command in current folder to build DSP1 and HOST notifypeer examples. Output files are created under debug subfolder.
-
-4. Launch target configurations. Note that BH560USB_M is emulator is used to connect to AM572X EVM.
-
-5. Right click CortexA15_0 and connect target.
-
-6. On CCS --> Scripts --> AM572 Multicore Initialization --> Run AM572x Multicore EnableAllCore
-
-7. Initialize DDR configuration. On CCS --> Scripts --> DDR configurations --> AM572_DDR3_532MHz_config
-
-8. **Load DSP1** notifypeer Example out file on DSP1.
-
-9. **Load HOST** notifypeer Example out file on ARM CortexA15_0.
-
-10. Run both DSP1 and CortexA15_0.
-
-11. On CCS --> Tools --> RTOS Object view (ROV).
-
-12. Suspend (halt) ARM CortexA15_0 to view test messages on ROV Viewable Modules -->LoggerBuf. Refer the following image of ROV log messages
-
-.. Image:: /images/Notify_peer_arm0.png
-
-13. Suspend (halt) DSP2 and click on ROV icon to view log messages.
-
-|
-
-.. rubric:: IPC Ping Example:
-   :name: ipc-ping-example
-
-**ex11_ping**
-
-ping example sends a message between all cores in the system. This
-example is used to exercise every communication path between all
-processors in the system (including local delivery on the current
-processor). Ping example is also organized in a suitable manner to
-develop an application with different compute units on each processor.
-
-Each executable will create two tasks: 1) the server task, and 2) the
-application task. The server task creates a message queue and then waits
-on that queue for incoming messages. When a message is received, the
-server task simply sends it back to the original sender.
-
-The application task creates its own message queue and then opens every
-server message queue in the system (including the server queue on the
-local processor). The task sends a message to a server and waits for the
-message to be returned. This is repeated for each server in the system
-(including the local server).
-
-.. note::
-   Note that presently EVE is not yet supported and therefore,
-   DSP1/DSP2/HOST are built for testing.
-
-1. Change to ping folder example by enter: cd
-~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/\ **ex11_ping**
-
-2. Open readme.txt file and follow build instructions step-by-step. Make
-sure there is no space between variable name and its value.
-
-3. Open makefile and remove EVE and IPU from PROC build list.
-
-4. Run make command in current folder to build DSP1, DSP2 and HOST ping examples. Output files are created under debug subfolder.
-
-5. Launch target configurations. Note that BH560USB_M is emulator is used to connect to AM572X EVM.
-
-6. Right click CortexA15_0 and connect target.
-
-7. On CCS --> Scripts --> AM572 Multicore Initialization --> Run AM572x Multicore EnableAllCore
-
-8. Initialize DDR configuration. On CCS --> Scripts --> DDR configurations --> AM572_DDR3_532MHz_config
-
-9. **Load DSP1** Ping Example out file on DSP1.
-
-10. **Load DSP2** Ping Example out file on DSP2.
-
-11. **Load HOST** ping Example onto ARM CortexA15_0
-
-12. Run DSP1, DSP2, and HOST images.
-
-13. On CCS --> Tools --> RTOS Object view (ROV).
-
-14. Halt DSP1 to view test messages on ROV Viewable Modules -->LoggerBuf Refer below image of ROV log messages
-
-.. Image:: /images/Ping_dsp1.png
-
-15. Suspend (halt) DSP2 and click on ROV icon to view log messages.
-
-16. Suspend (halt) ARM CortexA15_0 and click on ROV icon to view log messages.
-
-|
-
-.. rubric:: Expanding IPC Ping Example:
-   :name: expanding-ipc-ping-example
-
-To demonstrate the flexibility of IPC architecture, you may include
-additional cores to the above example by modifying the make file. For
-example, you may add IPU1 in the list of processor in the make file as:
-DSP1, DSP2, **IPU1,** HOST. After a clean build, the appropriate
-configuration and output executable files will be generated that allow
-passing messages between DSP1, DSP2, IPU1 and Host. Procedures are the
-same as described in the previous example with the exception of
-additional steps to load the IPU1 core with the corresponding executable
-and running it in conjunction with DSP1, DSP2 and HOST.
-
-.. note::
-   During build process using IPU1, you may encounter a message
-   indicating **rtsv7M4_T_le_eabi.lib** library is missing. This is a know
-   issue and is being tracked by **SDCOM00118417** IR. However, you may
-   create this missing library by going to the compiler installation's
-   **lib** directory and execute the following command to regenerate all
-   required libraries:
-
-   ::
-
-	./mklib --all
-
-The following example depicts a typical host communications protocol
-with other IPC apps (dsp1, dsp2, ipu1) **Note that the following HOST
-communications list has been rearranged to further clarify the type of
-communications between various cores**. Typically these messages arrive
-at different intervals depending on each core processes execution time.
-
-::
-
-       1    xdc.runtime.Main    --> main:
-       2    xdc.runtime.Main    main: ipc ready
-       3    xdc.runtime.Main    MainHost_svrTskFxn:
-       4    SvrHost    --> SvrHost_setup:
-       5    SvrHost    SvrHost_setup: slave is ready
-       6    SvrHost    <-- SvrHost_setup:
-       7    SvrHost    --> SvrHost_run:
-       8    xdc.runtime.Main    --> MainHost_appTskFxn:
-       9    AppHost    --> AppHost_setup:
-
-       10    AppHost    AppHost_setup: procId=0     opened server queue
-       11    AppHost    AppHost_setup: procId=1     opened server queue
-       12    AppHost    AppHost_setup: procId=2     opened server queue
-       28    AppHost    AppHost_setup: procId=3     opened server queue
-
-       32    AppHost    AppHost_run: ping procId=0
-       34    AppHost    AppHost_run: ping procId=0
-       36    AppHost    AppHost_run: ping procId=0
-       38    AppHost    AppHost_run: ping procId=0
-       40    AppHost    AppHost_run: ping procId=0
-
-       33    AppHost    AppHost_run: ack received     procId=0
-       35    AppHost    AppHost_run: ack received     procId=0
-       37    AppHost    AppHost_run: ack received     procId=0
-       39    AppHost    AppHost_run: ack received     procId=0
-       41    AppHost    AppHost_run: ack received     procId=0
-
-       13    SvrHost    SvrHost_run: message received     procId=0
-       14    SvrHost    SvrHost_run: message received     procId=0
-       15    SvrHost    SvrHost_run: message received     procId=0
-       16    SvrHost    SvrHost_run: message received     procId=0
-       17    SvrHost    SvrHost_run: message received     procId=0
-
-       42    AppHost    AppHost_run: ping procId=1
-       44    AppHost    AppHost_run: ping procId=1
-       46    AppHost    AppHost_run: ping procId=1
-       48    AppHost    AppHost_run: ping procId=1
-       50    AppHost    AppHost_run: ping procId=1
-
-       43    AppHost    AppHost_run: ack received     procId=1
-       45    AppHost    AppHost_run: ack received     procId=1
-       47    AppHost    AppHost_run: ack received     procId=1
-       49    AppHost    AppHost_run: ack received     procId=1
-       51    AppHost    AppHost_run: ack received     procId=1
-
-       18    SvrHost    SvrHost_run: message received     procId=1
-       19    SvrHost    SvrHost_run: message received     procId=1
-       20    SvrHost    SvrHost_run: message received     procId=1
-       21    SvrHost    SvrHost_run: message received     procId=1
-       22    SvrHost    SvrHost_run: message received     procId=1
-
-       52    AppHost    AppHost_run: ping procId=2
-       55    AppHost    AppHost_run: ping procId=2
-       58    AppHost    AppHost_run: ping procId=2
-       61    AppHost    AppHost_run: ping procId=2
-       64    AppHost    AppHost_run: ping procId=2
-
-       54    AppHost    AppHost_run: ack received     procId=2
-       57    AppHost    AppHost_run: ack received     procId=2
-       60    AppHost    AppHost_run: ack received     procId=2
-       63    AppHost    AppHost_run: ack received     procId=2
-       66    AppHost    AppHost_run: ack received     procId=2
-
-       53    SvrHost    SvrHost_run: message received     procId=2
-       56    SvrHost    SvrHost_run: message received     procId=2
-       59    SvrHost    SvrHost_run: message received     procId=2
-       62    SvrHost    SvrHost_run: message received     procId=2
-       65    SvrHost    SvrHost_run: message received     procId=2
-
-       67    AppHost    AppHost_run: ping procId=3
-       69    AppHost    AppHost_run: ping procId=3
-       71    AppHost    AppHost_run: ping procId=3
-       73    AppHost    AppHost_run: ping procId=3
-       75    AppHost    AppHost_run: ping procId=3
-
-       68    AppHost    AppHost_run: ack received     procId=3
-       70    AppHost    AppHost_run: ack received     procId=3
-       72    AppHost    AppHost_run: ack received     procId=3
-       74    AppHost    AppHost_run: ack received     procId=3
-       76    AppHost    AppHost_run: ack received     procId=3
-
-       23    SvrHost    SvrHost_run: message received     procId=3
-       24    SvrHost    SvrHost_run: message received     procId=3
-       25    SvrHost    SvrHost_run: message received     procId=3
-       26    SvrHost    SvrHost_run: message received     procId=3
-       27    SvrHost    SvrHost_run: message received     procId=3
-
-       29    AppHost    AppHost_setup: slave is ready
-       30    AppHost    <-- AppHost_setup:
-       31    AppHost    --> AppHost_run:
-       77    AppHost    <-- AppHost_run: 0
-       78    AppHost    --> AppHost_destroy:
-       79    AppHost    <-- AppHost_destroy: status=0
-       80    xdc.runtime.Main    <-- MainHost_appTskFxn: 0
-       81    xdc.runtime.Main    MainHost_done:
-
diff --git a/source/rtos/Overview.rst b/source/rtos/Overview.rst
deleted file mode 100644
index 59ea81582..000000000
--- a/source/rtos/Overview.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-##################
-Overview
-##################
-
-.. toctree::
-   :maxdepth: 5
-
-   index_overview
-
diff --git a/source/rtos/Overview/_Directory_Structure.rst b/source/rtos/Overview/_Directory_Structure.rst
deleted file mode 100644
index 82c328559..000000000
--- a/source/rtos/Overview/_Directory_Structure.rst
+++ /dev/null
@@ -1,156 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Directory_Structure
-
-Overview
-===========
-The Processor SDK for RTOS contain a number of software components,
-including a top-level RTOS SDK directory. These components are all
-installed in one common install path specified when running the
-installer.
-
-.. note::
-   Not all components are applicable on all platforms.
-
-Software Component Directories
-================================
-Here is a sample directory layout for the AM57x RTOS SDK:
-
-.. Image:: /images/Processor-SDK-RTOS-directories.png
-
-|
-
-Processor-SDK Directory
-========================
-The Processor SDK for RTOS contains a top-level RTOS SDK directory:
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>/
-
-The default SDK Install Path is ``C:\TI`` for Windows and
-``/home/[user]/ti`` for Linux.
-
-This directory contains the following top-level directories and files;
-here is an example for AM57x:
-
-.. Image:: /images/Processor-SDK-RTOS-directory-top.png
-
-These directories contain the collateral and tools applicable for RTOS:
-
--  **bin** - Contains the helper scripts for configuring the host system
-   and target device. Based on EVM capability, examples include scripts
-   to create an SD card with an RTOS application, script to flash EVM
-   with bootable application
-
--  **demos** - Contains demonstrations that implements interesting
-   features. Additionally, these demonstrations serve as a template to
-   start writing an application
-
--  **docs** - Contains various documentation such as the software
-   manifest and release notes
-
--  **prebuilt-sdcards** - Contains prebuilt SD card images that can be
-   copied to an SD card and used to load the EVM (AM3, AM4, AM5 only)
-
--  **prebuilt-images** - Contains prebuilt images to flash images to
-   write to EVM flash (K2x only)
-
--  **makefile** - Provides build targets for SDK components from the
-   top-level of the SDK
-
--  **setupenv.bat** - Configures the user Windows host system to prepare
-   to invoke the makefile
-
--  **setupenv.sh** - Configures the user Linux host system to prepare to
-   invoke the makefile
-
-|
-
-Components Included in SDK
-============================
-The following is a list of all components that may be included in the
-Processor-SDK RTOS SDK installer. See :ref:`Release Notes <release-notes-component-version>`
-for applicable components for a specific platform.
-
-Development Host Content
---------------------------
-
--  **CG_XML** - Perl scripts used to process the XML files that come
-   from the TI code generation tools
-
--  **XDC Tools** - XDCtools contains all of the tools for reusable
-   software components, optimized for real-time embedded systems
-
--  **ARM GCC Compiler** - GNU GCC ARM contains runtime libraries and
-   cross-compilers used for ARM development
-
--  **TI ARM Compiler** - TI ARM code generation tools, including C/C++
-   compiler, linker, and run-time-support libraries
-
--  **TI C6000 Compiler** - TI C6X code generation tools, including C/C++
-   compiler, linker, and run-time-support libraries
-
--  **TI PRU Compiler** - TI PRU code generation tools, including C/C++
-   compiler, linker, and run-time-support libraries
-
-Target Content
----------------
-
--  **CTOOLSLIB** - C6x DSP software libraries to use
-   trace/instrumentation hardware blocks on SOC (e.g., ETB, AET, STM)
-
--  **DSPLIB** - Optimized C6x DSP function library for C programmers
-
--  **EDMA3-LLD** - EDMA3 low level driver that supports data transfers
-   between two memory mapped devices
-
--  **FC**: Framework Components is comprised of XDAIS algorithm resource
-   managers and functional interfaces
-
--  **FFTLIB** - Optimized C6x DSP Fast Fourier Transform function
-   library for C programmers
-
--  **IMGLIB** - Optimized C6x DSP image and video processing function
-   library for C programmers
-
--  **IPC** - InterProcess Communication mechanisms including message
-   passing, streams, and linked lists, which work transparently in both
-   uniprocessor and multiprocessor configurations
-
--  **LIBARCH** - Library architecture framework used by other C6x DSP
-   optimized libraries
-
--  **LINALG** - Optimized C6x DSP dense linear algebra function library
-   for C programmers
-
--  **MATHLIB** - Optimized C6x DSP floating-point math function library
-   for C programmers
-
--  **MPM** - Multiproc Manager C6x DSP component provides services to
-   MPM Linux module to load and manage remote processors
-
--  **NDK** - Network Development Kit package provides an example network
-   stack that runs on the TI-RTOS kernel
-
--  **OPENCL** - OpenCL is a framework for writing programs that execute
-   across heterogeneous systems
-
--  **OPENMP** - OpenMP Runtime implements support for the OpenMP API
-   specification, a standard for shared memory parallel programming
-
--  **PDK** - Platform Development Kit that includes Chip Support
-   Libarary (CSL), Low Level Drivers (LLD), Boot, Diagnostics, and other
-   functions
-
--  **SYS/BIOS** - TI-RTOS kernel, a real-time operating system that
-   provides pre-emptive deterministic multithreading
-
--  **UIA** - Unified Instrumentation Architecture (UIA) APIs and
-   transports allow embedded software to log trace/event instrumentation
-   data that can be visualized in CCS
-
--  **XDAIS** - XDAIS (eXpress DSP Algorithm Interoperability Standard)
-   provides the rules and guidelines necessary to enable integration and
-   execution of algorithms
-
-|
-
diff --git a/source/rtos/Overview/_Examples_and_Demonstrations.rst b/source/rtos/Overview/_Examples_and_Demonstrations.rst
deleted file mode 100644
index cd080cbfe..000000000
--- a/source/rtos/Overview/_Examples_and_Demonstrations.rst
+++ /dev/null
@@ -1,284 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Examples_and_Demonstrations
-
-The SDK comes with some simple *examples* to get started using the
-software and IDE. The *demonstrations* contain a richer set of software
-and perform more complex features. If new to the SDK, it is suggested to
-go through the examples and demos before writing your application.
-
-|
-
-Application
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-Description
-
-AM335x EVM
-
-AM437x EVM
-
-AM57x EVM
-
-K2x EVM
-
-C66x EVM
-
-OMAPL13x EVM
-
-GP
-
-ICE
-
-SK
-
-BBB
-
-GP
-
-IDK
-
-SK
-
-GP
-
-IDK
-
-K2H
-
-K2E
-
-K2L
-
-K2G
-
-C665x
-
-C667x
-
-OMAPL137x/C6747x
-
-OMAPL138x/C6748x
-
-:ref:`Image Processing Demo <Demo-RTOS-Image-Processing-Demo-label>`
-
-The image processing demonstration utilizes SDK features such as
-multi-core A15 and DSP, optimized C66x IMGLIB, IPC, and UIA logging.
-
-X
-
-X
-
-X
-
-X
-
-:ref:`POSIX-SMP Demo <-RTOS-POSIX-SMP-Demo-label>`
-
-The Posix-SMP demonstration uses Posix APIs together with a simple
-benchmark (Dhrystone) to automatically calculate the effective
-throughput of all the cores in each SMP cluster. *(**NOTE:** SMP mode
-only applies to devices with ARM-A15 multiple cores.)*
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-`Audio Benchmark Starterkit <index_examples_demos.html#audio-benchmark-starterkit>`__
-
-The Audio Benchmark starter-kit demonstration provides quick and easy
-way to run core-benchmarks on the DSP for algorithms that are commonly
-used in audio applications.
-
-X
-
-X
-
-X
-
-X
-
-X
-
-`Audio Pre-Processing Demo <index_examples_demos.html#audio-pre-processing-demo>`__
-
-The Audio Pre-Processing demonstration provides an example for speech
-recognition application development by illustrating the integration of
-Beamforming (BF), Adaptive Spectrum Noise Reduction (ASNR), and Multiple
-Source Selection (MSS) components.
-
-X
-
-X
-
-X
-
-`Big Data IPC Example <index_examples_demos.html#big-data-ipc-example>`__
-
-The big data ipc examples are created mainly to show exchange of big
-data buffers between cores in a multi core system.
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-`TI-RTOS Kernel Example <index_examples_demos.html#ti-rtos-kernel-example>`__
-
-The RTOS examples gets user started with development of code using the
-TI-RTOS real-time operating system. These are simple examples that does
-not get into details of software components provided in the SDK.
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-`No OS (Bare Metal) Example <index_examples_demos.html#no-os-bare-metal-example>`__
-
-The bare-metal examples gets user started with development of code
-without an operating system. These are simple examples that does not get
-into details of software components provided in the SDK. *(**NOTE:**
-This example does not require the SDK to be installed, only the CCS IDE
-to communicate with the target.)*
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-X
-
-`Gravity Simulator Demo <index_examples_demos.html#gravity-simulator-demo>`__
-
-The RTOS Gravity Simulator Demo demonstrates the usage of an open
-sourced library combined with RTOS drivers to create a vibrant display.
-This showcases the usage of VPS LLD with CPU-generated display that is
-both variable and updated continuously.
-
-X
-
-`Template Application <index_examples_demos.html#rtos-template-application>`__
-
-The Template Application is intended for customers to use as a
-starting point during software development using Processor SDK RTOS
-software. The template application can be quickly brought up by
-importing the included CCS project into CCS development environment.
-
-X
-
-X
-
-|
-| The source files for the demonstrations can be found in the **demos**
-  folder of the top-level RTOS SDK directory:
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>/
-
-The default SDK Install Path is ``C:\TI`` for Windows and
-``/home/[user]/ti`` for Linux.
-
-.. Image:: /images/Processor-SDK-RTOS-directory-top.png
-
-|
-
diff --git a/source/rtos/Overview/_Getting_Started_Guide.rst b/source/rtos/Overview/_Getting_Started_Guide.rst
deleted file mode 100644
index e1f128133..000000000
--- a/source/rtos/Overview/_Getting_Started_Guide.rst
+++ /dev/null
@@ -1,452 +0,0 @@
-*****************************************
-Processor SDK RTOS Getting Started Guide
-*****************************************
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Getting_Started_Guide
-
-Overview
-=========
-
-The **Processor Software Development Kit (Processor-SDK)** provides the core
-foundation and building blocks that facilitate application software development
-on TI's embedded processors. This *Getting Started Guide* focuses on the
-Real-Time Operating System (RTOS) and provides information on acquiring the
-software and running basic examples/demonstrations bundled in the SDK.
-
-For anyone that is new to Processor-SDK RTOS, traversing through all the
-resources we provide in the right order is important. Here is a sequence
-to follow that introduces the SDK structure and gets you started with
-writing applications using the SDK.
-
-|
-
-Introduction to Processor SDK RTOS
-===================================
-
-First, start with watching introductory Processor SDK training videos
-that are relevant to RTOS:
-
-+------+-----------------------+-----------------------+
-|  ID  |         Name          |      Description      |
-+======+=======================+=======================+
-| 1.2  | `Introduction to      | This module is the    |
-|      | Processor SDK RTOS    | first installment of  |
-|      | Part                  | a two-part overview   |
-|      | 1 <http://training.ti | of the Processor SDK  |
-|      | .com/introduction-pro | from the TI-RTOS      |
-|      | cessor-sdk-rtos-part- | perspective. It       |
-|      | 1?cu=519268>`__       | introduces the        |
-|      | (40 min)              | functional elements   |
-|      |                       | that may be included  |
-|      |                       | in the installation   |
-|      |                       | for an SoC, and then  |
-|      |                       | looks at these        |
-|      |                       | elements in more      |
-|      |                       | detail: TI-RTOS       |
-|      |                       | kernel,               |
-|      |                       | Inter-Processor       |
-|      |                       | Communication (IPC),  |
-|      |                       | Network Developer's   |
-|      |                       | Kit (NDK), algorithm  |
-|      |                       | libraries, and        |
-|      |                       | diagnostic software.  |
-+------+-----------------------+-----------------------+
-| 1.3  | `Introduction to      | This module is the    |
-|      | Processor SDK RTOS    | second installment of |
-|      | Part                  | a two-part overview   |
-|      | 2 <http://training.ti | of the Processor SDK  |
-|      | .com/introduction-pro | from the TI-RTOS      |
-|      | cessor-sdk-rtos-part- | perspective. It       |
-|      | 2?cu=519268>`__       | examines the          |
-|      | (30 min)              | functional elements   |
-|      |                       | that may be included  |
-|      |                       | in the installation   |
-|      |                       | for an SoC: Low-level |
-|      |                       | Drivers (LLD), Chip   |
-|      |                       | Support Library       |
-|      |                       | (CSL), OS Abstraction |
-|      |                       | Layer (OSAL), board   |
-|      |                       | library, Secondary    |
-|      |                       | Boot Loader (SBL),    |
-|      |                       | and board             |
-|      |                       | diagnostics.          |
-+------+-----------------------+-----------------------+
-
-After going through these videos, you will have a good understanding of
-
--  how the software is organized for portability across platforms
--  software API hierarchy within a platform, from chip support to
-   low-level driver to middleware
--  where to customize software for different use cases
-
-|
-
-Basic examples
-================
-Next, it is beneficial to start with executing simple examples.
-
-Since we want to do this on the actual hardware target, you will need
-Code Composer Studio (CCS) and an Evaluation Module (EVM). See sections
-below for information to configure CCS and EVM for development. This is
-a top-level starting point, but you may need to go to your specific EVM
-hardware setup guide for some steps (e.g., connecting external JTAG). A
-cross reference to all hardware users guide can be found on the :ref:`Supported
-Platforms <RTOS-SDK-Supported-Platforms>`
-page.
-
-“Hello World” example with no operating system
-------------------------------------------------
-The simplest example that you can write is a “Hello World” example that
-runs in bare metal or no operating system. CCS comes with templates of a
-semi-hosted program for the different device and core. Using this
-template allows standard output to be displayed on the host PC using the
-debugger. This is a good way to start learning basic configurations such
-as the memory map of your device. Specific instructions for each
-platform bundled in the Processor SDK RTOS can be found at
-`Processor SDK Bare-Metal Examples <index_examples_demos.html#no-os-bare-metal-example>`__
-
-Simple examples with an operating system
-------------------------------------------
-The next level of complexity is the take that same “Hello World” example
-and run it over the TI-RTOS kernel. Besides a template for the simple
-four-line “Hello World” example, CCS comes with templates for other
-features of the kernel such as clock, error, event, log, SWI, and task.
-You will also learn how to configure the TI-RTOS kernel for such things
-as enabling semi-host support. Specific instructions for each platform
-bundled in the Processor SDK RTOS can be found at
-`Processor SDK RTOS Examples <index_examples_demos.html#ti-rtos-kernel-example>`__
-
-|
-
-Advanced examples
-==================
-Next, you can get familiar with peripheral drivers.
-
-Peripheral driver example
----------------------------
-The next level of complexity is to start using peripherals of your
-device. There are low-level driver examples that are provided in the
-Processor SDK RTOS package. These are CCS projects that can be used to
-test an individual peripheral. Some of the examples use multiple low
-level drivers; for example, the GPIO example will use I2C driver for
-reading EVM board ID to auto configure the software and UART driver to
-display status messages.
-
-For simplicity and flexibility, the CCS project information are captured
-in configuration files that you can use to generate CCS projects for
-your platform, EVM, endian, and core. Once CCS projects are created,
-they are loaded and run on the EVM via JTAG. Instructions to create and
-run the CCS projects can be found at
-`Rebuilding The PDK <index_how_to_guides.html#rebuild-drivers-from-pdk-directory>`__
-
-|
-
-Application development
-========================
-We now take the leap to put together parts of the SDK and create a more
-complex application.
-
-Template Application Workshop
-----------------------------------
-Take a look at the `workshop`__ for the RTOS/Bare-metal Template Application. This
-workshop will cover the basics of navigating the SDK and its documentation and
-using CCS. The Template Application is a good
-starting point to learn how to use drivers, the OSAL layer, and Board Library.
-It pulls portions of the SDK software into one application which can serve
-as the starting point for creating your first application.
-
-__ index_examples_demos.html#rtos-template-application
-
-.. note::
-   The template application currently supports Sitara EVMs (AM335x EVM,
-   AM437x EVM, AM572x EVM, and AM654x EVM) only.
-
-Demonstrations in Processor SDK RTOS
---------------------------------------
-Start with running the demonstrations that are part of Processor SDK
-RTOS package. These demonstrations can be run “out of box” since
-pre-build binaries are provided, but also contain source to that you can
-set breakpoints and step through the code. The demonstrations contain a
-richer set of software and perform more complex features such as audio
-and graphics.
-
-Not all demonstrations are applicable to all platforms. The following
-page has a list of all demonstrations and supported platform:
-`Processor SDK_RTOS Examples and Demonstrations <index_examples_demos.html>`__
-
-Custom application
---------------------
-Next, watch the following training video on guidelines to write a custom
-application using the SDK.
-
-+------+-----------------------+-----------------------+
-|  ID  |         Name          |      Description      |
-+======+=======================+=======================+
-| 1.4  | `Application          | This presentation     |
-|      | Development Using     | provides a detailed   |
-|      | Processor SDK         | overview of the       |
-|      | RTOS <https://trainin | application           |
-|      | g.ti.com/application- | development process   |
-|      | development-using-pro | using the Processor   |
-|      | cessor-sdk-rtos?cu=51 | SDK RTOS release. It  |
-|      | 9268>`__              | walks through each    |
-|      | (1 hr 40 min)         | step of the a typical |
-|      |                       | development flow,     |
-|      |                       | including setup of    |
-|      |                       | the evaluation module |
-|      |                       | (EVM), getting        |
-|      |                       | started with the EVM, |
-|      |                       | running out-of-box    |
-|      |                       | examples, developing  |
-|      |                       | application code,     |
-|      |                       | porting applications  |
-|      |                       | to custom hardware,   |
-|      |                       | and customization of  |
-|      |                       | application software. |
-+------+-----------------------+-----------------------+
-
-This video has a lot of content, as you can see from the duration. It is
-broken down into the following sections:
-
--  **Setup** development environment including download software,
-   configure target EVM
--  **Start** with basic software examples and basic connectivity of EVM
--  **Run** demo applications provided in SDK
--  **Develop** application using drivers in SDK
--  **Port** software to custom hardware by changing the board support
-   package
--  **Customize** application for certain use cases
-
-If you have custom hardware, the SDK software is organized to ease
-porting to a new hardware. All EVM-specific software is kept in the
-board support package, Board Library. Functions include unlocking MMR
-registers, initializing PLL, configuring clock, configuring PinMux,
-initialing DDR, and creating a UART instance for console output.
-Individual examples, unit tests, and demonstrations call the Board
-Library so that each of these applications can be migrated to a custom
-hardware by modifying the Board Library. You may want to also port the
-EVM diagnostics to your custom hardware and ensure the test suite
-passes.
-
-The customize module provides information to create a new application.
-This includes configuring TI-RTOS kernel to link required driver
-libraries, memory map, RTSC platform definition, and task creation.
-
-|
-
-Download and install software
-===============================
-There are three software packages that make up the Processor SDK RTOS
-development ecosystem:
-
--  Code Composer Studio (if using JTAG, IDE)
--  Latest CCS Emulation package (for connecting to target using JTAG)
--  Processor-SDK RTOS software
-
-See the :ref:`Release Notes <processor-sdk-rtos-release-notes>`
-for information on minimum requirements for host PC.
-
-The size of the installer is large since we want to provide one bundle
-for all the components. The bad side of this is that if you are manually
-downloading the Processor-SDK installer, you may run into issues such as
-download stall or slow download. One simple solution is to run a
-download manager/accelerator such as
-http://www.freedownloadmanager.org/.
-
-.. _overview-code-composer-studio:
-
-Code Composer Studio
------------------------
-
-.. Image:: /images/Ccsv7splash.jpg
-
-The Processor-SDK RTOS uses *Code Composer Studio* as the host
-integrated development environment for development and debug. All
-compilers are packaged with the SDK installer. This allows compilation
-of software without needing to install CCS. You only need CCS if you are
-using CCS projects, using JTAG to communicate with target, or need an
-Integrated Development Environment (IDE) for development and debug.
-
-To download CCS, use the installer specified on the Processor-SDK
-download page for your platform (see links in below section).
-
-
-.. Attention::
-   See the :ref:`Release Notes <processor-sdk-rtos-release-notes>` for the
-   recommended version of CCS. This is the version that was validated with
-   the software in the SDK and will provide the best user experience.
-   Occasionally, there may be compatibility issues if different versions
-   are used.
-
-When installing CCS, you can choose to control what is installed for
-processor architecture.
-
-.. Image:: /images/Processor-SDK_CCSv7-Setup-Processor-Support.png
-
-The minimum required for the SDK are the following items
-
--  **Sitara AMx Processors** for AM335x, AM437x, AM57x
--  **66AK2x multicore DSP + ARM Processors & C66x KeyStone multicore
-   DSP** for K2E, K2G, K2H, K2K, K2L, C665x, C667x
--  **OMAP-L1x DSP + ARM9 Processor** for OMAP-L1x
--  **C6000 Power-Optimized DSP** for C674x
-
-.. note::
-   If you plan to use emulators other than the XDS100 class or XDS200 class
-   of emulators, please select the appropriate emulation drivers at the
-   time of install. Code composer studio does not allow upgrades on drivers
-   that were not installed during the first install.
-
-|
-
-Emulator support
------------------
-The support for connecting a JTAG to the EVM to debug software is
-included in the CCS package. In some cases, additional modifications to
-configuration GEL files are provided separately. To get the latest
-version, perform a `CCS Check for
-Updates <http://software-dl.ti.com/ccs/esd/documents/ccsv7_updates.html>`__.
-
-The relevant update will be named
-
--  **Sitara Device Support** for AM335x, AM437x, AM57x
--  **Keystone2 Device Support** for K2E, K2G, K2H, K2K, K2L
--  **Keystone1 Device Support** for C665x, C667x
--  **OMAPL/Integra Device Support** for OMAP-L1x
--  **C6000 Device Support** for C674x
-
-For example, an update for Sitara devices will look like:
-
-.. Image:: /images/Processor-SDK_CCS-Emu-Update.png
-
-Processor-SDK for RTOS
-------------------------
-The final step is to download and install the Processor-SDK RTOS. See
-the software product page for your device to get the latest version of
-this software:
-
--  `Processor SDK for
-   AM335x <http://www.ti.com/tool/processor-sdk-am335x>`__
--  `Processor SDK for
-   AM437x <http://www.ti.com/tool/processor-sdk-am437x>`__
--  `Processor SDK for
-   AM57xx <http://www.ti.com/tool/processor-sdk-am57x>`__
--  `Processor SDK for
-   AMIC110 <http://www.ti.com/tool/PROCESSOR-SDK-AMIC110>`__
--  `Processor SDK RTOS for
-   C665x <http://www.ti.com/tool/PROCESSOR-SDK-C665X>`__
--  `Processor SDK RTOS for
-   C667x <http://www.ti.com/tool/PROCESSOR-SDK-C667X>`__
--  `Processor SDK RTOS for
-   C6747/OMAP-L17 <http://www.ti.com/tool/processor-sdk-omapl137>`__
--  `Processor SDK RTOS for
-   C6748/OMAP-L138 <http://www.ti.com/tool/processor-sdk-omapl138>`__
--  `Processor SDK RTOS for
-   K2E <http://www.ti.com/tool/PROCESSOR-SDK-K2E>`__
--  `Processor SDK RTOS for
-   K2G <http://www.ti.com/tool/PROCESSOR-SDK-K2G>`__
--  `Processor SDK RTOS for
-   K2H/K2K <http://www.ti.com/tool/PROCESSOR-SDK-K2H>`__
--  `Processor SDK RTOS for
-   K2L <http://www.ti.com/tool/PROCESSOR-SDK-K2L>`__
-
-From the appropriate software product page, go to the download page by
-clicking "Get Software" for the RTOS package.
-
-.. note::
-    -  When Installing on linux (Ubuntu 16.04 and above) the following packages need to be installed before the Procsdk RTOS installer is installed
-
-       **sudo apt install diffstat texinfo gawk chrpath dos2unix unzip socat doxygen libc6:i386 libncurses-dev:i386 libstdc++6:i386 libz1:i386**
-
-    -  To avoid configuring CCS "Tool Discovery Path" to search for
-       components in different directories, it is recommended to install the
-       SDK in the same directory as CCS. This is *C:/TI* for Windows and
-       */home/[user]/ti* for Linux.
-    -  Once installer has started, the Cancel button may not work properly.
-    -  On Ubuntu 14.04 Linux Host, if you are installing Processor SDK RTOS
-       and observe that the installer exits immediately after you try to run
-       from command line then you need resolve dependencies using
-       instructions provided here :ref:`Processor SDK RTOS_Release Notes <processor-sdk-rtos-release-notes>`
-
-|
-
-Setup EVM hardware
-===================
-
-.. Attention::
-   The EVM board is sensitive to electrostatic discharges
-   (ESD). Use a grounding strap or other device to prevent damaging the
-   board. Be sure to connect communication cables before applying power to
-   any equipment.
-
-|
-
-The EVM provides the ability to utilize a variety of capabilities of the
-SoC. Follow instructions in the included *EVM Quick Start Guide* for
-information on hardware configuration and other pertinent information.
-This guide is included in the EVM kit and also available for download
-from the software download page for your particular device. The list of
-supported EVMs are provided in the :ref:`Release Notes <RN-Supported-Platforms-label>`.
-
-If you connect to the EVM UART, use the following host configuration:
-
--  **Baud Rate**: 115200
--  **Data Bits**: 8
--  **Parity**: None
--  **Flow Control**: Off
-
-For more information beyond what is covered in the *EVM Quick Start
-Guide*, see :ref:`EVM Hardware User Guides <RTOS-SDK-Supported-Platforms>`
-
-|
-
-Setting up CCS for EVM and Processor-SDK RTOS
-==============================================
-After the Processor SDK is installed, launch Code Composer Studio and
-make sure that the components inside Processor SDK are discovered by the
-CCS eclipse environment. If you installed the SDK in the same directory
-as CCS, this is as simple as starting CCS and it will auto-detect the
-newly installed components.
-
-.. note::
-   If you installed the SDK and CCS in different paths, see the
-   `Custom Installation Path <index_how_to_guides.html#update-environment-when-installing-to-a-custom-path>`__
-   **How To** page that provides instructions to configure for a custom
-   installation path.
-
-The next step is to make a connection between CCS and your EVM (or
-*target*). If you need help with this step, see the `Setup CCS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__
-**How To** page explaining this further.
-
-At this point, you should be able to connect to target using CCS and
-start development!
-
-|
-
-Useful links
-==============
-
-- :ref:`Developer Guide <Index-Processor-SDK-RTOS-label>`
-.. note::
-   This is a good landing page to bookmark since all links below can be
-   found in the Developer Guide.
-
-
-- `Training Videos <https://training.ti.com/processor-sdk-training-series>`__
-- `Getting Started Guide <index_overview.html#getting-started-guide>`__
-
-- :ref:`Supported Platforms <RTOS-SDK-Supported-Platforms>`
-
-- `Landing Page to All Processor SDK RTOS Packages <http://www.ti.com/tool/ti-rtos-proc>`__
-- :ref:`Release Notes <processor-sdk-rtos-release-notes>`
-- `Examples and Demonstrations <index_examples_demos.html>`__
-- `FAQ <index_faq.html>`__
-|
-
-Archived
-==========
-- `Processor-SDK RTOS 4.0 <http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_Getting_Started_Guide&oldid=230434>`__
-- `Processor-SDK RTOS 3.2 <http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_Getting_Started_Guide&oldid=225568>`__
-
-|
-
diff --git a/source/rtos/Overview/_Processor_SDK_RTOS_Software_Developers_Guide.rst b/source/rtos/Overview/_Processor_SDK_RTOS_Software_Developers_Guide.rst
deleted file mode 100644
index 2880caa29..000000000
--- a/source/rtos/Overview/_Processor_SDK_RTOS_Software_Developers_Guide.rst
+++ /dev/null
@@ -1,237 +0,0 @@
-**********************************************
-Processor SDK RTOS Software Developer's Guide
-**********************************************
-
-.. note::
-   | Processor SDK documentation is now created from reStructuredText sources using
-     Sphinx, and hosted on ti.com instead of processors wiki - starting
-     4.3 release.
-   |
-   | We intend to retain the look and feel of the content
-     to make this transition seamless, and yet provide the users with the benefits of
-     consuming the content generated with emergent documentation tools.
-   |
-   | Wiki content will be left for reference during this migration process to find any missing old content. Feel free to drop us a note using the
-     forums listed at :ref:`Technical Support <overview-technical-support>`, and we would love to hear from you.
-   |
-   | Old Wiki Documentation links from previous releases:
-   |    - `Wiki Software Developer's Guide <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Software_Developer_Guide>`__.
-   |    - `Wiki Getting Started Guide <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Getting_Started_Guide>`__.
-   |
-
-.. rubric:: Introduction
-   :name: introduction
-
-The Texas Instruments Processor Software Development Kit (Processor-SDK)
-is a single scalable software platform that offers streamlined development
-across different TI `Sitara/DSP Processors <http://www.ti.com/lsds/ti/processors/overview.page>`__.
-The Processor-SDK for RTOS provides fundamental platform software and tools
-for development, deployment and execution of RTOS-based applications.
-It includes the following, though not all features are applicable across
-all supported platforms:
-
--  TI-RTOS kernel, a light-weight real-time embedded operating system for TI devices
--  Chip support libraries, drivers, and basic board-support utilities
--  Interprocessor communication for communication across cores and devices
--  Basic networking stack and protocols
--  Optimized C66x algorithm libraries
--  Debug and instrumentation utilities
--  Bootloaders and boot utilities
--  Demonstrations and examples
-
-Combined with TI Code Composer Studio integrated development environment (IDE),
-the Processor-SDK provides the core foundational building blocks that facilitate
-application software development on TI's embedded processors.
-
-.. rubric:: Scope
-   :name: scope
-
-The purpose of this guide is to quickly provide the information you need most while
-evaluating and developing applications on a TI embedded processor, specifically
-running embedded real-time operating system. It is not intended to be a thorough
-design document. As such, the focus is on application programming interfaces (API),
-build information, and examples to use as a template to start development.
-
-.. rubric:: Guides
-   :name: guides
-
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-| **Processor SDK RTOS**                                                                                                                                 |
-+========================================================================+===============================================================================+
-| |__Getting Started Guide__|  <-- **Start Here**                        | |__Release Notes__|                                                           |
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-| |__Examples and Demonstrations__|                                      | |__RTOS Software Stack__|                                                     |
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-| |__Directory Structure Overview__|                                     | |__Building the SDK__|                                                        |
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-| `Training <https://training.ti.com/processor-sdk-training-series>`__   | |__Migration Guide__|                                                         |
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-| |__Technical Support__|                                                | |__How To Guides__|                                                           |
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-| |__Related Software__|                                                 | |__Frequently Asked Questions (FAQ)__|                                        |
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-| |__Supported Platforms and Versions__|                                                                                                                 |
-+------------------------------------------------------------------------+-------------------------------------------------------------------------------+
-
-
-.. |__Getting Started Guide__| replace:: :ref:`Getting Started Guide <overview-getting-started-guide>`
-.. |__Release Notes__| replace:: :ref:`Release Notes <processor-sdk-rtos-release-notes>`
-.. |__Examples and Demonstrations__| replace:: :ref:`Examples and Demonstrations <index-examples-demos>`
-.. |__RTOS Software Stack__| replace:: :ref:`RTOS Software Stack <overview-rtos-software-stack>`
-.. |__Directory Structure Overview__| replace:: :ref:`Directory Structure Overview <overview-directory-structure>`
-.. |__Building the SDK__| replace:: :ref:`Building the SDK <overview-building-the-sdk>`
-.. |__Migration Guide__| replace:: :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>`
-.. |__Technical Support__| replace:: :ref:`Technical Support <overview-technical-support>`
-.. |__How To Guides__| replace:: :ref:`How To Guides <index-how-to-guides>`
-.. |__Related Software__| replace:: :ref:`Related Software <overview-related-software>`
-.. |__Frequently Asked Questions (FAQ)__| replace:: :ref:`Frequently Asked Questions (FAQ) <index-faq>`
-.. |__Supported Platforms and Versions__| replace:: :ref:`Supported Platforms and Versions <RTOS-SDK-Supported-Platforms>`
-
-+---------------------+---------------------+--------------------------+-------------------+
-| **Board/EVM Abstration**                                                                 |
-+=====================+=====================+==========================+===================+
-| |__Diagnostics__|   | |__Board Support__| | |__Power-On Self Test__| |                   |
-+---------------------+---------------------+--------------------------+-------------------+
-
-.. |__Diagnostics__| replace:: :ref:`Diagnostics <index-board-diagnostics>`
-.. |__Board Support__| replace:: :ref:`Board Support <board-board-support>`
-.. |__Power-On Self Test__| replace:: :ref:`Power-On Self Test <board-power-on-self-test>`
-
-+---------------------+-------------------+--------------------+--------------------+
-| **Foundational Components**                                                       |
-+=====================+===================+====================+====================+
-| |__TI-RTOS Kernel__|| |__Boot__|        | |__IPC__|          | |__MPM__|          |
-+---------------------+-------------------+--------------------+--------------------+
-| |__OpenMP__|        | |__FC__|          | |__OpenCL__|       | |__Network__|      |
-+---------------------+-------------------+--------------------+--------------------+
-| |__XDAIS__|         | |__PKTLIB__|      | |__NWAL__|         | |__Tools__|        |
-+---------------------+-------------------+--------------------+--------------------+
-
-.. |__TI-RTOS Kernel__| replace:: :ref:`TI-RTOS Kernel <foundational-components-ti-rtos-kernel>`
-.. |__Boot__| replace:: :ref:`BOOT <foundational-components-boot>`
-.. |__IPC__| replace:: :ref:`IPC <foundational-components-IPC>`
-.. |__MPM__| replace:: :ref:`MPM <foundational-components-mpm>`
-.. |__OpenMP__| replace:: :ref:`OpenMP <foundational-components-openmp>`
-.. |__FC__| replace:: :ref:`FC <foundational-components-fc>`
-.. |__OpenCL__| replace:: :ref:`OpenCL <foundational-components-opencl>`
-.. |__Network__| replace:: :ref:`Network <foundational-components-ndk>`
-.. |__XDAIS__| replace:: :ref:`XDAIS <foundational-components-xdais>`
-.. |__PKTLIB__| replace:: :ref:`PKTLIB <foundational-components-pktlib>`
-.. |__NWAL__| replace:: :ref:`NWAL <foundational-components-nwal>`
-.. |__Tools__| replace:: :ref:`Tools <foundational-components-tools>`
-
-
-+---------------------+-------------------+--------------------+--------------------+
-| **DSP Optimized Libraries**                                                       |
-+=====================+===================+====================+====================+
-| |__MATHLIB__|       | |__IMGLIB__|      | |__DSPLIB__|       | |__FFTLIB__|       |
-+---------------------+-------------------+--------------------+--------------------+
-| |__LINALG__|        |                   |                    |                    |
-+---------------------+-------------------+--------------------+--------------------+
-
-.. |__MATHLIB__| replace:: :ref:`MATHLIB <dsp-sw-dsp-optimized-libraries>`
-.. |__IMGLIB__| replace:: :ref:`IMGLIB <dsp-sw-dsp-optimized-libraries>`
-.. |__DSPLIB__| replace:: :ref:`DSPLIB <dsp-sw-dsp-optimized-libraries>`
-.. |__FFTLIB__| replace:: :ref:`FFTLIB <dsp-sw-dsp-optimized-libraries>`
-.. |__LINALG__| replace:: :ref:`LINALG <dsp-sw-dsp-optimized-libraries>`
-
-
-+---------------------+-------------------+--------------------+--------------------+
-| **DSP Debug and Trace**                                                           |
-+=====================+===================+====================+====================+
-| |__CToolsLib__|     | |__UIA__|         | |__Trace__|        |                    |
-+---------------------+-------------------+--------------------+--------------------+
-| |__Fault Mgt__|     | |__WDT__|         |                    |                    |
-+---------------------+-------------------+--------------------+--------------------+
-
-.. |__CToolsLib__| replace:: :ref:`CToolsLib <dsp-sw-ctoolslib>`
-.. |__UIA__| replace:: :ref:`UIA <dsp-sw-uia>`
-.. |__Trace__| replace:: :ref:`Trace <dsp-sw-trace>`
-.. |__Fault Mgt__| replace:: :ref:`Fault Mgt <dsp-sw-fault-management>`
-.. |__WDT__| replace:: :ref:`WDT <dsp-sw-wdt>`
-
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| **Device Drivers**                                                                                                 |
-+=============================+============================+============================+============================+
-| |__CSL__|                   | |__UART__|                 | |__USB__|                  | |__PCIe__|                 |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| |__GPIO__|                  | |__I2C__|                  | |__McSPI-QSPI-OSPI__|      | |__EDMA3__|                |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-||__ICSS-EMAC__|              | |__PRUSS__|                | |__FATFS__|                | |__MMCSD__|                |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| |__QMSS__|                  | |__CPPI__|                 | |__PA__|                   | |__SA__|                   |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| |__SRIO__|                  | |__HYPLNK__|               | |__TSIP__|                 | |__MCBSP__|                |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| |__EMAC__|                  | |__MCASP__|                | |__PM__|                   | |__RM__|                   |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| |__GPMC__|                  | |__VPS Drivers__|          | |__DSS__|                  | |__CAL__|                  |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| |__UDMA__|                  | |__SCICLIENT__|            |  |__IOLINK__|              |                            |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-
-.. |__CSL__| replace:: :ref:`CSL <device-driver-csl>`
-.. |__UART__| replace:: :ref:`UART <device-driver-uart>`
-.. |__USB__| replace:: :ref:`USB <device-driver-usb>`
-.. |__PCIe__| replace:: :ref:`PCIe <device-driver-pcie>`
-.. |__GPIO__| replace:: :ref:`GPIO <device-driver-gpio>`
-.. |__I2C__| replace:: :ref:`I2C <device-driver-i2c>`
-.. |__McSPI-QSPI-OSPI__| replace:: :ref:`McSPI-QSPI-OSPI <device-driver-mcspi-qspi-ospi>`
-.. |__EDMA3__| replace:: :ref:`EDMA3 <device-driver-edma3>`
-.. |__ICSS-EMAC__| replace:: :ref:`ICSS-EMAC(DRIVER,FIRMWARE) <device-driver-icss-emac>`
-.. |__PRUSS__| replace:: :ref:`PRUSS <device-driver-pruss>`
-.. |__FATFS__| replace:: :ref:`FATFS <device-driver-fatfs>`
-.. |__MMCSD__| replace:: :ref:`MMCSD <device-driver-mmcsd>`
-.. |__QMSS__| replace:: :ref:`QMSS <device-driver-qmss>`
-.. |__CPPI__| replace:: :ref:`CPPI <device-driver-cppi>`
-.. |__PA__| replace:: :ref:`PA <device-driver-pa>`
-.. |__SA__| replace:: :ref:`SA <device-driver-sa>`
-.. |__SRIO__| replace:: :ref:`SRIO <device-driver-srio>`
-.. |__HYPLNK__| replace:: :ref:`HYPLNK <device-driver-hyplnk>`
-.. |__TSIP__| replace:: :ref:`TSIP <device-driver-tsip>`
-.. |__MCBSP__| replace:: :ref:`MCBSP <device-driver-mcbsp>`
-.. |__EMAC__| replace:: :ref:`EMAC <device-driver-emac>`
-.. |__MCASP__| replace:: :ref:`MCASP <device-driver-mcasp>`
-.. |__PM__| replace:: :ref:`PM <device-driver-pm>`
-.. |__RM__| replace:: :ref:`RM <device-driver-rm>`
-.. |__GPMC__| replace:: :ref:`GPMC <device-driver-gpmc>`
-.. |__VPS Drivers__| replace:: :ref:`VPS Drivers <device-driver-vps-drivers>`
-.. |__DSS__| replace:: :ref:`DSS <device-driver-dss>`
-.. |__CAL__| replace:: :ref:`CAL <device-driver-cal>`
-.. |__UDMA__| replace:: :ref:`UDMA <device-driver-udma>`
-.. |__SCICLIENT__| replace:: :ref:`SCICLIENT <device-driver-sciclient>`
-.. |__IOLINK__| replace:: :ref:`IOLINK <device-driver-iolink>`
-
-
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| **Device Driver Utilities**                                                                                        |
-+=============================+============================+============================+============================+
-| |__OSAL__|                  | |__Profiling__|            |                            |                            |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-
-.. |__OSAL__| replace:: :ref:`OSAL <device-driver-osal>`
-.. |__Profiling__| replace:: :ref:`Profiling <device-driver-profiling>`
-
-
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| **PRU-ICSS Firmware**                                                                                              |
-+=============================+============================+============================+============================+
-| |__Dual EMAC and Switch__|  | |__PRU-ICSS SORTE__|       | |__PRU-ICSS I2C__|         | |__PRU-ICSS IOLINK__|      |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-
-.. |__Dual EMAC and Switch__| replace:: :ref:`Dual EMAC and Switch <pru-icss-fw-dual-emac-and-switch>`
-.. |__PRU-ICSS SORTE__| replace:: :ref:`PRU-ICSS SORTE <pru-icss-fw-pru-icss-sorte>`
-.. |__PRU-ICSS I2C__| replace:: :ref:`PRU-ICSS I2C <pru-icss-fw-pru-icss-i2c>`
-.. |__PRU-ICSS IOLINK__| replace:: :ref:`PRU-ICSS IOLINK <pru-icss-fw-pru-icss-iolink>`
-
-
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-| **Compilers**                                                                                                      |
-+=============================+============================+============================+============================+
-| |__TI C6000__|              | |__TI ARM__|               | |__TI PRU__|               | |__Linaro GCC ARM__|       |
-+-----------------------------+----------------------------+----------------------------+----------------------------+
-
-.. |__TI C6000__| replace:: :ref:`TI C6000 <compilers-ti-c6000>`
-.. |__TI ARM__| replace:: :ref:`TI ARM <compilers-ti-arm>`
-.. |__TI PRU__| replace:: :ref:`TI PRU <compilers-ti-pru>`
-.. |__Linaro GCC ARM__| replace:: :ref:`Linaro GCC ARM <compilers-linaro-gcc-arm>`
diff --git a/source/rtos/Overview/_Related_Software.rst b/source/rtos/Overview/_Related_Software.rst
deleted file mode 100644
index aec310651..000000000
--- a/source/rtos/Overview/_Related_Software.rst
+++ /dev/null
@@ -1,35 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Related_Software
-
-This section provides a collection links to additional software elements
-that may be of interest for the Processor SDK RTOS package.
-
-+-----------------------------------+-----------------------------------+
-|             Software              |            Description            |
-+===================================+===================================+
-| `PRU-ICSS Industrial              | The PRU-ICSS protocols enable     |
-| Software <http://www.ti.com/tool/ | real-time industrial              |
-| PRU-ICSS-INDUSTRIAL-SW>`__        | communications for TI Sitara      |
-|                                   | processors. Built on top of       |
-|                                   | Processor SDK, they contain       |
-|                                   | optimized PRU-ICSS firmware, a    |
-|                                   | corresponding PRU-ICSS driver for |
-|                                   | the ARM processor, and example    |
-|                                   | applications.                     |
-+-----------------------------------+-----------------------------------+
-| `Security Accelerator 3GPP        | Download page for SA 3GPP Enabler |
-| Enabler                           | designed to be used along with SA |
-| LLD <http://software-dl.ti.com/li | LLD 3.x package, delivered as     |
-| bs/sa_3gpp_enabler/latest/index_F | part of Processor-SDK-RTOS        |
-| DS.html>`__                       | release, to enable 3GPP           |
-|                                   | functionality.                    |
-+-----------------------------------+-----------------------------------+
-| `Telecom                          | TI software folder for            |
-| Libraries <http://focus.ti.com/do | information and download of       |
-| cs/toolsw/folders/print/telecomli | Telecom Libraries (Voice, Fax,    |
-| b.html>`__                        | etc) for TI processors.           |
-+-----------------------------------+-----------------------------------+
-| `c66x Speech and Video            | TI software folder for            |
-| Codecs <http://www.ti.com/tool/c6 | information and download of       |
-| 6xcodecs>`__                      | Speech and Video codecs for c66x. |
-+-----------------------------------+-----------------------------------+
-
diff --git a/source/rtos/Overview/_Software_Stack.rst b/source/rtos/Overview/_Software_Stack.rst
deleted file mode 100644
index 5b9f2ad05..000000000
--- a/source/rtos/Overview/_Software_Stack.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Software_Stack
-
-Overview
-==========
-
-The following software stack illustrates at a high level the various
-components provided with the Processor SDK for RTOS. The package
-provides well-defined API abstraction layers allowing applications to
-quickly utilize different peripherals accessible from an SOC.
-
-.. note::
-   Certain features are platform dependent and are clarified in the associated User Guides.
-
-|
-
-Software Block Diagram
-========================
-
-.. Image:: /images/RTOS-Software-Architecture.png
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM335x_AM437x.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM335x_AM437x.rst
deleted file mode 100644
index 932c0073b..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM335x_AM437x.rst
+++ /dev/null
@@ -1,849 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM335x/AM437x
-
-Overview
-^^^^^^^^^
-
-Bootloader supports power-on-reset bootstraps for the board. It
-initializes board, loads application from the memory device to DDR and
-transfers control to application. Section provides additional details
-including flashing and booting instructions across different media.
-
-Source Reference
-^^^^^^^^^^^^^^^^^^
-
-::
-
-    < BASE_DIR = PDK_INSTALL_DIR\packages\ti\starterware>
-
-
-Bootloader build files for AM335x/AM437x
-"""""""""""""""""""""""""""""""""""""""""
-
-**Source files:**
-
--  **BASE_DIR/bootloader/src**: Common source files for bootloader
-   functionality
--  **BASE_DIR/bootloader/src/<device>**: Files specific to device to
-   initialize platform features like PLL, pinmux and DDR
-
-**Build Files:**
-
--  **BASE_DIR/build/makerules/rules_a8.mk**: Common Compiler flags used
-   for A8 cores. Applies to AMIC110 and AM335x
--  **BASE_DIR/build/makerules/rules_a9.mk**: Common Compiler flags used
-   for A9 cores. Applies to AM437x devices
--  **BASE_DIR/build/makerules/platform.mk**: Global settings for all
-   components for a particular platform.
--  **BASE_DIR/build/makerules/components.mk**: Specific settings for
-   components in starterware
--  **BASE_DIR/build/makerules/build_cfg.mk**: Flags to enable features
-   in the build
--  **BASE_DIR/bootloader/Makefile**: Makefile for bootloader that
-   provides list of source files and library to create bootloader
-   binary.
-
-**Boot and flashing tools:**
-
--  **BASE_DIR/tools Contains tools to create boot images and flashing
-   tools to program the boot binary on the boot media.**
-
-|
-
-Bootloader execution sequence
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The Processor SDK RTOS boot loader uses a two stage boot process. The
-different stages of the application boot sequence using Processor SDK
-RTOS bootloader are shown below:
-
-Boot Sequence
-"""""""""""""""
-
-#. Power on Reset
-#. ROM Bootloader (RBL)
-
-   -  Platform configuration and initialization.
-
-      -  DPLL and clock settings for MPU, I2C, MMCSD, USB, SPI, QSPI,
-         Ethernet etc.
-
-   -  Checks Sysboot pins and choose booting device
-
-      -  If no valid bootloader found on booting device, RBL checks for
-         next booting device. The sequence depends on RBL execution flow
-         and Sysboot pins.
-
-   -  RBL gets image size and load address by checking TI Image Header
-      appended on bootloader binary(.bin). Check `binary
-      formats <index_Foundational_Components.html#tools-and-binary-formats>`__.
-   -  Loads the binary to internal OCMC memory at the Load address
-      fetched from TI Image Header
-   -  Passes control to Secondary Bootloader(SBL)
-
-#. Secondary Bootloader(SBL)
-
-   -  Configure PLL and Initialize DDR
-   -  Configure PRCM and PinMux  for Boot Peripherals
-   -  Copies application image to DDR
-   -  Passes execution control to Application
-
-#. Application execution
-
-Tools and Binary formats
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Binary format         | Requirement           | Details               |
-+-----------------------+-----------------------+-----------------------+
-| .bin                  | QSPI bootloader,      | QSPI bootloader       |
-|                       |                       | binary should in .bin |
-|                       | UART bootloader and   | format and            |
-|                       | app                   | Application binary    |
-|                       |                       | should be in \_ti.bin |
-|                       |                       | format.               |
-|                       |                       |                       |
-|                       |                       | UART bootloader and   |
-|                       |                       | applications are      |
-|                       |                       | loaded in .bin format |
-|                       |                       | through XMODEM in     |
-|                       |                       | terminal.             |
-+-----------------------+-----------------------+-----------------------+
-| \_ti.bin              | MMCSD bootloader      | .bin binaries are     |
-|                       | and app,              | converted to          |
-|                       |                       | \_ti.bin format by    |
-|                       | NAND bootloader and   | adding Image          |
-|                       | app,                  | size(4bytes) and      |
-|                       |                       | Image load            |
-|                       | MCSPI boot loader and | address(4bytes) as    |
-|                       | app,                  | image header.         |
-|                       |                       | Refer to Image        |
-|                       | QSPI app.             | format section in     |
-|                       |                       | Initialization        |
-|                       |                       | chapter of `AM437x    |
-|                       |                       | TRM`_                 |
-|                       |                       |                       |
-|                       |                       | MMCSD, NAND and MCSPI |
-|                       |                       | boot loaders and      |
-|                       |                       | application binaries  |
-|                       |                       | should be appended    |
-|                       |                       | with ti image header. |
-|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-
-.. _AM437x TRM: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf
-
-|
-
-**TI Boot image**
-
-+------------+----------------------------+
-| Offset     | Binary value               |
-+============+============================+
-| 0x00000000 | **Size**                   |
-+------------+----------------------------+
-| 0x00000004 | **Entry Point (Location)** |
-+------------+----------------------------+
-| 0x00000008 | **Binary (.bin)**          |
-+------------+----------------------------+
-
-.. note::
-   - For bootloader, the entry point is usually 0x402f0000
-   - For app, the entry point is usually 0x80000000.
-
-
-Binary format conversion procedure
-"""""""""""""""""""""""""""""""""""
-
-The GCC tool chain, referred as GCC_TOOLCHAIN_PATH below, is installed during
-the Processor-SDK RTOS installation. For example, Processor-SDK RTOS 6.3 has
-gcc-arm-none-eabi-7-2018-q2-update.
-
-Binary format conversion in Linux
-''''''''''''''''''''''''''''''''''
-1) To convert from .out -> .bin
-
-::
-
-    <GCC_TOOLCHAIN_PATH>/bin/arm-none-eabi-objcopy -O binary <application>.out <application>.bin
-
-2) Build tiimage.out. Go to starterware/tools/ti_image/
-
-::
-
-    gcc tiimage.c –o tiimage.out
-
-3) To convert from .bin -> \_ti.bin
-
-::
-
-    tiimage.out <Image Load Address> NONE <application>.bin <application>_ti.bin
-
-Binary format conversion in Windows
-''''''''''''''''''''''''''''''''''''
-1) To convert from .out -> .bin
-
-::
-
-    <GCC_TOOLCHAIN_PATH>/bin/arm-none-eabi-objcopy -O binary <application>.out <application>.bin
-
-2) To convert from .bin -> \_ti.bin. tiimage.exe is provided as prebuilt
-binary in starterware/tools/ti_image.
-
-::
-
-    tiimage.exe <Image Load Address> NONE <application>.bin <application>_ti.bin
-
-|
-
-Boot Modes supported
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Following are the Boot Modes supported through AM335x/AM437x bootloader
-for the various EVMs.
-
-+-----------+-----------+-----------+-----------+-----------+-----------+
-|           | **MMCSD** | **NAND**  | **McSPI** | **QSPI**  | **UART**  |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AM335x  |    YES    |    YES    |    YES    |    NO     |    YES    |
-| GPEVM**   |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AM335x  |    YES    |    NO     |    YES    |    NO     |    NO     |
-| ICEv2**   |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AM335x  |    YES    |    NO     |    NO     |    NO     |    YES    |
-| StarterKi |           |           |           |           |           |
-| t**       |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AM335x  |    YES    |    NO     |    NO     |    NO     |    YES    |
-| BeagleBon |           |           |           |           |           |
-| eBlack**  |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AMIC110 |    NO     |    NO     |    YES    |    NO     |    YES    |
-| ICE**     |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AM437x  |    YES    |    NO     |    NO     |    NO     |    YES    |
-| GPEVM**   |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AM437x  |    YES    |    NO     |    NO     |    YES    |    NO     |
-| IDK**     |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-| **AM437x  |    YES    |    NO     |    NO     |    NO     |    NO     |
-| StarterKi |           |           |           |           |           |
-| t**       |           |           |           |           |           |
-+-----------+-----------+-----------+-----------+-----------+-----------+
-
-|
-
-Building the Bootloader
-^^^^^^^^^^^^^^^^^^^^^^^
-
-**Pre-requisite:** Setup SDK build environment as described in article
- `Setup_Environment <index_overview.html#setup-environment>`__
-
-Change working directory to the packages/ti/starterware directory
-    cd <procsdk_install_dir>/pdk_<soc>_<version>/packages/ti/starterware
-
-NOTE: For the starterware build targets below, the parallel make option (-j) is not supported. Please ensure that the below are built without parallel make option.
-
-Normal Operation of Bootloader:
-"""""""""""""""""""""""""""""""""""
-
-Bootloading an application from flash into DDR memory as in case of TI
-evaluation platforms is described as normal operation mode for the
-bootloader. This is the default behavior of the bootloader and can be
-built using the following command in starterware.
-
-::
-
-    gmake bootloader BUILDCFG=boot BOOTMODE=<BOOT_MODE> PLATFORM=<EVM> PROFILE=<BUILD_PROFILE> -s KW_BUILD=no
-
--  BOOT_MODE: mcspi, nand, qspi, mmcsd, uart (Check supported boot modes
-   for your evaluation platform)
--  EVM: am335x-evm (for all AM335x/AMIC110 based boards), am43xx-evm (for all AM43xx based boards)
--  BUILD_PROFILE: debug, release
-
-Additional Build Options
-""""""""""""""""""""""""
-
-The build options listed below are currently supported only for AMIC110/AM335x ICE Users.
-
--  **DDR less Application boot setup**
-
-::
-
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=debug -s KW_BUILD=no USE_DDR=no
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=release -s KW_BUILD=no USE_DDR=no
-
-This option builds an ultra light weight (<10 KB) bootloader for cost
-optimized application that doesn't use external DDR memory.
-
--  **PRU/ICSS Enable in SBL**
-
-::
-
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=debug -s KW_BUILD=no ENABLE_PRU=yes
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=release -s KW_BUILD=no ENABLE_PRU=yes
-
-This feature is required in application that need to quick wake up of
-ICSS/PRU cores. The PRU cores can be woken up and loaded from the SBL by
-combining the ENABLE_PRU and BIN_LOAD arguments.
-
--  **Load additional binaries from flash**
-
-::
-
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=debug -s KW_BUILD=no BIN_LOAD=yes
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=am335x-evm PROFILE=release -s KW_BUILD=no BIN_LOAD=yes
-
-The location of binaries in offset is configured using
-sbl_flash_offset_cfg.h in the bootloader source. Users are required to
-use TIIMAGE tool to append an header to the binary so that the
-bootloader knows the location and size of the binary to be loaded.
-
-Special Build Option for Industrial DDRless Booting
-"""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The AMIC110 DDRLESS platform provides a superset flag to enable all the
-above features and build the bootloader. The superset build is invoked
-using **BUILD_ICSS_DDRLESS_BOOT=yes** as shown below:
-
-::
-
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=debug -s KW_BUILD=no BUILD_ICSS_DDRLESS_BOOT=yes
-    gmake bootloader BUILDCFG=boot BOOTMODE=mcspi PLATFORM=amic110-ddrless PROFILE=release -s KW_BUILD=no BUILD_ICSS_DDRLESS_BOOT=yes
-
-
-Prebuilt binaries inside the Processor SDK RTOS for AMIC110-DDRLESS will
-be configured using this option to allow for testing of cost optimized
-industrial use case.
-
-|
-
-Boot Mode settings
-^^^^^^^^^^^^^^^^^^
-
-Boot mode settings for supported AM335x and AM437x boards can be found in
-the applicable `EVM Hardware User's Guide <index_release_specific.html#supported-platforms-and-versions>`__.
-
-Boot Modes
-^^^^^^^^^^
-
-Booting Via SD Card
-"""""""""""""""""""""
-
-Booting from SD Card involves two steps.
-
-#. Preparing SD card.
-#. Booting target.
-
-Preparing SD card 
-'''''''''''''''''''
-
-#. To boot target the SD card should be bootable. Follow the steps at
-   `Creating bootable SD card in windows <index_overview.html#windows-sd-card-creation-guide>`__
-   or `Creating bootable SD card in Linux <index_overview.html#linux-sd-card-creation-guide>`__.
-#. Delete the "*MLO*" and "*app*" in the bootable SD card which are
-   created in the process of making the SD bootable.
-#. Bootloader images with ti header (<mmcsd_bootloader>_ti.bin)should be
-   renamed to "*MLO*". Bootloader images are located at
-   *<PDK_INSTALL_DIR/packages/ti/starterware/binary/bootloader/bin/<TargetType*>
-#. Similarly the converted application binary image has to be renamed to
-   "*app*" from "*<app_name>_ti.bin*"
-#. Copy both the boot loader image "*MLO*" and the application image
-   "*app*" to the SD card.
-#. The SD card is ready for use on target.
-
-Booting target
-'''''''''''''''
-
-#. Insert SD card to the base board SD slot. Connect a UART cable to a
-   host running a serial terminal application (teraterm/hyperterminal)
-   with 115200 baud, 8bit, No parity and 1 STOP bit configuration.
-#. Configure the board for SD Boot mode
-
-   #. SD instance 0 (on base board) is available in all profiles.
-   #. SD instance 0 boot mode needs to appropriately set. For SD boot to
-      be selected first, SD boot should appear first in the boot device
-      list in the boot mode. If any other boot mode is selected, even if
-      a SD boot card is inserted, and does not appear first in the list,
-      the first available sane boot image (like NAND or SPI etc) is
-      booted and SD is not selected. Only if no sane boot image is found
-      in the first devices, SD boot image will be selected.
-
-#. Once SD boot image is chosen, the *MLO* is first detected and copied
-   and executed from the OCMC0 RAM. The *MLO* then copies the
-   application image (*app*) from the card to the SDRAM and passes the
-   control to the application. If the process is successful, messages
-   identifying board and SoC will appear on the serial console.
-
-After this the application will take control and execute.
-
-**NOTE:** If board has boot mode selection pins, choose proper boot mode
-selection pins from hardware reference manuals.
-
-| If the boards have no boot mode selection pins and a valid boot image
-  is present on McSPI flash, booting will happen from McSPI flash. Erase
-  McSPI flash in such cases to boot from SD card.
-  Refer to `Booting Via McSPI <index_Foundational_Components.html#booting-via-mcspi>`__
-  for how to rease McSPI flash.
-  The boot sequence depends on ROM bootloader.
-
-
-Booting Via QSPI
-""""""""""""""""""
-
-Booting from QSPI flash involves two steps-
-
-#. Preparing Flash Device
-#. Booting target.
-
-Preparing Flash Device
-'''''''''''''''''''''''
-
-Procedure relies on contents being copied to SD card. Additional
-details below:
-
-#. Copy bootloader image(bootloader_boot_qspi_a9host_debug.bin rename)
-   and app image("<app_name>_ti.bin") into the SD card.
-   The file names have to be renamed in such a way that the length of
-   name is less than 9 characters. Any file name less than 9 characters
-   can be used.
-   Rename the bootloader file to 'boot' and application image to 'app'
-   with no extensions.
-#. Copy the 'config' file into the SD card which will contain the names
-   of the image to be flashed and the offset.
-   A sample config file can be found at
-   *<PDK_INSTALL_DIR/packages/ti/starterware/tools/qspi/config/>
-   directory*. Do not change name of the **config** file.
-   **NOTE:** "config" file can be used without any modifications if
-   bootloader and application images are renamed to "boot" and "app".
-   **NOTE:** Do not rename bootloader to be copied to SD card as
-   "*MLO*", as MMCSD bootloader expects "*MLO*" and "*app*" to boot.
-#. Now SD card contains 1)boot 2)app 3)config files.
-   config file contains the address of boot image as **0x0** and app
-   image as **0x80000**.
-   Insert it into the SD card slot.
-#. Connect the board with CCS and load the prebuilt qspi flash writer
-   application from
-   *<PDK_INSTALL_DIR/packages/ti/starterware/binary/qspi_app_flash_writer/bin/m43xx-evm>*
-#. Run the QSPI flash writer application. Following logs expected on
-   console.
-
-::
-
-    StarterWare QSPI Flash Writer!!
-    BOARDInit status [0x0]
-    SoC                   : [AM43XX]
-    Core                  : [A9]
-    Board Detected        : [IDKEVM]
-    Base Board Revision   : [UNKNOWN]
-    Daughter Card Revision: [UNKNOWN]
-    Copying boot to QSPI Flash
-    Copying app to QSPI Flash
-    Changing read to quad mode
-    Read mode has been changed to Quad mode
-    SUCCESS!!!
-    Flashing completed
-
-Booting the target.
-''''''''''''''''''''
-
-#. Connect UART cable to a host running serial terminal application
-   (teraterm/hyperterminal) with 115200 baud, 8bit, No parity and 1 STOP
-   bit configuration.
-#. After flashing successfully remove SD card and reboot to see
-   following logs
-
-::
-
-    StarterWare Boot Loader
-    BOARDInit status [0x0]
-    SoC                   : [AM43XX]
-    Core                  : [A9]
-    Board Detected        : [IDKEVM]
-    Base Board Revision   : [UNKNOWN]
-    Daughter Card Revision: [UNKNOWN]
-    Copying Header of the application image
-    Copying image from flash to DDR
-    Jumping to StarterWare Application...
-
-::
-
-     NOTE: Boot logs will appear approximately after 25 seconds on reset.
-
-::
-
-     NOTE:If there is no boot mode selection present on board, boot image will be loaded depending on ROM boot sequence
-    Example: If QSPI flash and MMCSD has valid bootloaders, on reset MMCSD boot image will be loaded following ROM Boot sequence.
-
-Booting Via UART
-""""""""""""""""""
-
-ROM and Bootloader supports XMODEM protocol with images being binary
-not requiring any additional headers. Following are steps for boot:
-
-#. Configure board for UART boot mode :
-   UART boot need to be first in the boot device list. Note: In case if
-   any other boot mode is selected, the first available boot image
-   (eg:NAND or MMCSD etc) will override. In case of no valid images,
-   UART boot will be selected.   
-
-   -  Select View->Memory Browser through CCS.   
-   -  Select address 0x44e10040.   
-   -  Write 0x19 to last 2 bytes of this memory address.(UART boot)   
-   -  Soft reset the board. This is a volatile bit which gets reset
-      after power on.
-
-#. ROM code will print "CC.." on UART console expecting Bootloader via
-   XMODEM. File can be sent via xmodem through tera-term File-> Transfer
-   -> XMODEM -> Send.
-#. On transmitting bootloader
-   image, bootloader_boot_uart_a9host_debug.bin via XMODEM, following
-   message will be expected on serial console.
-
-::
-
-    CCCCCCCCCCCCCCCCCCCCCCCCCCCC
-    StarterWare Boot Loader
-    BOARDInit status [0x0]
-     SoC                   : [AM43XX]
-     Core                  : [A9]
-     Board Detected        : [IDKEVM]
-     Base Board Revision   : [UNKNOWN]
-     Daughter Card Revision: [UNKNOWN]
-    GPIO Instance number: 0
-    Pin number: 22
-    Please transfer file:
-    CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
-
-  4.  As  a next step application binary (without header) can be sent
-via XMODEM which will lead to application start executing.
-
-Booting Via McSPI
-"""""""""""""""""""
-
-Booting from McSPI involves two steps.
-
-#. Preparing Flash Device
-#. Booting the target.
-
-.. rubric:: Preparing Flash Device
-   :name: preparing-flash-device-1
-
--  Set the appropriate bootmode if applicable for EVM. Refer to corresponding
-   hardware user's guide for bootmode settings.
-   **Note**: Most of the boards may not have switch settings.
--  Add a required target configuration in CCS depending on emulator and
-   board connected.
--  Connect target to required core. Ex: A8.
--  Load the flash writer from
-   *<PDK_INSTALL_DIR/packages/ti/starterware/tools/flash_writer/spi_flash_writer_AM335X.out*
-   onto the EVM.
--  Run the application and observe the logs on CCS console.
-
-::
-
-    Starting SPIWriter.
-    Choose Operation:
-    Enter 1 ----> To FLASH an Image
-    Enter 2 ----> To ERASE Flash
-    Enter 3 ----> To EXIT
-
--  When Flash option is chosen program prompts to enter file name.
-
-::
-
-    Enter the File Name
-
--  Provide the complete path of file
-   *bootloader_boot_mcspi_a8host_release_ti.bin* at directory
-   "binary/bootloader/bin/<PLATFORM>/<gcc/ccs>/" and hit Enter.
-
-::
-
-    Enter the Offset in bytes (in HEX)
-
--  Provide **0x00000** to flash bootloader.
-
--  Wait for few minutes as flashing is a slower process.
-
-::
-
-    Erasing flash at byte offset: xx, byte length: xxxx
-    SF: Successfully erased xxxx bytes @ xxxx
-    Writing flash at page offset: x, number of pages: xxxx
-    Flashing is in progress...
-    Verifying... Success.
-
--  Repeat the steps to load and run the flash writer, then choose the application
-   binary image <app_name>_a8host_ti.bin and enter **0x20000** as the offset.
-   Wait until the flashing completes.
-
--  Once SPI flash writing completes disconnect target.
-
-.. rubric:: Booting the target
-   :name: booting-the-target
-
-#. Connect a serial cable to a host running a serial terminal
-   application (teraterm/hyperterminal) with 115200 baud, 8bit, No
-   parity and 1 STOP bit configuration.
-#. Configure the board for SPI boot mode.
-#. On reset, ROM bootloader copies the bootloader from flash to internal
-   memory. The bootloader then copies the application image from flash
-   to DDR and passes the control to the application.
-
-|
-
-Booting Via NAND
-""""""""""""""""""
-
-Booting from NAND involves two steps.
-
-#. Preparing Flash Device
-#. Booting the target.
-
-.. rubric:: Preparing Flash Device
-   :name: preparing-flash-device-2
-
--  Configure BOOT pins for NAND according to the hardware user's guide.
--  Connect target with CCS.
--  Load the
-   *<PDK_INSTALL_DIR/packages/ti/starterware/tools/flash_writer/nand_flash_writer_AM335X.out>*
-   to target and Run. Flash writer will output messages to CCS console.
-   When it prompts for inputs, proper inputs shall be given via CCS
-   console.
--  When prompted for binary file name, update file with proper path.
--  Select option for flashing.
-
-::
-
-    Choose your operation
-    Enter 1 ---> To Flash an Image
-    Enter 2 ---> To ERASE the whole NAND
-    Enter 3 ---> To EXIT
-
--  If Option 1 is selected, enter image path to flash when prompted as
-   shown below.
-
-::
-
-    Enter image file path
-
-    Provide the complete path (e.g.
-<PDK_INSTALL_DIR/packages/ti/starterware/binary/bootloader/bin/<am335x/am437x-evm>/<compiler>/bootloader_boot_nand_a8host_<debug/release>_ti.bin)
-
--  Enter offset when prompted as shown below.
-
-::
-
-    Enter offset (in hex):
-
-|     This offset is start location from where the image should be
-  flashed.
-| NOTE:
-
-#. Use hex format
-#. If bootloader is to be flashed, provide **0x00000**. For application
-   binary, provide **0x80000**.
-
--  Select ECC for flashing.
-
-::
-
-    Choose the ECC scheme from given options
-    Enter 1 ---> BCH 8 bit
-    Enter 2 ---> HAM
-    Enter 3 ---> T0 EXIT
-    Please enter ECC scheme type:
-
-    Always select BCH8 for bootloader and application as ROM code and
-bootloader uses the BCH8 ECC scheme.
-
--  Ensure that flash info displayed by tool matches NAND flash in EVM.
--  After this tool should first erase the required region in flash and
-   then start flashing new image.
--  If flashing procedure is complete following message should be
-   displayed.
-
-::
-
-    Application is successfully flashed
-    NAND flashing successful!
-
--  Once NAND flash writing completes, disconnect from CCS.
-
-.. rubric:: Booting the target
-   :name: booting-the-target-1
-
--  Connect a UART cable to a host running a serial terminal application
-   (teraterm/hyperterminal) with 115200 baud, 8bit, No parity and 1 STOP
-   bit configuration.
--  Configure the board for NAND boot mode. Refer to corresponding
-   hardware user's guide for bootmode settings.
--  On reset, ROM detects bootloader from NAND and copies it to internal
-   memory. Bootloader then copies application image from the NAND to DDR
-   and passes control to application. If the process is successful,
-   following messages appear in serial console.
-
-::
-
-       StarterWare Boot Loader
-    BOARDInit status [0x0]
-    SoC                   : [AM335X]
-    Core                  : [A8]
-    Board Detected        : [GPEVM]
-    Base Board Revision   : [1.5]
-    Daughter Card Revision: [UNKNOWN]
-    NAND flash is connected to GPMC on this board
-    Jumping to StarterWare Application...
-
-After this application should take control and execute.
-
-Test Application
-^^^^^^^^^^^^^^^^^^
-
-The section explains steps for building and booting a sample pdk
-application for am335x or am437x using MMCSD bootloader.
-
-Test Application Image Creation
-""""""""""""""""""""""""""""""""""
-
-Follow below steps to generate the bootable application image.
-
-#. Generate .out files using steps for `Rebuilding
-   PDK <index_how_to_guides.html#rebuild-drivers-from-pdk-directory>`__. Locate .out file in directory
-   *<PDK_INSTALL_PATH/MyExampleProjects/<ExampleProjectDirectory>/Debug>*
-#. Convert files to support MMCSD boot using steps as per `Binary format
-   conversion procedure <index_Foundational_Components.html#binary-format-conversion-procedure>`__.
-#. Rename generated <Application>_ti.bin to "app".
-
-Loading Test application
-"""""""""""""""""""""""""
-
-Follow procedure to use "app" file as per section `Booting Via SD
-Card <index_Foundational_Components.html#booting-via-sd-card>`__.
-
-Usage Notes
-^^^^^^^^^^^^^
-
--  **Bootloader Memory map**
-
-The bootloader code runs from internal OCMC memory and occupies certain
-amount of OCMC memory that is not available for application to use
-during booting.
-
-Refer to the map file for the boot loader to check for latest
-information on the memory utilization in the boot loader.
-
-Location of linker command file:
-
-::
-
-    BASE_DIR\binary\bootloader\bin\<platform>\gcc
-
-After SBL execution is complete, this region can be used as per
-application requirement.
-
--  **Configuring entry point for SBL**
-
-The three files that help setup the entry point in the bootloader build
-are "PDK_INSTALL_PATH/packages/ti/starterware/soc/armv7a/gcc/sbl_init.S"
-and the linker command file
-"PDK_INSTALL_PATH/packages/ti/starterware/examples/gcc/<device>_boot.lds".
-The global symbol Entry is used to provide the entry point to the
-bootloader. The Base address of the memory section OCMCRAM (starts at 1K
-offset in OCMC RAM as defined in TRM) is then used by the tiimage or
-GPHEader tool to provide RBL the guidance to find the entry point to
-pass control. After MLO is created check the TI image format file(
-\_ti.bin) to confirm that the entry point matches the location of Entry
-symbol in the .map file.
-
-.. note::
-   The object file created by sbl_init.S should always be the first object
-   file in the link order for the symbol Entry to be placed at the BASE
-   address of the memory section SBL_MEM
-
--  **Boot image creation tools generates a large boot image if load
-   sections are fragmented**
-
-Please note that when using objcopy the compiler generates a contiguous
-binary that gets loaded by the bootloader at the location specified in
-the header appended by TIIMAGE boot utility. IF you have some code
-sections in OCMC or SRAM and some section in DDR the compiler will
-generates a binary that spans across full memory range which would be in
-order of MB or even GB size so it is recommended that you create compact
-binaries that can be loaded into memory or implement a ELF parser to
-bootloader memory sections that may be fragmented in the address space.
-you can also load separate binaries for OCMC sections and DDR memory and
-load the sections separately
-
--  **Removing Heap section from application binary to speed up boot
-   times**
-
-A common issue reported with the ARM GCC compiler is that it appends
-Heap section associated with the binary to the binary image used to
-boot. The Heap section is usually filled with zeros so can cause
-significant delay in boot times. Essentially the bootloader will be
-writing a bunch of zeros in memory so is inefficient. Following work
-around has been used to circumvent the issue
-
-**Option 1:** Eliminate the heap by using the compiler option
-"--remove-section" as described in the E2E post below:
-
-**Refer:** `E2E post to configure Heap in ARM application binary by
-adding
-"--remove-section" <https://e2e.ti.com/support/arm/sitara_arm/f/791/p/604616/2225826>`__
-
-**Example BIOS configuration:**
-
-::
-
-    var heap1 = HeapMem.create();
-    heap1.size = 256 * 1024 * 1024;
-    heap1.sectionName = ".stack";
-    Memory.defaultHeapInstance = heap1;
-
-**Compiler Setting :** --remove-section=.stack
-
-**Option 2** Configure Segment type to be "NO LOAD" in .cfg and use
-excludeSections
-
-SYSBIOS Memory map configurations allows user to specify the section
-name, length and type. by configuring the section type to "NOLOAD" and
-using excludeSection option the heap memory can be eliminated from the
-final binary.
-
-**Example BIOS configuration:**
-
-::
-
-    Program.sectMap[".biosheap"] = new Program.SectionSpec();
-    Program.sectMap[".biosheap"].runSegment = "DDR2"
-    Program.sectMap[".biosheap"].type = "NOLOAD";
-
-::
-
-    Program.sectionsExclude = ".biosheap"
-
-Alternate approach using linker command file:
-
-::
-
-     .ddr3Heap (NOLOAD):
-       {
-           *(.ddr3Heap)
-       } > HOST_DDR3
-
-.. note::
-   The approach described above helps improve boot times but Users are
-   recommended to initialize the HEAP sections to zeros post boot during
-   initialization to avoid any undesired behavior during normal operation
-   of the app
-
-Debugging application boot
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Steps to debug application boot using Processor SDK RTOS bootloader are
-discussed in the article **`Common steps to debug application
-boot <index_Foundational_Components.html#common-steps-to-debug-application-boot>`__**
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM57x.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM57x.rst
deleted file mode 100644
index d0767d1b9..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM57x.rst
+++ /dev/null
@@ -1,752 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM57x
-
-Overview
-^^^^^^^^^
-
-The Secondary Bootloader (SBL) for AM57xx device initializes the
-execution environment for multi-core application and this can be used to
-demonstrate an out-of-box experience.The section covers additional
-details including execution sequence, tools and additional flashing
-instructions.
-
-Bootloader Execution Sequence
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  **Power On Reset**
--  **ROM Bootloader (RBL)**
-
-   -  Software pre-programmed in ROM memory starts executing
-   -  Checks Sysboot pins and choose booting device
-   -  If no valid bootloader found on booting device, RBL checks for
-      next booting device.
-   -  Platform configuration and initialization.
-   -  Configures DPLL and clock settings for MPU, and boot media like
-      I2C, MMCSD, SD/MMC, SPI, QSPI, Ethernet etc for reliable boot.
-   -  The sequence depends on RBL execution flow and Sysboot pins.
-   -  RBL gets image size and load address by checking TI Image Header
-      appended on bootloader binary(.bin). Check binary formats.
-   -  Loads the binary to internal memory at the Load address fetched
-      from TI Image Header
-   -  Passes control to Secondary Bootloader(SBL)
-
-.. note::
-   Detailed description of ROM bootloader is provided in Initialization
-   Chapter in `AM57xx Technical Reference
-   manual <http://www.ti.com/lit/pdf/spruhz6>`__
-
--  **Secondary bootloader(SBL)**
-
-   -  User level secondary bootloader(SBL) begins execution from
-      internal memory by running basic initialization routines like
-      setting up Stack, BSS and then jumps to main() to begin Board
-      Initialization.
-   -  Board Initialization is done by a call to **Board_init()** API.For
-      additional details refer `Processor SDK Board
-      Support <index_board.html#board-support>`__.
-   -  It includes setting up PLLs, enabling clocks to all interfaces and
-      modules, performing pinmux and setting up UART console.
-   -  Once Board Initialization is complete, it enables clocks to the
-      target cores like C66x/DSP, IPU, etc and brings them out of reset.
-   -  Parses Multicore Application image located in memory device and
-      copies it to DDR memory based on load address for different
-      sections.
-   -  Once copy is successful it transfers control to application.
-
--  **Application then starts executing from DDR**.
-
-.. note::
-
-    -  RBL requires boot loader to be in a special format with a header
-       appended to the binary image. The header shall contain the load
-       address of the bootloader and size of the bootloader image.
-    -  For more information on the TI header refer TRM document
-
-Directory structure
-^^^^^^^^^^^^^^^^^^^^
-
-**Makefiles:**
-
--  **PDK_INSTALL_PATH/ti/boot/sbl/board/<EVAL_BOARD>/build**: Makefile
-   for bootloader that provides list of source files and library and
-   compiler options to create bootloader binary.
-
-**Source Files:**
-
--  **PDK_INSTALL_PATH/ti/boot/sbl/board/<EVAL_BOARD>**: Source to SBL
-   main function that consolidates all features
--  **PDK_INSTALL_PATH/ti/boot/sbl/soc**: Source to SOC specific
-   initialization used in the SBL.
--  **PDK_INSTALL_PATH/ti/boot/sbl/src**: Source to boot media specific
-   initialization used in the SBL.
-
-|
-
-Tools and Binary Formats
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section lists out the various tools and scripts used by SBL for
-different boot modes and those required to create a bootable application
-image.
-
-**SBL/MLO image format:**
-To generate the *MLO*, SBL uses tiImageGen tool to prepend the sbl.bin
-image with the TI header information. The image format has been
-described in detail in the Image Format Section of the\ `AM57xx
-Technical Reference manual <http://www.ti.com/lit/pdf/spruhz6>`__
-
-|
-**Application image format:**
-A bootable application image can be created by using the Am57xImageGen
-script provided under tools folder as part of sbl. It can be located at
-*<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/scripts* folder.
-
-The Am57xImageGen script uses out2rprc and multicoreImageGen format
-conversion tools to create the final application image. Graphical view
-of the multicore application image is provided below:
-
-.. Image:: /images/Multicore_app_image.png
-
-The script creates the bootable image in 2 steps
-
-**Step 1: Conversion to RPRC format conversion**
-
--  Firstly, application executable is converted from ELF/COFF format
-   (.out) to custom TI Rprc binary image using out2rprc tool. This tool
-   strips out the initialized sections from the executable file (i.e.
-   \*.out) and places them in a compact format that the SBL can
-   understand. The output (bin) file is typically much smaller than the
-   original executable (out) file.
--  The rprc files are intermediate files in a format that is consumed by
-   MulticoreImageGen tool that generates the final binary.
-
-**RPRC File Header Format**
-
-+------------+----------------------------+
-| Offset     | Binary value               |
-+============+============================+
-| 0x00000000 | **Magic Word(43525052)**   |
-+------------+----------------------------+
-| 0x00000004 | **Entry Point (Location)** |
-+------------+----------------------------+
-| 0x00000008 | **Reserved Addr**          |
-+------------+----------------------------+
-| 0x0000000C | **Section Count**          |
-+------------+----------------------------+
-| 0x00000010 | **Version**                |
-+------------+----------------------------+
-
-**RPRC Section Header Format**
-
-+------------+---------------------------+
-| Offset     | Binary value              |
-+============+===========================+
-| 0x00000000 | **Section start Address** |
-+------------+---------------------------+
-| 0x00000004 | **Reserved Addr**         |
-+------------+---------------------------+
-| 0x00000008 | **Size**                  |
-+------------+---------------------------+
-| 0x0000000C | **Reserved CRC**          |
-+------------+---------------------------+
-| 0x00000010 | **Reserved**              |
-+------------+---------------------------+
-
-|
-**Step 2: Multicore Image file generation**
-
--  RPRC files for each cores is combined into a single multicore
-   bootable application image.
-
-**Multicore boot image format**
-
-**Meta Header Start**
-
-+------------+-------------------------------+
-| Offset     | Binary value                  |
-+============+===============================+
-| 0x00000000 | **Magic String (0x5254534D)** |
-+------------+-------------------------------+
-| 0x00000004 | **Number of Files**           |
-+------------+-------------------------------+
-| 0x00000008 | **Device ID**                 |
-+------------+-------------------------------+
-| 0x0000000C | **Reserved**                  |
-+------------+-------------------------------+
-
-**Meta Header per Core**
-
-+------------+------------------+
-| Offset     | Binary value     |
-+============+==================+
-| 0x00000000 | **Core ID**      |
-+------------+------------------+
-| 0x00000004 | **Image Offset** |
-+------------+------------------+
-
-Core ID and Device ID for specific devices can be located in the file
-sbl_target_core_boot.h in the boot/sbl/soc/<SOC_NAME> folder
-
-Refer section `App Image
-Creation <index_Foundational_Components.html#application-image-creation>`__
-for more details on usage of this script and application image creation.
-
-**Flashing Tools**
-
-
-SBL provides a CCS based qspi flash writer utility to flash image and
-multicore AppImage from a SD card to onboard QSPI device. It
-is located at *<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/qspi*
-
-
-Building the SBL
-^^^^^^^^^^^^^^^^^^^^
-
-**Pre-requisites to Building**
-
--  Set your environment using pdksetupenv.bat or pdksetupenv.sh. Refer
-   to the Processor SDK RTOS Building page for information on setting up
-   your build environment
--  The SBL has following dependencies and will need the following
-   libraries built
-
-   -  Board
-   -  UART
-   -  I2C
-   -  SPI
-   -  CSL
-   -  OSAL
-   -  MMCSD
-   -  PM
-
-.. note::
-   Refer to the makefile for the board you are using for the latest driver
-   dependency. These libraries should come pre-built with any fresh
-   installation of the Processor SDK RTOS but may be removed if a gmake
-   clean is invoked
-
-**Compiling the SBL Components**
-
-To build the SBL components:
-
-#. **cd <PDK>/packages**
-#. **Run pdksetupenv script**
-#. **make all -C ti/boot/sbl BOARD=<BOARD_NAME> SOC=<SOC_NAME> BOOTMODE=<BOOTMEDIA>**
-
--  BOARD_NAME : idkAM572x, idkAM571x, evmAM572x, idkAM574x
--  SOC_NAME : AM572x, AM571x, AM574x
-
-SBL can be built for all the AM57x platforms using below command
-
-#. **cd <PDK>/packages**
-#. **Run pdksetupenv script**
-#. **cd <PDK>/packages/ti/boot/sbl**
-#. **make all_sbl_images SBL_PLATFORM=am57xx**
-
-This will make the SBL for a specific $BOARD and $BOOT_MEDIA. Output
-files will be located in: **<PDK>/packages/ti/boot/sbl/binary/<BOARD>**
-
-.. note::
-   Refer **<PDK>/packages/ti/boot/sbl/sbl_<DEVICE>.sh** for more build
-   options
-
-
-.. rubric:: Boot Modes
-   :name: boot-modes
-
-This Release of SBL supports MMCSD and QSPI Boot modes. The different
-boot modes supported for all the boards is tabulated in the table below.
-
-+-----------------------+--------+------+------+
-|                       | MMCSD  | QSPI | eMMC |
-+-----------------------+--------+------+------+
-| AM572x GPEVM          |  YES   | NO   | YES  |
-+-----------------------+--------+------+------+
-| AM572x IDKEVM         |  YES   | YES  | NO   |
-+-----------------------+--------+------+------+
-| AM571x IDKEVM         |  YES   | YES  | NO   |
-+-----------------------+--------+------+------+
-| AM574x IDKEVM         |  YES   | YES  | NO   |
-+-----------------------+--------+------+------+
-
-|
-
-Booting Via SD Card
-""""""""""""""""""""""
-
-#. Preparing the SD card.
-#. Booting the target.
-
-Preparing the SD card 
-'''''''''''''''''''''''
-
-#. To boot the target the SD card should be bootable. Follow the steps
-   at `Creating bootable SD card in windows <index_overview.html#windows-sd-card-creation-guide>`__
-   or `Creating bootable SD card in Linux <index_overview.html#linux-sd-card-creation-guide>`__.
-#. Delete the "MLO" and "app" in the bootable SD card which are created
-   in the process of making the SD bootable.
-#. Copy the sbl binary(MLO) to the SD card.
-#. Copy the Application image(app) generated using the
-   `Script <index_Foundational_Components.html#application-image-creation>`__
-   to the SD card.
-
-Booting the target
-''''''''''''''''''''
-
-#. Insert micro SD card into the SD card slot of the board.
-#. Open a serial communication terminal like TeraTerm, MiniCom on host
-   PC and connect to the UART console port
-#. Do a power reset of the board to boot the appliation from the SD
-   card.
-
-Booting Via eMMC
-""""""""""""""""""""""
-
-#. Preparing the eMMC.
-#. Booting the target.
-
-Preparing the eMMC 
-'''''''''''''''''''
-
-#. To format the eMMC of the target board, Run the following application on the target board
-   `USB_DevMsc_mmcsd <Device_Drivers.html#id6>`__ .
-#. To boot the target the eMMC should be bootable. Follow the steps same as SD card
-   formatting as given
-   at `Creating bootable SD card in windows <Overview.html#windows-sd-card-creation-guide>`__
-   or `Creating bootable SD card in Linux <Overview.html#linux-sd-card-creation-guide>`__
-   except instead of SD card, connect the target board eMMC to the host PC.
-#. Delete the "MLO" and "app" in the bootable eMMC which are created
-   in the process of making the eMMC bootable.
-#. Copy the sbl binary(MLO) to the eMMC.
-#. Copy the Application image(app) generated using the
-   `Script <Foundational_Components.html#application-image-creation>`__
-   to the eMMC.
-
-Booting the target
-''''''''''''''''''''
-
-#. Set boot settings to eMMC by selecting J3, J4 and J6 jumpers on Pin 2 and 3
-   of AM572x EVM Board.
-#. Ensure there is no SD card inserted in the SD card slot.
-#. Open a serial communication terminal like TeraTerm, MiniCom on host
-   PC and connect to the UART console port
-#. Do a power reset of the board to boot the appliation from the eMMC.
-
-Booting Via QSPI
-""""""""""""""""""
-Booting from QSPI flash involves two steps-
-
-#. Flashing bootloader and app image to QSPI flash.
-#. Booting the target.
-
-Preparing Flash Device
-''''''''''''''''''''''''
-
-Use the CCS based qspi_flash_writer.out utility provided in
-<*TI_PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashwriter/qspi/<Board>'*
-to flash the SBL image at offset 0 and application image at offset
-0x80000 to the QSPI device.
-
-QSPI device Memory Map:
-
-+----------------+-----------------------------+
-| Offset 0x00    | SBL                         |
-+----------------+-----------------------------+
-| Offset 0x80000 | Application Multicore Image |
-+----------------+-----------------------------+
-
-The images can be flashed into QSPI flash by following steps given
-below.
-
-#. Copy QSPI mode SBL image
-   *<TI_PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/<BoardName>/qspi/bin/MLO*
-   and application image(app) generated using the Script into the SD
-   card.
-   Rename the bootloader file to 'boot' and application image to 'app'
-   with no extensions. 
-#. Copy 'config' file into the SD card, the config file should contain
-   names of the image to be flashed and the offset.
-   A sample config file can be found at
-   *<TI_PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/qspi/config*.
-   Do not change the name of the config file.
-   **NOTE:** "config" file can be used without any modifications if
-   bootloader and application images are renamed to "boot" and "app".
-   **NOTE:** Do not rename the bootloader to be copied to SD card as
-   "MLO", as MMCSD bootloader expects "MLO" and "app" to boot.
-#. Now SD card contains 3 files 1)boot 2)app 3)config files.
-   config file contains the address of boot image as 0x0 and app image
-   as 0x80000.
-   Insert it into the SD card slot.
-#. Connect the board with CCS and and load the prebuilt qspi flash
-   writer application from
-   <TI_PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/qspi/bin/<BoardName>
-#. Run the QSPI flash writer application. You will see the following
-   logs on the EVM's UART console.
-#. After the images have been flashed to the QSPI device disconnect from
-   CCS and do a power reset to boot from the QSPI memory. 
-
-::
-
-    PDK QSPI Flash Writer!!
-    Copying boot to QSPI Flash
-    Copying app to QSPI Flash
-    Changing read to quad mode
-    Read mode has been changed to Quad mode
-    SUCCESS!!!
-    Flashing completed
-
-
-.. note::
-
-   -  The file names have to be renamed in such a way that the length of
-      name is less than 9 characters. Any file name less than 9 characters
-      can be used.
-   -  This application will flash the image at required offset without
-      taking into consideration any overwriting to previously flashed
-      image.
-   -  It is the responsibility of the user to provide proper offsets.
-
-
-Test Application
-^^^^^^^^^^^^^^^^^^
-
-SBL provides a test application to demonstrate booting of multicore
-application image on A15 and DSP cores.The multicore sample
-application uses mailbox for inter-processor communication. It is used
-to validate the multi-core boot-up use case.
-
-Master application sends wake-up message to the DSP target cores & waits
-for acknowledgement message from the target cores in an infinite
-loop.Each target DSP core waits for wake-up message from the master core 
-responds back with an acknowledgement message.
-
-Application Image Creation
-"""""""""""""""""""""""""""""
-Application Image creation involves two steps.
-
-#. Generating the .outs of applications for individual cores
-#. Combining the .outs of individual cores to create a bootable
-   multicore image
-
-The steps to create the bootable image in Linux and Windows environment
-are listed below.
-
-.. note::
-   -  Valid SOC settings are AM571x/AM572x
-   -  Valid BOARD settings are evmAM572x/idkAM571x/idkAM572x
-
-Linux Environment
-"""""""""""""""""""
-Command to build the test application.
-
-::
-
-    Go to cd (TI_PDK_INSTALL_DIR)\packages\ti\boot\sbl
-
-    make example BOARD=<BOARD> SOC=<SOC> to build the application
-    make example_clean BOARD=<BOARD>
-
-Example:
-
-::
-
-    make example BOARD=idkAM572x SOC=AM572x
-
-To create the final bootable application image use the AM57xImageGen
-script and follow these steps
-
-1. Set the following environment variable in the shell.  BIN_PATH:
-Pointing to the path where the AppImage needs to be generated
-
-::
-
-    Ex: export BIN_PATH=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary
-
-2. Edit the script file to point to the application elf files by setting
-the input application variables. 
-
-App_MPU_CPU0: Point to the path where the application .out for A15 MPU is located
-App_DSP1: Point to the path where the dsp core 1 application is located
-App_DSP2: Point to the path where the dsp core 2 application is located
-
-::
-
-    export APP_MPU_CPU0=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/armv7/bin/sbl_app.out
-
-    export APP_DSP1=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/c66/dsp1/bin/sbl_app.xe66
-
-    export APP_DSP2=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/c66/dsp2/bin/sbl_app.xe663
-
-    export APP_IPU1_CPU0=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/m4/ipu1/bin/sbl_app.xem4
-
-    export APP_IPU1_CPU0=$(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/idkAM572x/example/m4/ipu2/bin/sbl_app.xem4
-
-3. If it is not required to load an application on specific core leave
-the variable blank.
-
-4. Run the script file AM57xImageGen found under the path $(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/tools/scripts
-
-5. An application image by name app is created in the path pointed by
-BIN_PATH variable
-
-6. Copy the Bootlaoder image(MLO) and application(app) in the SD card to
-boot using MMCSD boot mode.
-
-.. note::
-
-   -  The AM57xImageGen.sh script depends on tools like mono to execute the
-      out2rprc.exe.
-   -  The linux host environment needs to have this tool installed to
-      execute this script.
-   -  Refer this link to download the
-      `mono <http://www.mono-project.com>`__ tool
-
-Windows environment
-"""""""""""""""""""""
-Command to build the test application.
-
-::
-
-    Go to cd (TI_PDK_INSTALL_DIR)\packages\ti\boot\sbl
-
-    gmake example BOARD=<BOARD> SOC=<SOC> to build the application
-    gmake example_clean BOARD=<BOARD>
-
-Example:
-
-::
-
-    gmake example BOARD=idkAM572x SOC=AM572x
-
-To create the final bootable application image use the AM57xImageGen
-script and follow these steps
-
-1. Set the following environment variable in windows command prompt
-
-BIN_PATH: Pointing to the path where the AppImage needs to be generated 
-
-::
-
-    Ex:  set BIN_PATH=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary
-
-2. Edit the batch file to point to the application elf files by setting
-the input application variables.
-
-App_MPU_CPU0: Point to the path where the application .out for A15 MPU is located
-App_DSP1: Point to the path where the dsp core 1 application is located
-App_DSP2: Point to the path where the dsp core 2 application is located
-
-::
-
-    set App_MPU_CPU0=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\armv7\bin\sbl_app.out
-
-    set App_DSP1=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\c66\dsp1\bin\sbl_app.xe66
-
-    set App_DSP2=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\c66\dsp2\bin\sbl_app.xe66
-
-    set App_IPU1_CPU0=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\m4\ipu1\bin\sbl_app.xem4
-
-    set App_IPU2_CPU0=%TI_PDK_INSTALL_DIR%\packages\ti\boot\sbl\binary\idkAM572x\example\m4\ipu2\bin\sbl_app.xem4
-
-3. If it is not required to load an application on specific core leave
-the variable blank.
-
-4. Run the batch file AM57xImageGen found under the path $(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/tools/scripts
-
-5. Follow the steps 4 to 6 listed above for Linux environment.
-|
-Setup Requirements
-""""""""""""""""""""
-For information on board specific requirements like power supply, UART
-console port connections refer the Hardware User guide of the respective
-boards.
-
-The configurations needed to setup UART console through a serial
-terminal application on host PC are listed in the next section.
-
-UART Console Setup
-'''''''''''''''''''
-PDK SBL prints messages on the UART Serial Console running on the host.
-Hence, a serial terminal application (like Tera
-Term/HyperTerminal/minicom) should be running on the host.
-
-The host serial port must be configured at 115200 baud, no parity, 1
-stop bit and no flow control.
-Please ensure that the local echo setting for the terminal is turned off.
-
-Loading the test application
-''''''''''''''''''''''''''''''
-Follow these steps to load the test application using a SD card on the
-target
-
-copy the MLO to your SD card (located
-at $(TI_PDK_INSTALL_DIR)/packages/ti/boot/sbl/binary/[BOARD]/mmcsd)
-
-#. copy the example app located at path pointed to by BIN_PATH to your
-   SD card
-#. insert your SD card into your board and power on your board
-#. open teraterm to connect to the board's UART console
-#. press the "Hard Reset" button on your board
-
-On Successful bootup you should see the following logs on the UART
-console for a AM572x based board.
-
-.. Image:: /images/Sbl_example.jpg
-
-.. note::
-   MPU Core 0 example does a sequential check of mailbox messages sent from
-   the other cores. On rare occasions, the check happens before the message
-   is sent - the "<core> boot-up Successful" message might not be displayed
-   even though the core(s) were booted successfully.
-
-Application Integration
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Memory Map
-""""""""""""
-
-Table indicated below provides memory map details for SBL image in
-OCMC_RAM1.  For more details on pinmux and IO delay requirements refer
-this link `Processor SDK Board
-Support <index_board.html#board-support>`__
-
-We recommend that users should refer to the linker command file and the
-map file for the boot loader to check for latest information on the
-memory utilization in the boot loader.
-
-**Location of linker command file**:
-<PDK_INSTALL_PATH>/packages/ti/boot/sbl/board/<BOARD>/build
-
-The SBL memory map is shown below
-
-.. Image:: /images/SBL_memory_map.png
-
-..  note::
-   -  After the application boots and is running on the SOC, it is free to
-      use the SBL_MEM region.
-   -  The pinmux data from the board library and MMU Table are part of the
-      SBL_MEM region indicated in the figure above. If pinmux data needs to
-      be placed at a specific location then users can update the SBL linker
-      command file to add the BOARD_IO_DELAY_CODE and BOARD_IO_DELAY_DATA
-      as described in `Application Integration of board library for
-      AM5x <index_board.html#application-integration-for-am5x-dra7xx>`__
-
-
-SBL Customization
-^^^^^^^^^^^^^^^^^^^
-
-Changing boot media offsets
-"""""""""""""""""""""""""""""
-The location at which SBL resides on the flash is predefined by the ROM
-bootloader spec and so these defaults can`t be changed. However the SBL
-is a user defined bootloader so many of the defaults can easily be
-modified to meet application requirements. For example the flash offset
-location from which the bootloader reads the application is configured
-in the source files located under
-<PDK_INSTALL_PATH>/packages/ti/boot/sbl/src/<BOOT_MEDIA>
-
-Examples of customization that can be changed:
-
-- QSPI/SPI flash offsets: These offsets are configured in sbl_qspi.c and
-  sbl_spi.c
-
-- MMCSD: The name of the application is hard coded as app in function
-  SBL_MMCBootImage in the sbl_mmcsd.c
-
-Speeding up boot by increasing speed of the boot interface
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-The SBL for AM57xx devices uses LLD drivers to read and write from boot
-media supported. The SBL uses the default SOC configuration of the
-drivers and the speeds setup. For example, the SPI driver default SPI
-bitrate is 1 MHz (Refer
-<PDK_INSTALL_PATH>/packages/ti/drv/spi/src/SPI_drv.c) so if you wish to
-speed up boot you can update the SPI parameter in the SBL as shown
-below:
-
-::
-
-     SPI_Params_init(&spiParams);
-     spiParams.bitRate = 24000000U;
-
-The configuration of the driver is usually done in the
-boot/sbl/soc/<device>/sbl_soc.c file.
-
--  **For SD/MMC**: You can configure higher speed and change bus width
-   using MMCSD_v1_HwAttrs_s or MMCSD_v0_HwAttrs_s
--  **For QSPI**: 2 pin and 4 pin mode, and input frequency is configured
-   using QSPI_HwAttrs in the QSPI driver. Check driver for defaults.
-
-Also, check to see if the CACHE and MMU settings for the ARM core are
-setup to enable fast boot.
-
-.. note::
-   **SYSBOOT settings for AM57xx**
-
-   The SYSBOOT configuration in your hardware using Sitara devices
-   (AM3/AM4/AM5) can play a big role in the time required to boot
-   successfully. On these devices the boot pins configure a boot sequence
-   for the ROM bootloader to check for valid boot image so if you have a
-   preferred boot mode designers are required to use SYSBOOT setup such
-   that the preferred boot media is first in the boot sequence. If the
-   preferred boot media occurs later boot sequence, the boot is likely to
-   add the time required by RBL to check other boot media for an valid
-   image. For example if QSPI is the preferred boot media on your AM57xx
-   hardware then you should have system configure SYSBOOT to boot of QSPI
-   first using SYSBOOT setting for QSPI_1 or QSPI4 for Memory preferred
-   booting or Production booting (Refer: Initialization chapter in
-   TRM).Incorrect SYSBOOT configuration can causes long delays especially
-   if peripheral boot is configured to be one of the preferred boot modes
-   in the boot order
-
-
-Reducing size of SBL and application
-"""""""""""""""""""""""""""""""""""""
-Another way to optimize boot times is to reduce the size of the binary
-that needs to be loaded by the bootloader by building the app with
-optimization for code size using -Os (GNU GCC) and for -O<level> when
-using TI compilers.
-
-Other than compiler based optimizations developers can actively shutdown
-non-essential modules and features to reduce code size. For example if
-UART logging is not required or DDR memory is not connected in the
-system, the initialization functions can be removed to reduce code size.
-
-Usage Notes
-^^^^^^^^^^^^^
-
-SBL AVS and ABB setup
-""""""""""""""""""""""
-AVS and ABB configuration is mandated for normal operation of AM57xx
-devices. All Processor SDK RTOS releases v3.3 and later contain SBL that
-sets up AVS and ABB configuration features using PM LLD APIs The
-complete details of PMIC configuration and AVS and ABB configuration
-required by the chip for different OPP has been implemented in the file:
-
-<PDK_INSTALL_PATH>/packages/ti/boot/sbl/board/src/sbl_avs_config.c If you
-are using the same PMIC as GP EVM or IDK platform then you can reuse the
-settings as is in SBL for your custom platform
-
-Configuring entry point for SBL
-""""""""""""""""""""""""""""""""
-
-The two key files that help setup the entry point in the SBL build are
-"sbl/soc/<SOC_NAME>/sbl_init.S" and the linker command file
-"sbl/soc/<SOC_NAME>/linker.cmd". The global symbol Entry is used to
-provide the entry point to the SBL. The Base address of the memory
-section SBL_MEM is then used by the tiimage and GP Header tool to
-provide RBL the guidance to find the entry point to pass control. After
-MLO is created check the TI image format file(MLO or \_ti.bin) or the GP
-Header file to confirm that the entry point matches the location of
-Entry symbol in the sbl.map
-
-.. note::
-   The object file created by sbl_init.S should always be the first object
-   file in the link order for the symbol Entry to be placed at the BASE
-   address of the memory section SBL_MEM
-
-
-Debugging application boot
-""""""""""""""""""""""""""""
-Steps to debug application boot using Processor SDK RTOS bootloader are
-discussed in the article `Common steps to debug application
-boot <index_Foundational_Components.html#common-steps-to-debug-application-boot>`__
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM65x_J721E.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM65x_J721E.rst
deleted file mode 100644
index c7f930335..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM65x_J721E.rst
+++ /dev/null
@@ -1,832 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM65x_J721E
-
-Overview
-^^^^^^^^^
-
-The Secondary Bootloader (SBL) for AM65xx/J721E device initializes the execution
-environment for multi-core applications and this can be used to demonstrate
-a real world product experience. This section covers additional details
-including execution sequence, tools and additional flashing instructions.
-
-The SBL is essentially a baremetal application, and it uses many components
-from the Processor SDK
-
-- <PDK>/packages/ti/build : For  build infrastructure
-- <PDK>/packages/ti/csl : For initialization and SoC addresses
-- <PDK>/packages/ti/board : For board and usecase specific initialization
-- <PDK>/packages/ti/drv/spi :  For reading applications from OSPI flashes
-- <PDK>/packages/ti/drv/udma :  For reading data from boot media using DMA
-- <PDK>/packages/ti/drv/mmcsd : For reading applications from MMC/SD/eMMC
-- <PDK>/packages/ti/fs/fatfs : For reading files from MMC/SD/eMMC
-- <PDK>/packages/ti/drv/sciclient : For communicating with DMSC sub-system
-- <PDK>/packages/ti/drv/uart : For log messages
-- <PDK>/packages/ti/osal : Primitives required by ti/drv components
-
-The SBL is in turn used by the board framework to load and start diagnostics
-
-
-.. rubric:: Bootloader Execution Sequence
-   :name: bootloader-execution-sequence
-
--  **Power On Reset**
--  **ROM Bootloader (RBL)**
-
-   -  Software pre-programmed in AM65xx/J721E ROM memory starts executing
-   -  The RBL performs platform configuration and initialization.
-   -  It then checks sysboot pins and chooses booting device
-   -  The RBL then configures PLL and clock settings for R5, and
-      boot media like eMMC, SD/MMC, OSPI, UART, PCIe, Ethernet etc for reliable
-      boot.
-   -  If no valid bootloader found on booting device, the RBL checks for next
-      booting device, based on sysboot pins
-   -  It then gets image size and load address by checking the X.509 certificate that
-      is part of the bootloader image.
-   -  The RBL then verifies, optionally decrypts and loads the binary to internal
-      memory at the load address specified in the X.509 certificate.
-   -  Finally it resets the R5 and passes control to Secondary Bootloader(SBL) running on the R5.
-
--  **Secondary bootloader(SBL)**
-
-   -  User level secondary bootloader(SBL) begins execution from internal memory.
-      It enables ATCM, starts PMU timers for profiling, initializes the MCU,
-      and sets up the stack, heap and globals. It then jumps to main().
-   -  Board Initialization is done by calls to **Board_init()** API.For additional
-      details refer `Processor SDK Board Support
-      <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Board_EVM_Abstration.html>`__.
-   -  The RAT is setup. Pin MUX and UART console are setup by calling **Board_init()** API. The
-      system firmware (SYSFW) is then loaded from the boot media into the DMSC subsystem.
-   -  Once the SYSFW is up and running, the rest of the initialization can be done.
-   -  This includes optionally using **Board_init()** to configure PLLs, LPSCs and DDR.
-   -  The SBL then loads the application from the boot media. If the image is signed, the
-      application will be copied into a user specified reserved memory, and the SBL will attempt
-      to verify the image by calling system firmware APIs. On HS devices, the boot proceeds
-      only if image verification passes.
-   -  The SBL parses application image(s) for each of the core(s) from boot
-      media and scatter loads it to memory.
-   -  Once the application is loaded, the SBL communicates with the system firmware
-      to setup the clocks for the core(s) and release it from reset.
-   -  The core then starts executing from application entry point.
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-
--  RBL requires boot loader (SBL) to be in a special format with the binary image
-   appended to a X.509 certificate. The certificate contains the load address, size
-   and SHA of the bootloader image.
--  For a detailed description of ROM bootloader and more information on the image
-   format expected by the RBL refer the initialization chapter in the `AM65xx Technical
-   Reference Manual <http://www.ti.com/lit/pdf/spruid7>`__ and the `J721E Technical
-   Reference Manual <http://www.ti.com/lit/pdf/spruil1>`__
--  In addition to the bootloader and application, the DMSC firmware binary is also needed
-   for the SoC to complete the system boot flow.
--  The first 256 bytes of the ATCM are reserved by SBL for its use. The SBL initializes
-   the ATCM with 0xFF before it uses it.
--  If the multicore application image is signed using the TI Dummy Key, instead of a
-   degenerate key (default setting) the same binary can be used on GP and HS devices.
-   For information on the application's X.509 certificate format, please refer
-   `Security X509 Certificate Documentation <http://downloads.ti.com/tisci/esd/latest/
-   2_tisci_msgs/security/sec_cert_format.html#security-x509-certificate-documentation>`__
--  When the R5 is released from reset, it will always fetch and execute the first
-   intruction from address 0x0.
-
-.. raw:: html
-
-   </div>
-
-.. _am655x-sbl-high-level-arch:
-
-Block Diagram
-^^^^^^^^^^^^^^^^
-
-.. Image:: /images/k3_sbl_arch_block_diag.png
-
-.. _am655x-sbl-memory-usage:
-
-Memory Map
-^^^^^^^^^^^
-
-.. Image:: /images/k3_sbl_mem_usage.png
-
-
-.. _am655x-sbl-directory-structure:
-
-Directory structure
-^^^^^^^^^^^^^^^^^^^^
-
-::
-
-    sbl
-    │
-    ├── board
-    │   └── k3
-    │       └── sbl_main.c					<= define main() for SBL, board specific init
-    │
-    ├── build
-    │   ├── makefile						<= makefile for the SBL component
-    │   ├── sbl_am65xx.sh					<= For legacy, called by Yocto build
-    │   ├── sbl_boot_test.mk					<= Builds SBL single core tests
-    │   ├── sbl_smp_test.mk					<= Builds example app for using SBL lib
-    │   ├── sbl_mcu0_boot_perf_test.mk				<= Builds example app for SBL performance tuning
-    │   ├── sbl_mcu0_boot_xip_entry.mk				<= Builds example trampoline app to demonstrate transitioning to a XIP app from SBL
-    │   ├── sbl_mcu0_boot_xip_test.mk				<= Builds example app to demonstrate XIP execution from XIP capable boot media
-    │   ├── sbl_img.mk						<= builds SBL image that is loaded and executed by ROM code
-    │   ├── sbl_lib.mk						<= Builds sbl library that other apps can link into
-    │   ├── sbl_multicore_smp.mk				<= Builds multi-core image from SBL lib eg. test to demonstrate symmetric multiprocessor boot (SMP)
-    │   └── sbl_multicore_amp.mk				<= Builds multi-core image from single core tests to demonstrate asymmetric multiprocessor boot (AMP)
-    │
-    ├── example
-    │   └── k3MulticoreApp
-    │       ├── binary
-    │       │   └── [soc]
-    │       │       ├── sbl_baremetal_*.appimage 		<= SBL loadable board specific sample apps for testing SBL boot flow on GP devices
-    │       │       ├── sbl_baremetal_*.appimage.signed		<= SBL loadable board specific signed sample apps for testing SBL boot flow on HS devices
-    │       │       └── sbl_baremetal_*_release.x*.bin		<= Binary image that can be eXecuted In Place on XIP capable boot media
-    │       ├── mcuAmplinker.lds 				<= Linker comamnd file when TI CGT is used for Asym. Multiproc. boot
-    │       ├── mpuAmplinker.lds 				<= GCC linker command file (for Cortex Axx cores) for Asym. Multiproc. boot
-    │       ├── mcuBootPerfLinker.lds 				<= TI CGT Linker comamnd file for SBL performance tuning example.
-    │       ├── mcuLockStepLinker.lds 				<= Linker comamnd file when TI CGT is used for R5 lock-step boot
-    │       ├── mpuSmplinker.lds 				<= GCC linker command file (for Cortex Axx cores) for SMP boot
-    │       ├── mcuXiplinker.lds 				<= Linker command file for XIP trampoline app
-    │       ├── xip_entry.lds 					<= Linker comamnd file for XIP test case
-    │       ├── xip_entry.asm 					<= Entry point of XIP trampoline app
-    │       ├── xip_stub.c 					<= Simple SBL test app that demonstrates transitioning to a XIP app
-    │       ├── sbl_amp_multicore.c 				<= Simple SBL test that displays UART message
-    │       ├── sbl_amp_multicore_sections.h 			<= Allows same source to be loaded to different sections for different cores.
-    │       ├── sbl_mcu_0_boot_perf_benchmark.c			<= SBL Test to tune boot performance.
-    │       ├── sbl_multicore_a53.asm 				<= Test case entry point  for Cortex-Axx cores
-    │       ├── sbl_multicore_r5.asm 				<= Test case entry point for Cortex-R5 cores
-    │       ├── sbl_multicore_r5_sections.inc 			<= Allows same source to be loaded to different sections for different MCUs.
-    │       ├── sbl_printf.c 					<= Lightweight UART printf function for SBL testing
-    │       ├── sbl_smp_multicore.c 				<= Simple SBL SMP test that uses SBL lib to reset MPUs
-    │       └── sbl_smp_r5.asm 					<= Provides dummy override function for __mpu_init for SMP testcase.
-    │
-    ├── binary							<= ROM bootable SBL images for each board/boot media
-    │   ├── [board]
-    │       └── [bootmedia]
-    │           └── bin
-    │               └── sbl_[bootmedia]_img_mcu1_0_release.tiimage
-    │
-    ├── lib							<= SBL lib for each boot media/board supported
-    │   ├── [bootmedia]
-    │   │   └── [board]
-    │   │       └── r5f
-    │   │           └── release
-    │   │               └── sbl_lib_[bootmedia].aer5f
-    │   └── cust
-    │       └── [board]
-    │           └── r5f
-    │               └── release
-    │                   └── sbl_lib_cust.aer5f
-    │
-    ├── soc							<= SOC specific SBL code
-    │   └── k3
-    │       ├── linker.cmd					<= Linker file used for generating ROM loadable SBL image.
-    │       ├── sbl_err_trap.h					<= Error loops for SBL
-    │       ├── sbl_init.asm					<= SBL Entry point
-    │       ├── sbl_misc.asm					<= SBL Assembly utility functions
-    │       ├── sbl_log.h					<= SBL logging framework
-    │       ├── sbl_sci_client.c				<= Calls SYSFW on DMSC
-    │       ├── sbl_sci_client.h
-    │       ├── sbl_slave_core_boot.c				<= Code that contains the sequence to release a core from reset
-    │       ├── sbl_slave_core_boot.h
-    │       ├── sbl_soc.c					<= Cache Ops, PMU init, image verfication, etc & SoC specific code like RAT Init..
-    │       ├── sbl_soc_cfg.h					<= Abstraction layer for hiding SoC level changes from SBL
-    │       └── sbl_profile.h					<= SBL profiling framework
-    │
-    ├── src							<= Common drivers used across SOCs
-    │   ├── mmcsd
-    │   ├── hyperflash
-    │   ├── ospi
-    │   ├── qspi
-    │   ├── uart
-    │   ├── rprc						<= RPRC image parser used by SBL
-    │   └── spi
-    │
-    └── tools
-        ├── btoccs
-        ├── byteswap
-        ├── ccsutil
-        ├── flashWriter						<= Unused for AM65xx/J721E. AM65xx/J721E uses Uniflash to program flashes.
-        ├── multicoreImageGen					<= Stitches multiple RPRC images for different cores into a single image
-        ├── omapl13x_boot_utils					<= Unused for AM65xx/J721E
-        ├── omapl13x_sd_card_format				<= Unused for AM65xx/J721E
-        ├── out2rprc						<= Converts .out into .rprc files, so that SBL can load non-continuous memory sections
-        ├── scripts						<= Scripts used by .out  generated by CCS projects into SBL loadable images
-        │   ├── K3ImageGen.bat
-        │   └── K3ImageGen.sh
-        └── tiImageGen						<= Unused for AM65xx/J721E. Image generation is handled by PDK build framework (<prsdk_install_path>/pdk_*/packages/ti/build/)
-
-
-.. _am655x-image-formats:
-
-Image Formats
-^^^^^^^^^^^^^^
-
-**SBL format:**
-
-To generate the a bootable image, the SBL build uses the x509CertificateGen script to
-sign the sbl binary with so that the ROM Boot Loader (RBL) can parse it. The image
-format expected by the RBL has been described in detail in the Image Format Section
-of the `AM65xx Technical Reference Manual <http://www.ti.com/lit/pdf/spruid7>`__ and
-the `J721E Technical Reference Manual <http://www.ti.com/lit/pdf/spruil1>`__
-
-.. note::  For HS devices, the SBL and system firmware have to be signed with the MPK.
-           For an easy out-of-box experience, the Processor SDK for HS devices signs the
-           SBL and system firmware with a TI Dummy Key. Images signed with a TI dummy
-           key will boot on both GP and HS boards from TI. The build system invokes the script
-           <PDK>/packages/ti/build/makerules/x509CertificateGen* which inturn calls OpenSSL
-           to create the X509 certificate.
-
-.. warning::  The TI Dummy Key(s) *MUST* be replaced by customers during production
-              with their own Private Keys. If the TI Dummy Keys are used in a production
-              system, the system will be open to security attacks. The path of the default
-              (dummy) key used by the signing script for HS devices is
-              <PDK>/packages/ti/build/makerules/k3_dev_mpk.pem
-
-.. warning::  While SBL and system firmware images signed with the TI Dummy Keys will work
-              on both GP and HS devices, the boot time will be significantly impacted on GP
-              devices. Using SBL signed by TI Dummy Keys on GP devices is only recommended
-              during the prototyping phase - when porting code developed on GP to HS devices.
-
-**Application image format:**
-
-Two utilities - out2rprc and multicoreImageGen are used to convert an application elf
-image(s) into an image loadable by the SBL. The structure of a multicore application
-image is provided below:
-
-.. Image:: /images/Multicore_app_image.png
-
-**RPRC File Header Format**
-
-+------------+----------------------------+
-| Offset     | Binary value               |
-+============+============================+
-| 0x00000000 | **Magic Word(43525052)**   |
-+------------+----------------------------+
-| 0x00000004 | **Entry Point (Location)** |
-+------------+----------------------------+
-| 0x00000008 | **Reserved Addr**          |
-+------------+----------------------------+
-| 0x0000000C | **Section Count**          |
-+------------+----------------------------+
-| 0x00000010 | **Version**                |
-+------------+----------------------------+
-
-**RPRC Section Header Format**
-
-+------------+---------------------------+
-| Offset     | Binary value              |
-+============+===========================+
-| 0x00000000 | **Section start Address** |
-+------------+---------------------------+
-| 0x00000004 | **Reserved Addr**         |
-+------------+---------------------------+
-| 0x00000008 | **Size**                  |
-+------------+---------------------------+
-| 0x0000000C | **Reserved CRC**          |
-+------------+---------------------------+
-| 0x00000010 | **Reserved**              |
-+------------+---------------------------+
-
-**Multicore boot image format**
-
-**Meta Header Start**
-
-+------------+-------------------------------+
-| Offset     | Binary value                  |
-+============+===============================+
-| 0x00000000 | **Magic String (0x5254534D)** |
-+------------+-------------------------------+
-| 0x00000004 | **Number of Files**           |
-+------------+-------------------------------+
-| 0x00000008 | **Device ID**                 |
-+------------+-------------------------------+
-| 0x0000000C | **Reserved**                  |
-+------------+-------------------------------+
-
-**Meta Header per Core**
-
-+------------+------------------+
-| Offset     | Binary value     |
-+============+==================+
-| 0x00000000 | **Core ID**      |
-+------------+------------------+
-| 0x00000004 | **Image Offset** |
-+------------+------------------+
-
-
-**Signed application image format:**
-
-To convert the multicore application image into a format that can be verified,  the build flow uses
-the x509CertificateGen script to create a x509 certificate for the app image. Images that have a
-x509 certificate are called signed images. Signed applications images are mandatory for HS devices,
-but will work also work on GP devices.
-
-Signed images are automatically detected by the SBL and loaded into a scratch memory area specified during
-SBL build. The scratch memory area used by default is specified in `sbl_lib.mk <https://git.ti.
-com/keystone-rtos/sbl/blobs/master/build/sbl_lib.mk>`__ via the flags SBL_SCRATCH_MEM_START and
-SBL_SCRATCH_MEM_SIZE. The SBL_SCRATCH_MEM* options can also be specified for custom builds to override
-the defaults.
-
-The SBL scratch memory is unavailable to applications during app load time, as the SBL is
-still active. Once the SBL transfers control to the application, this memory is available for app
-use - in other words SBL_SCRATCH_MEM* is available during app runtime.
-
-For information on the application's X.509 certificate format, please refer
-`Security X509 Certificate Documentation <http://downloads.ti.com/tisci/esd/latest/
-2_tisci_msgs/security/sec_cert_format.html#security-x509-certificate-documentation>`__
-
-Building the SBL and its components
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**Pre-requisites to Building**
-
--  Set your environment using pdksetupenv.bat or pdksetupenv.sh. Refer to
-   `Processor SDK RTOS Building <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#setup-environment>`__ for information on setting up your build environment
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-
--  SBL needs openssl to build. To check if openssl is present, type the
-   following at the linux or windows prompt.
-::
-
-    openssl version
-
-
--  To build on Linux, you need to have `mono <http://www.mono-project.com>`__ installed.
-
--  Refer `Build Dependencies <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Overview.html#command>`__ for instructions on how to install these tools,
-   if they are not already present on your system.
-
-
-.. raw:: html
-
-   </div>
-
-**Compiling the SBL**
-
-To build all the SBL components:
-::
-
-    cd <PDK>/packages/ti/boot/sbl/build
-    gmake clean all (for windows)
-    make clean all  (for Linux)
-
--  SBL image files are be located at: **<PDK>/packages/ti/boot/sbl/binary/**
--  SBL examples are located at **<PDK>/packages/ti/boot/sbl/examples/k3MulticoreApp/binary**
--  SBL lib are located at **<PDK>/packages/ti/boot/sbl/lib/**
-
-**Compile time options for the SBL**
-
-The SBL supports several compile time options to tweak the SBL to satisfy requirements of
-ease of use, boot time and size. These can be enabled or disabled by editing `sbl/sbl_component.mk
-<http://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/boot/sbl/sbl_component.mk>`__
-
--  SBL_LOG_LEVEL : Controls amount of SBL logs (on the MCU UART) and system firmware logs(on WAKEUP UART).
-   Varies from 0(no logs) to  3 (all logs)
--  SBL_USE_DMA : Valid values are 0 (use CPU to access boot media) or 1 (use DMA to
-   access boot media).
--  SBL_DISPLAY_PROFILE_INFO : At the end of the boot process, displays a log of timestamps
-   at which different SBL profile points are hit. This is useful to see how much
-   time the SBL spends in different functions. SBL_LOG_LEVEL can significantly
-   affect performance numbers.
--  SBL_ENABLE_PLL : Dials up all the PLLs calling Board_init(). Makes it easier for
-   applications as they no longer have to initialize the PLLs. However, enabling this
-   significantly increases boot time and power consumption. Requires system firmware to
-   be loaded.
--  SBL_ENABLE_CLOCKS : Enables all the module clocks by calling Board_init(). Makes
-   it easier for applications as they no longer have to enable clocks.
--  SBL_ENABLE_DDR : Initializes the DDR. At the cost of boot time, this enables
-   applications to run from and use DDR. SBL_ENABLE_CLOCKS and SBL_ENABLE_PLL must
-   also be enabed for this to work. Enabling this option increases the boot time.
--  SBL_SKIP_MCU_RESET : Jumps to the MCU0 application entry point
-   without resetting the core. Enables faster boot time. Will not change the MCU's
-   mode (lock-step/split). Application also inherits the MCU state as the SBL
-   left it in.
--  SBL_ENABLE_DEV_GRP_MCU : Will cause the system firmware to only use MCU domain
-   resources during system firmware initialization. This can be dont either to support
-   boot when the main power domain is off, or to save boot time.
-
-The SBL also supports a "custom" build, in addition to standard out-of-box builds.
-A custom build is a useful way of testing out the effect of different build options -
-like when optimizing for boot time, or enabling custom usecases like eXecute In Place (XIP)
-to reduce memory usage.
-
-For an example of how to use such custom builds, please refer to `sbl/sbl_component.mk
-<https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/boot/sbl/sbl_component.mk#n526>`__. It shows
-how to specify a select list of build options while building SBL images and libs.
-
-
-**SBL Startup**
-
-The SBL can specify the R5 configuration (lockstep or split) that ROM needs to use when it
-starts up the SBL. This info is passed to ROM as a field in the X509 certificate. The value
-in this field can be controlled by editing the build flag R5_STARTUP_MODE  in `sbl/build/sbl_img.mk
-<https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/boot/sbl/build/sbl_img.mk#n91>`__
-
--  EFUSE_DEFAULT : SBL will run with the same R5 configuration the boot rom ran in.
--  SPLIT_MODE  : ROM will switch the R5 to split mode before starting the SBL (default).
-
-
-**Enabling/Disabling JTAG on secure devices**
-
-JTAG access is controlled using a field in the X509 certificate.
-
-By default, for an easy out of box experience, the Processor SDK enables debug via JTAG
-on High Secure devices. Leaving JTAG enabled, while making it easy for software development,
-creates a major security hole in production devices.
-
-To disable/change the level of JTAG access on HS devices, update the value of the debugType field in the
-signing scripts `build/makerules/x509template.txt <http://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/build/makerules/x509template.txt#n74>`__
-(when building from windows) and `build/makerules/x509CertificateGen.sh
-<http://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/build/makerules/x509CertificateGen.sh#n513>`__ (when building from linux).
-
-
-Valid values are
-
--  0 : Disable all JTAG access (most secure and most restrictive)
--  1 : Use device defaults (most secure and most restrictive)
--  2 : Allow debug of non-secure code, when the CPU is running in secure mode, JTAG connectivity will be lost
--  4 : Allow debug of both secure and non-secure code (least secure and least restrictive). This is the default.
-
-
-.. raw:: html
-
-   </div>
-
-.. _am655x-compiling-apps-for-sbl:
-
-**Compiling apps that can be loaded by SBL:**
-
-**Memory Map Considerations**
-
-Applications that the SBL loads must comply with the am655x-sbl-memory-usage_.
-In the application's linker command file, care must be taken to not use the first
-0x100 bytes of any R5 MCU's ATCM memory and SBL reserved memory from 0x41C00100
-to 0x41C3E000. If the applications are signed, no loadable sections must be placed
-in the SBL scratch memory area. The scratch memory can be used at application runtime
-for stacks, heaps, etc.
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-
--  The local address 0x0 of the MPU is not accessible from the MCU, so any MPU linker
-   command file must not specify any loadable sections in that memory region. The SBL
-   will not be able to access that memory to load code or data.
-
-
-.. raw:: html
-
-   </div>
-
-**Converting ELF executables to SBL loadable image**
-
-Depending on the usecase, an ELF application executable can be converted into an
-image that can be loaded by SBL in many ways.
-
--  **Using CCS**: Any project created using the pdkProjectCreate scripts will
-   automatically generate a SBL loadable app, as part of a post-build step.
-
--  **Using makefiles**: Add the following lines to the component's .mk file
-::
-
-    app_name_SBL_APPIMAGEGEN = yes
-    export app_name_SBL_APPIMAGEGEN
-
--  **Existing ELF executable**: By calling the K3ImageGen script.
-::
-
-    Linux Syntax: K3ImageGen.sh <CoreID> <.out>
-
-    Example:
-    cd  <prsdk_install_path>/pdk_*/packages/ti/boot/sbl/example/ampMulticoreApp/binary/am65xx_evm/
-    K3ImageGen.sh 4 sbl_baremetal_boot_test_am65xx_evm_mcu1_0TestApp_release.xer5f
-::
-
-    Windows Syntax: K3ImageGen.bat "<CoreID> <.out>"
-
-    Example:
-    cd  <prsdk_install_path>\pdk_*\packages\ti\boot\sbl\example\ampMulticoreApp\binary\am65xx_evm\
-    K3ImageGen.bat "4 sbl_baremetal_boot_test_am65xx_evm_mcu1_0TestApp_release.xer5f"
-
--  **Multicore Images**: Multicore images, as the name suggests, allows the SBL
-   to load applications for multiple cores from a single image. Creating such images
-   invloves three steps.
-#. Generate the ELF application executables for individual cores
-#. Convert the ELF executables into intermediate .rprc images
-#. Combine the .rprc images of individual cores to create a single multicore image
-
-To covert any .out into the intermediate .rprc format, execute the following commands
-::
-
-    For Linux:
-    mono <PDK>/packages/ti/boot/sbl/tools/out2rprc/bin/out2rprc.exe input.out output.rprc
-::
-
-    For Windows:
-    <PDK>\packages\ti\boot\sbl\tools\out2rprc\bin\out2rprc.exe input.out output.rprc
-
-To stitch multiple .rprc images into a multicore image, execute the following command
-::
-
-    For Linux:
-    <PDK>/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen LE 55 output.appimage  <core_id_1> core_1.rprc <core_id_2> core_2.rprc
-
-::
-
-    For Windows:
-    <PDK>/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen.exe LE 55 output.appimage  <core_id_1> core_1.rprc <core_id_2> core_2.rprc
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-
--  The linux host environment needs to have `mono <http://www.mono-project.com>`__ installed.
--  The values used for the Core ID and Device ID can be found in `sbl/soc/k3/
-   sbl_slave_core_boot.h <https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/boot/sbl/soc/k3/sbl_slave_core_boot.h#n51>`__
--  To simply load an ELF without executing it, use CoreID value ONLY_LOAD_ID
--  If an image for MCU_1 core is provided, the SBL will attempt to switch to
-   split mode.
--  If only an image for MCU_0 is provided, the SBL will not change the mode of the
-   MCU subsystem.
--  To enable SMP on the MPU, ie, to get multiple MPUs execute from a single binary
-   from the same address, use one of the following core_ids
-
-   -  MPU1_SMP_ID: The same app binary runs on both cores in MPU cluster 1
-   -  MPU2_SMP_ID: The same app binary runs on both cores in MPU cluster 2
-   -  MPU_SMP_ID:  The same app binary runs all the MPUs
-
-.. raw:: html
-
-   </div>
-
-
-**Converting ELF executables to executable binary images**
-
-Sometimes, for exteremely constrained and specialized usecases like ultra-low-latency boot
-or DDR-less systems, an ELF application executable can be converted into a binary
-image that can executed directly from the boot media, without loading into internal
-memory.
-
-As internal memory is always accessible, this mode of execution allows some otherwise
-mandatory steps steps like DDR initlization or clock initialization  to be done
-later or skipped altogether.
-
-Working with such highly contrained systems require some special steps..
-
--  Make sure that the boot media supports eXecuting In Place (XIP).
-
--  Use the custom SBL build to select the build options to build a SBL
-   that meets the usecase requirements.
-
--  In the linker command file for the application, make sure that all the data
-   sections, stacks, heaps and globals are in internal read/write memory
-
--  In the linker command file for the application, make sure that there are no
-   holes in the loadable sections. Such non-contiguous sections can drastically
-   blow up the binary image size, when comapred to the ELF executable size.
-
--  To generate an executable binary image from the applications ELF file,
-   add the following lines to the component's .mk file
-::
-
-    app_name_SBL_APP_BINIMAGEGEN = yes
-    export app_name_SBL_APP_BINIMAGEGEN
-
-
-Testing the SBL
-^^^^^^^^^^^^^^^^^
-
-SBL provides test applications to demonstrate booting the A53 and R5 cores in
-both symmetric/lock step & asymmetric/split-mode and other features. The multicore
-sample application prints a message on the UART for each core. The functionality
-the different tests exercises are listed below.
-
--  sbl_*_boot_test_*_all_coresTestApp_release: A single multicore boot test case
-   that boots each core in the SoC with a separate app. Also tests DDR loading
--  sbl_*_boot_test_*_xxxx_xTestApp_release.appimage: A simple testcase for booting
-   core xxxx_x (eg. MCU1_0, MPU2_0 etc.)
--  sbl_*_smp_test_*_all_coresTestApp_release.appimage: A single SMP boot test case
-   that boots MCUs in lock step. The MCU app then uses the SBL lib to boot all the
-   MPUs in SMP mode, ie, all the MPUs execute a single binary from the same address.
--  sbl_baremetal_boot_perf_*_mcu1_0TestApp_release.appimage: A single MCU1_0 test
-   case that can be used to measure the effect of enabling/disabling the perf.
-   tuning knobs in the SBL for OSPI boot. The size of the test case can be easily
-   modified by changing the values of .space directives in `sbl/example/k3MulticoreApp/
-   sbl_boot_perf_r5.asm <http://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/boot/sbl/example/k3MulticoreApp/sbl_boot_perf_r5.asm#n42>`__
-   to profile for different app image sizes.
--  sbl_baremetal_boot_xip_test_*_mcu1_0TestApp_release.xer5f.bin: A testcase
-   demonstrating booting an XIP application from OSPI flash. Please refer `sbl/build/
-   sbl_mcu0_boot_xip_test.mk <https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/boot/sbl/build/
-   sbl_mcu0_boot_xip_test.mk>`__ and `sbl/example/k3MulticoreApp/mcuXiplinker.lds
-   <https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/boot/sbl/example/k3MulticoreApp/mcuXiplinker.lds>`__
-   to see how to convert an existing application into an XIP application. The
-   sbl_*_xip_entry_*.appimage works in tandem with sbl_*xip_test_*.xer5f.bin to transition
-   the system from non-xip to xip boot, as the ROM, by default, does not support XIP from
-   boot media. After programming the sbl and syfw, to program  both sbl_*_xip_entry_*.appimage
-   and  sbl_*xip_test_*.xer5f.bin into OSPI flash, use the following uniflash commands
-
-::
-
-    For Windows:
-    .\dslite.bat --mode processors -c COM9 -f <PDK>\packages\ti\boot\sbl\example\k3MulticoreApp\binary\am65xx\sbl_baremetal_boot_xip_entry_am65xx_evm_mcu1_0TestApp_release.appimage -d 3 -o A0000
-    .\dslite.bat --mode processors -c COM9 -f <PDK>\packages\ti\boot\sbl\example\k3MulticoreApp\binary\am65xx\sbl_baremetal_boot_xip_test_am65xx_evm_mcu1_0TestApp_release.xer5f.bin -d 3 -o E0000
-
-
-::
-
-    For Linux:
-    sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f <PDK>/packages/ti/boot/sbl/example/k3MulticoreApp/binary/am65xx/sbl_baremetal_boot_xip_entry_am65xx_evm_mcu1_0TestApp_release.appimage -d 3 -o A0000
-    sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f <PDK>/packages/ti/boot/sbl/example/k3MulticoreApp/binary/am65xx/sbl_baremetal_boot_xip_test_am65xx_evm_mcu1_0TestApp_release.xer5f.bin -d 3 -o E0000
-
-
-
-An example test log for sbl_*_boot_test_*_all_coresTestApp_release is
-::
-
-    SYSFW  ver xx.x.x-v20xx.xx (xxx xxx) running
-    SBL Revision: xx.xx.xx.xx (MMM  DD YYYY - HH:MM:SS)
-    MPU1_0 running
-    MPU1_1 running
-    MPU2_0 running
-    MPU2_1 running
-    MCU1_1 running
-    MCU1_0 running
-    MCU1_0 reports: All tests have passed
-
-An example log for sbl_*_smp_test_*_all_coresTestApp_release.appimage is
-::
-
-    SYSFW  ver xx.x.x-v20xx.xx (xxx xxx) running
-    SBL Revision: xx.xx.xx.xx (MMM  DD YYYY - HH:MM:SS)
-    MPU SMP boot test
-    Cores 0 & 1 will boot from 0x801007a0
-    Cores 2 & 3 will boot from 0x803007a0
-    Resetting all ARM cores now...
-    No of Cortex-A core(s) running: 1
-    No of Cortex-A core(s) running: 2
-    No of Cortex-A core(s) running: 3
-    No of Cortex-A core(s) running: 4
-    All tests have passed
-
-An example log for sbl_baremetal_boot_perf_*_mcu1_0TestApp_release.appimage, when the best boot time is reached is
-::
-
-    Time elapsed since start of SBL:     36665us
-    fxn:boot_perf_test_main	cycles:  14666041
-
-    Attempting board config ...BOARD_INIT_PLL ...passed
-    BOARD_INIT_MODULE_CLOCK...passed
-    BOARD_INIT_DDR...passed
-
-    Analyzing run results ....
-    Boot time is now optimized....
-    All tests have passed
-
-    Profiling info ....
-    MCU @ 400000000Hz.
-    cycles per usec  = 400
-      fxn:                            main	line:  75	cycle:  xxx	timestamp:       432us
-  					.
-  					.
-  					.
-      fxn:               SBL_SlaveCoreBoot	line: 231	cycle:  xxx	timestamp:     36149us
-
-The test log for sbl_*_xip_test_*.xer5f.bin is
-::
-
-    MCU1_0 running
-
-Boot Modes
-^^^^^^^^^^
-
-
-The SBL supports MMCSD, OSPI, UART and Hyperflash Boot modes. The different boot modes
-supported for all the boards is tabulated below.
-
-+-----------------------+--------+------+------+------+------+------------+
-|                       | MMCSD  | OSPI | UART | PCIe | ETH  | HYPERFLASH |
-+-----------------------+--------+------+------+------+------+------------+
-| AM65xx EVM            |  YES   | YES  | YES  |  NO  |  NO  |     NO     |
-+-----------------------+--------+------+------+------+------+------------+
-| AM65xx IDK            |  YES   | YES  | YES  |  NO  |  NO  |     NO     |
-+-----------------------+--------+------+------+------+------+------------+
-| J721E EVM             |  YES   | YES  | YES  |  NO  |  NO  |     YES    |
-+-----------------------+--------+------+------+------+------+------------+
-
-**Booting Via SD Card**
-
-#. Preparing the SD card.
-#. Booting the testcase from SD card.
-
-**Preparing the SD card**
-
-#. To boot the target the SD card should be bootable. Follow the steps
-   at `Creating bootable SD card in
-   windows <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Creating_a_SD_Card_with_Windows>`__
-   or `Creating bootable SD card in
-   Linux <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_create_SD_card_script>`__.
-#. To update the SBL with a newer version, copy the sbl image (sbl_mmcsd_img_mcu1_0_release.tiimage) to the SD card.
-   Rename it to **tiboot3.bin**
-#. To update the SYSFW with a newer version, copy the system firmware image (sysfw.bin) to the SD card.
-#. Copy the generated application image(\*.appimage) to the SD card. Rename it to
-   **app**
-
-**Booting the testcase  from SD card**
-
-#. Insert SD card into the SD card slot of the board.
-#. Refer Boot Modes section in the `AM6x EVM Hardware Users Guide
-   <http://www.ti.com/lit/pdf/spruim7>`__  to setup EVM to boot from MMCSD.
-#. Open a serial communication terminal like TeraTerm, MiniCom on host
-   PC and connect to the MCU UART console port
-#. Power cycle the board to boot the application from the SD card.
-#. The test logs will be displayed on the MCU UART
-
-**Booting Via OSPI flash**
-
-#. `Programming the OSPI flash <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_board.html#uniflash>`__
-#. Booting the testcase from OSPI flash
-
-
-**Booting the testcase from OSPI flash**
-
-#. Refer Boot Modes section in the `AM6x EVM Hardware Users Guide
-   <http://www.ti.com/lit/pdf/spruim7>`__  to setup EVM to boot from OSPI.
-#. Open a serial communication terminal like TeraTerm, MiniCom on host
-   PC and connect to the MCU UART console port
-#. Power cycle  the board to boot the application from the OSPI flash.
-#. The test logs will be displayed on the MCU UART
-
-
-**Booting the testcase from UART**
-
-#. Refer Boot Modes section in the `AM6x EVM Hardware Users Guide
-   <http://www.ti.com/lit/pdf/spruim7>`__  to setup EVM to boot from UART.
-#. Open a serial communication terminal like TeraTerm, MiniCom on host
-   PC and connect to the MCU UART console port
-#. Power cycle the board, the console should show a sequence of CCC being printed
-#. Choose the X-Modem interface and send the SBL that was built for UART. After the transfer is completed,
-   repeat the same step for sysfw.bin and the application. You will see notifications to perform these
-   actions.
-
-.. warning::   If sysfw.bin is not present in the boot media, the boot will fail without displaying any
-               logs on the MCU UART. SBL enables UART logging only after successfully starting the system
-               firmware image. If the system firmware load fails, the RBL will eventually reset the system.
-
-
-**Booting Via Hyperflash**
-
-#. `Programming the Hyperflash <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_board.html#uniflash>`__
-#. Booting the testcase from Hyperflashflash
-
-
-**Booting the testcase from Hyperflash**
-
-#. Refer Boot Modes section in the `J721E EVM Hardware Users Guide
-   <https://cdds.ext.ti.com/ematrix/common/emxNavigator.jsp?objectId=28670.42872.4850.38306>`__
-   to setup EVM to boot from Hyperflash.
-#. Open a serial communication terminal like TeraTerm, MiniCom on host
-   PC and connect to the MCU UART console port
-#. Power cycle  the board to boot the application from the Hyperflash.
-#. The test logs will be displayed on the MCU UART
-
-
-EVM Setup for testing SBL
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For information on board specific requirements like power supply, UART console port
-connections refer the Hardware User guide of the respective boards.
-
-The configurations needed to setup UART console through a serial terminal 
-application on host PC are listed in the next section.
-
-**UART Console Setup**
-
-PDK SBL prints messages on the UART Serial Console running on the host. Hence, a
-serial terminal application (like Tera Term/HyperTerminal/minicom) should be
-running on the host.
-
--  The host serial port must be configured at 115200 baud, no parity, 1  stop bit
-   and no flow control.
--  Please ensure that the local echo setting for the terminal is turned  off.
--  All SBL prints are routed to the `MCU UART <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#uart-connection>`__
--  To verify setup is correct, setup the EVM to boot from UART  as the Primary Boot
-   Device(refer `AM6x EVM Hardware Users Guide <http://www.ti.com/lit/pdf/spruim7>`__.
-   Power cycle the EVM, and look for the string CCCCCCC on the UART.
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_C66x.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_C66x.rst
deleted file mode 100644
index 877100002..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_C66x.rst
+++ /dev/null
@@ -1,868 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_C66x
-
-Overview
-^^^^^^^^^^^
-
-C66x SOCs use the Intermediate Boot-Loader (IBL) to initialize and setup
-the SOC for specific boot modes. The table below illustrates the
-supported bootmodes:
-
-+--------------------------------------+-------------+-------------+
-| Boot Mode                            | TMDSEVM6678 | TMDXEVM6657 |
-+======================================+=============+=============+
-| NOR boot via IBL over I2C\ :sup:`1`  | Yes         | Yes         |
-+--------------------------------------+-------------+-------------+
-| NAND boot via IBL over I2C\ :sup:`1` | Yes         | Yes         |
-+--------------------------------------+-------------+-------------+
-| TFTP boot via IBL over I2C\ :sup:`1` | Yes         | Yes         |
-+--------------------------------------+-------------+-------------+
-| I2C POST boot\ :sup:`2`              | Yes         | Yes         |
-+--------------------------------------+-------------+-------------+
-| Ethernet boot                        | Yes         | Yes         |
-+--------------------------------------+-------------+-------------+
-| SRIO boot                            | Yes         | Yes         |
-+--------------------------------------+-------------+-------------+
-| PCIe boot                            | Yes         | Yes         |
-+--------------------------------------+-------------+-------------+
-
-.. note::
-   #. Support boot over I2C bus address 0x51
-   #. Support POST boot over I2C bus address 0x50
-   #. Only ELF and BBLOB images are supported for booting
-   #. IBL is using the first 128KB L2 local memory, any application booting
-      from IBL should NOT use the first 128KB L2 memory, OR should only use
-      the first 128KB L2 memory for uninitialized data section
-
-Please refer to the boot mode dip switch settings for different boot
-modes on
-`TMDSEVM6678L_EVM <http://processors.wiki.ti.com/index.php/TMDXEVM6678L_EVM_Hardware_Setup#Boot_Mode_Dip_Switch_Settings>`__,
-and
-`TMDSEVM6657L_EVM <http://processors.wiki.ti.com/index.php/TMDSEVM6657L_EVM_Hardware_Setup#Boot_Mode_Dip_Switch_Settings>`__
-that IBL supports.
-
-Flashing the Bootloader
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-IBL needs to be flashed into EEPROM address 0x51.
-
-Refer to `Processor SDK RTOS Flashing Bootable
-Images <http://processors.wiki.ti.com/index.php/Program_EVM_UG>`__] for
-instructions on using the script, program_evm.js, to automatically flash
-your device.
-
-Bootloader Execution Sequence
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-IBL is flashed into I2C EEPROM bus address 0x51. IBL provides a
-workaround for the PLL lockup issue (please refer to C6678 errata
-document, February 2011, advisory 8 for details on the PLL lockup
-issue). For ROM boot modes (EMAC,SRIO,PCIe,Hyperlink etc) and I2C boot
-mode with bus address 0x50, DSP will initially boot from I2C EEPROM bus
-address 0x51 which does the PLL reset workaround, updates the DEVSTAT
-for appropriate values based on the DIP switch settings (SW3 through SW6
-settings) and then re enters the ROM to accomplish the desired boot
-mode. Please note that the re entry is done for all boot modes except
-for PCIe boot mode and I2C boot mode with bus address 0x51.
-
-Below are the steps done in the IBL:
-
-#. FPGA samples the bootmode pins
-#. FPGA forces the DSP to boot via I2C bus address 0x51
-#. PLL is initialized correctly by the IBL on the I2C.
-#. IBL reads the sampled bootmode from an FPGA register.
-#. IBL checks the bootmode, if it is not I2C boot or it is I2C boot but
-   with bus address 0x50, IBL writes bootmode into the DEVSTAT register
-#. IBL then checks if the bootmode is PCIE boot or not. If it is, it
-   executes some PCIE workaround to configure the PCIE registers (mainly
-   to accept spread spectrum clock) and stays inside IBL waiting for
-   PCIe boot.
-#. If it is not PCIE boot mode, IBL writes the Boot ROM entry address
-   into the DSP Program Counter, DSP executes the desired internal ROM
-   boot mode or boot from I2C bus address 0x50 as normal.
-
-Compilation
-^^^^^^^^^^^^^^
-
-The recommended rule-of-thumb to compiling projects in the Processor SDK
-RTOS package is to use the makefiles provided. The makefiles are usable
-after setting up your shell/terminal/command prompt environment with the
-setupenv.bat or setupenv.sh script located in
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>
-
-Refer to `Processor SDK RTOS Building the SDK <index_overview.html#building-the-sdk>`__
-guide on how to setup your environment for building within any of the
-Processor SDK RTOS packages.
-
-.. note::
-   C66x projects are supported by C6000 Code Generation
-   Tools 7.4.x. Make sure your environment variable, C6X_GEN_INSTALL_PATH,
-   is pointing to a valid C6000 compiler. Compiling IBL invokes the C6000
-   compiler, cl6x, directly. Your PATH variable will need to have
-   $C6X_GEN_INSTALL_PATH/bin.
-
-The IBL package can be found in:
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl
-
-To build:
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make
-     make <IBL_BINARY_NAME> ENDIAN=<BINARY_ENDIANNESS> I2C_BUS_ADDR=0x51
-
-*<IBL_BINARY_NAME>* can be of values: **evm_c6657_i2c** or
-**evm_c6678_i2c**. (For C6657 or C6678 platforms, respectively)
-
-*<BINARY_ENDIANNESS>* can be of values: **little** or **big**
-
-*I2C_BUS_ADDR* specifies the I2C bus address to use, and has to be 0x51
-for C66x SOCs to access the EEPROM.
-
-The resulting output will be in [SDK Install
-Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make/bin
-directory.
-
-.. note::
-   For developers, who want to build IBL in Windows environment. Please
-   build this using MinGW environment using the instructions provided in
-   the build_instructions.txt that can be found under
-   pdk_c66xx_xx_xx\packages\ti\boot\ibl\doc\ibl\doc
-
-|
-
-Flash Writers
-^^^^^^^^^^^^^^^^^
-
-There are three types of flash memory provided with the C66x SOCs:
-EEPROM, NOR, and NAND. Each of these flash memory can hold bootable
-application binaries. As such, respective flash writers are provided in:
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer
-
-.. note::
-   Please set your EVM to **NO BOOT** mode before loading
-   and running any of the flash writers. Flashing in NO BOOT mode is the
-   safest way since it eliminates any unwarranted interactions with booted
-   applications.
-
-
-EEPROM Writer
-""""""""""""""
-
-The EEPROM Writer is used to write a binary into the EEPROM memory.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer/eeprom/<platform>/build
-     make all
-
-Usage
-'''''''
-
-#. Set your EVM to **NO BOOT**. Power on, launch target configuration in
-   CCS, and connect to Core 0. Be sure the GEL file is used and DDR is
-   initialized.
-#. Copy the desired binary you want to flash to [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/writer/eeprom/<platform>/bin
-   directory.
-#. Rename the binary you copied in the previous step to "app.bin".
-#. In CCS, select Core 0 and open the Memory Browser
-#. In the Memory Browser window, right click and select "Load Memory"
-#. Load your app.bin to 0x0C000000. Do so by selecting app.bin for the
-   file, click Next, and input 0x0C000000 for Start Address (Type-size
-   selected should be 32-bit)
-#. Load [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/writer/eeprom/<SOC>/bin/eepromwriter_<platform>.out
-#. Run Core 0. This will program the flash memory.
-
-If it succeeds, the console will print "EEPROM programming completed
-successfully"
-
-NOR Writer
-"""""""""""
-
-The NOR Writer is used to write a binary into the NOR memory.
-
-Compilation
-''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nor/<platform>/build
-     make all
-
-Usage
-''''''
-
-#. Set your EVM to **NO BOOT**. Power on, launch target configuration in
-   CCS, and connect to Core 0. Be sure the GEL file is used and DDR is
-   initialized.
-#. Copy the desired binary you want to flash to [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nor/<platform>/bin
-   directory.
-#. Rename the binary you copied in the previous step to "app.bin".
-#. In CCS, select Core 0 and open the Memory Browser
-#. In the Memory Browser window, right click and select "Load Memory"
-#. Load your app.bin to 0x80000000. Do so by selecting app.bin for the
-   file, click Next, and input 0x80000000 for Start Address (Type-size
-   selected should be 32-bit)
-#. Load [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nor/<SOC>/bin/norwriter_<platform>.out
-#. Run Core 0. This will program the flash memory.
-
-If it succeeds, the console will print "NOR programming completed
-successfully"
-
-NAND Writer
-""""""""""""
-
-The NAND Writer is used to write a binary into the NAND memory.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nand/<platform>/build
-     make all
-
-Usage
-''''''
-
-#. Set your EVM to **NO BOOT**. Power on, launch target configuration in
-   CCS, and connect to Core 0. Be sure the GEL file is used and DDR is
-   initialized.
-#. Copy the desired binary you want to flash to [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nand/<platform>/bin
-   directory.
-#. Rename the binary you copied in the previous step to "app.bin".
-#. In CCS, select Core 0 and open the Memory Browser
-#. In the Memory Browser window, right click and select "Load Memory"
-#. Load your app.bin to 0x80000000. Do so by selecting app.bin for the
-   file, click Next, and input 0x80000000 for Start Address (Type-size
-   selected should be 32-bit)
-#. Load [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/writer/nand/<SOC>/bin/nandwriter_<platform>.out
-#. Run Core 0. This will program the flash memory.
-
-If it succeeds, the console will print "NAND programming completed
-successfully"
-
-Boot Modes
-^^^^^^^^^^^
-
-NAND Boot
-""""""""""""
-
-.. Image:: /images/Nandboot.jpg
-
-NAND boot is a multi-stage process which is designed to boot an
-application from NAND flash after reset. Figure below illustrates the
-elements of the NAND boot process.
-
-On reset the DSP starts execution with the bootrom which transfers
-execution to the secondary bootloader from EEPROM using the I2C target
-bus address 0x51. The secondary bootloader loads the application program
-from NAND flash then transfers control to the application. To execute
-the NAND bootloader you must ensure the DIP switches for your platform
-are properly configured for I2C Master Boot and address 0x51, AND
-the boot parameter index dip switch should be set to 2 or 3.
-
-NAND boot supports multiple images booting. Depending on the boot
-parameter index dip switch, maximum 2 boot images can be supported. By
-default NAND boot only supports a BBLOB image format, if the customer
-wants to boot an ELF image,  the IBL configuration table needs to be
-modified and re-programmed to EEPROM.
-
-|
-
-NOR Boot
-""""""""""""
-
-.. Image:: /images/Norboot.jpg
-
-NOR boot is a multi-stage process which is designed to boot an
-application from NOR flash after reset. Figure below illustrates the
-elements of the NOR boot process.
-
-On reset the DSP starts execution with the bootrom which transfers
-execution to the secondary bootloader from EEPROM using the I2C target
-address 0x51. The secondary bootloader loads the application program
-from NOR flash then transfers control to the application. To execute the
-NOR bootloader you must ensure the DIP switches for your platform are
-properly configured for I2C Master Boot and address 0x51, AND the boot
-parameter index switch should be set to 0 or 1.
-
-NOR boot supports multiple images booting. Depending on the boot
-parameter index dip switch, maximum 2 boot images can be supported.
-
-|
-
-TFTP Boot
-""""""""""""
-
-.. Image:: /images/Emacboot.jpg
-
-EMAC boot is a multi-stage process which is designed to boot an
-application from TFTP server after reset. Figure below illustrates the
-elements of the EMAC boot process.
-
-On reset the DSP starts execution with the bootrom which transfers
-execution to the secondary bootloader from EEPROM using the I2C target
-address 0x51. The secondary bootloader loads the application program
-from a remote TFTP server then transfers control to the application. To
-execute the EMAC bootloader you must ensure the DIP switches for your
-platform are properly configured for I2C Master Boot and address 0x51,
-AND the boot parameter index switch should be set to 4. By default EMAC
-boot only supports a BBLOB image format, if the customer wants to boot
-an ELF image, the IBL configuration table needs to be modified and
-re-programmed to EEPROM.
-
-|
-
-Updating the IBL Ethernet Configurations
-'''''''''''''''''''''''''''''''''''''''''''
-
-There are two ways to update the IBL ethernet configurations for
-ethernet boot.
-
-**Using CCS**
-
-#. Turn on and connect to your EVM with the appropriate Target
-   Configuration file.
-#. Connect to Core 0.
-#. Go to Run -> Load Program and select i2cparam_0x51_c667#_le_0x500.out
-   located in [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make/bin
-#. Go to Tools -> GEL Files and then right click on GEL Files window and
-   Load the i2cConfig.gel GEL file, located in [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/make/bin
-#. Run the program. The following message will be printed on the CCS
-   console: *Run the GEL for the SOC to be configured, press return to
-   program the I2C.* **DO NOT PRESS ENTER UNTIL STEP 6 IS DONE**
-#. Run the GEL script"Scripts -> EVM c6678 IBL" -> setConfig_c6678_main.
-#. Now press "Enter" in the CCS console window, and the program will
-   write the boot parameter table to the EEPROM. On success the message
-   "I2c table write complete" will be printed on the CCS console.
-
-Please note that the i2cConfig.gel file can be modified via a text
-editor before loading and running the script in CCS. Please note that
-this gel file contains configuration settings for multiple SOCs and
-multiple boot modes.
-
-**Using iblConfig Utility Program**
-
-The second way to update the IBL ethernet configurations is to use
-**iblConfig.out**. This utility program is located under:
-
-::
-
-      [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/util/iblConfig/build
-
-In command line, use "make" with the given Makefile to generate
-iblConfig.out and input.txt. Please be sure to fill in the parameters
-for input.txt before running iblConfig.out; below is an example of
-input.txt:
-
-::
-
-    file_name = ibl.bin
-    SOC = 6
-    offset = 0x500
-    ethBoot-doBootp = TRUE
-    ethBoot-bootFormat = ibl_BOOT_FORMAT_ELF
-    ethBoot-ipAddr = 192.168.1.3
-    ethBoot-serverIp = 192.168.1.2
-    ethBoot-gatewayIp = 192.168.1.1
-    ethBoot-netmask = 255.255.255.0
-    ethBoot-fileName =
-
-The first 3 parameters must be filled in for iblConfig.out to work:
-
--  file_name refers to the IBL binary file to update. This file must be
-   in the same directory as iblConfig.out.
--  SOC refers to the SOC being used. Please enter **6 for C6678, and 8
-   for C6657**.
--  offset refers to an offset space in the IBL. The value is 0x500 for
-   C6678, and C6657
-
-The ethernet parameters (the entries beginning with ethBoot) refer to
-specific ethernet configurations. If they are not specified, they will
-be defaulted to the values in the [SDK Install
-Path]/pdk_<platform>_<version>/packages/ti/boot/ibl/src/util/iblConfig/src/SOC.h
-file. In the example above, the ethernet boot file name will be
-defaulted to c6678-le.bin when iblConfig.out is run.
-
-After running iblConfig.out and updating the IBL binary, you must
-flash the modified IBL binary to your EVM. You can do this as part of
-program_evm (refer to `Processor SDK Flashing Bootable
-Images <http://processors.wiki.ti.com/index.php/Program_EVM_UG>`__) or
-you can flash it individually using eepromwriter (refer to "Flash
-Writers" section above).
-
-.. note::
-   If you updated the IBL with iblConfig and flashed it
-   with eepromwriter, you should **NOT** use
-   i2cparam_0x51_c667#_le_0x500.out and iblConfig.gel - this would
-   overwrite the changes you made to the IBL.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/i2c/tftp/<platform>/build
-     make all
-
-Usage
-'''''''''''''
-
-After your IBL ethernet settings are configured correctly and flashed
-into EEPROM memory, follow these steps to continue the TFTP booting
-process:
-
-#. Start a TFTP server on your local PC. Your local PC will be the one
-   sending the image to be booted, so make sure your PC and EVM are
-   connected to the same subnet via ethernet
-#. Copy i2ctftpboot_<platform>.out (refer to compilation step above) to
-   your base TFTP directory
-#. Rename i2ctftpboot_<platform>.out to app.out
-#. Set the IP address of the PC that is running the TFTP server to
-   192.168.2.101, since by default IBL will set the EVM IP address to
-   192.168.2.100 and the TFTP server IP address to 192.168.2.101
-#. Set EVM to TFTP boot mode and power on the EVM
-
-Your PC will send the application image to the EVM to boot. Open an UART
-terminal to view the output.
-
-POST Boot
-""""""""""""
-
-POST (Power On Self Test) Boot is designed to do a quick self-diagnostic
-upon boot. The POST application itself is located in
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/post
-
-This application should already be compiled and flashed into EEPROM
-out-of-box. Below instructions are for re-compilation or re-flashing
-only.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/post/<platform>/build
-     make all
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/post/<platform>/bin
-     ./post_romparse.sh
-
-Note: You would need to use post_romparse.bat instead of the \*.sh
-version if your host system is running on Windows.
-
-Usage
-'''''''''''''
-
-To flash the POST binary into EEPROM:
-
-#. Refer to above Flash Writers section on flashing EEPROM memory. The
-   binary you are flashing is "post_i2crom.bin".
-#. Before running the last step of the EEPROM flashing instruction to
-   run the DSP core, modify the **eepromwriter_input.txt** to use
-   **0x50** for the bus_addr field. The **eepromwriter_input.txt** file
-   is located in:
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/writers/eeprom/<SOC>/bin
-
-Configure your EVM's DIP Switches accordingly to I2C POST BOOT mode. The
-POST application will be loaded from EEPROM 0x50 and output will be
-available over the UART serial console.
-
-|
-
-ETHERNET Boot
-""""""""""""""
-
-ETHERNET Boot uses Ethernet sockets to transfer a bootable image from a
-host to the EVM. After powering on in Ethernet boot mode, the EVM will
-send BOOTP packets at regular interval - this gives visibility of the
-MAC ID of the EVM to the network.
-
-Below are instructions on compiling and running an example to send a
-simple program to the EVM while in Ethernet boot mode.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/ethernet/Utilities
-     make all
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/ethernet/simple
-     make all
-
-Usage
-'''''''''''''
-
-#. Set the EVM's DIP switches to Ethernet boot mode. Connect Ethernet
-   cables such that the EVM and your Host PC are on the same network.
-#. Power on the EVM. The EVM will start sending BOOTP packets. Read the
-   packets for the EVM's MAC ID. You can read the packet by using a
-   network tool such as Wireshark.
-#. On your Host PC, add an ARP entry to associate the EVM's MAC ID with
-   an IP address on your network.
-#. Use the pcsendpkt utility provided to send the simple.eth program
-   compiled in the compilation step to the EVM.
-
-To use pcsendpkt:
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/ethernet/Utilities
-     pcsendpkt simple.eth <EVM IP ADDRESS>
-
-*<EVM IP ADDRESS>* is the IP address you assigned the EVM in step 3
-
-.. note::
-   If you are on a Linux Host PC, you may need to recompile pcsendpkt locally with GCC
-
-  To verify, connect to the EVM's Core 0 via CCS and check that the A1
-  register is set to 0x11223344
-
-|
-
-SRIO Boot
-""""""""""""
-
-SRIO boot will attempt to load and run a binary image received via SRIO.
-An example can be found in:
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio
-
-Below are instructions on compiling and running the SRIO boot example.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_ddrinit/<platform>/build
-     make all
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_ddrinit/<platform>/bin
-     ./srioboot_ddrinit_elf2HBin.sh
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_helloworld/<platform>/build
-     make all
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_helloworld/<platform>/bin
-     ./helloworld_elf2HBin.sh
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/srio/srioboot_example/<platform>/build
-     make all
-
-Note: You would need to use srioboot_ddrinit_elf2HBin.bat and
-helloworld_elf2HBin.bat instead of their \*.sh version respectively if
-your host system is running on Windows. Compilation of the projects
-should be done in the order stated above.
-
-Usage
-'''''''''''''
-
-You will need to have 2 EVMs - both should be set to SRIO boot mode. The
-two EVMs will be connected through the AMC breakout board (lane x of one
-slot should be connected to lane x of the other breakout slot). One EVM
-will be acting as the host (referred to as the HOST EVM) and the other
-EVM will be doing the booting (referred to as the BOOTING EVM).
-
-#. Compile srioboot_example_evm66XXl.out
-#. Connect the BOOTING EVM's UART serial port to your PC using the
-   RS-232 cable
-#. Connect a JTAG emulator on the HOST EVM
-#. Power on both EVMs
-#. Open an UART terminal to view the BOOTING EVM's output. (Remember to
-   set the baud rate to 115.2k bps, 8-bit data, no parity, 1-bit stop,
-   and no flow control)
-#. Connect to the HOST EVM via Code Composer Studio (CCS is recommended
-   to be version 6 or higher). Launch target configuration for your HOST
-   EVM and connect to DSP0.
-#. Load and run srioboot_example_evm66xxl.out on your HOST EVM
-
-CCS console for your HOST EVM should display:
-
-::
-
-     [C66xx_0] SRIO Boot Host Example Version 01.00.00.01
-     [C66xx_0]
-     [C66xx_0] Transfer DDR init code via SRIO successfully
-     [C66xx_0] Transfer boot code via SRIO successfully
-
-Terminal for your BOOTING EVM should display:
-
-::
-
-     SRIO Boot Hello World Example Version 01.00.00.01
-     Booting Hello World image on Core 0 from SRIO ...
-     Booting Hello World image on Core 1 from Core 0 ...
-     Booting Hello World image on Core 2 from Core 0 ...
-     Booting Hello World image on Core 3 from Core 0 ...
-     Booting Hello World image on Core 4 from Core 0 ...
-     Booting Hello World image on Core 5 from Core 0 ...
-     Booting Hello World image on Core 6 from Core 0 ...
-     Booting Hello World image on Core 7 from Core 0 ...
-
-PCIE Boot
-""""""""""""
-
-PCIE boot will attempt to load and run a binary image upon enumeration.
-Example is located:
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie
-
-Below are instructions on compiling and running the PCIE boot example.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_ddrinit/<platform>/build
-     make all
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_helloworld/<platform>/build
-     make all
-
-Additionally for C6678 EVM:
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_interrupt/<platform>/build
-     make all
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/examples/pcie/pcieboot_localreset/<platform>/build
-     make all
-
-The POST application can also be used as a PCIE Boot example. Run the
-corresponding \*_elf2HBin.bat (or .sh) to convert the .out files into
-PCIE bootable binaries.
-
-Usage
-'''''''''''''
-
-An AMC to PCIE adaptor card, a TMS320C66xxL EVM card and a Linux PC are
-required to do the test. The test is verified on both TMS320C6670L and
-TMS320C6678L cards, with both 32-bit and 64-Linux PCs running Ubuntu
-10.04. Other Linux OS are expected to work as well.
-
--  Before connect the system, please update IBL with the latest from
-   Processor SDK
--  Set EVM card to PCIE boot (refer to hardware page)
--  Assemble the EVM card into the adaptor card
--  Connect the URAT cable from EVM card to a Linux PC’s USB port or
-   serial port
--  Completely shut off the PC power supply (by disconnecting the power
-   cord), insert the AMC adaptor card (with EVM mounted) into an open
-   PCIE slot in PC’s motherboard
--  Supply the power to PC, wait for a few seconds and power on the PC.
--  Make sure the PCIE device is correctly enumerated by PC by checking
-   below, note DEVICE_ID field is changed from 0x8888 to 0xb005 which is
-   programmed in IBL.
--  Either enter PC’s BIOS setting when PC is booting up, a new PCIE
-   device should be populated in the PCIE slot where card is inserted,
-   shown as a “Multimedia device”.
--  Or, type “lspci –n” under Linux command shell after Linux OS is
-   loaded, a TI device (VENDOR_ID: 0x104c) should be in the list:
-
-::
-
-     local-ubuntu:~$ lspci -n
-     00:00.0 0600: 8086:2774
-     00:1b.0 0403: 8086:27d8 (rev 01)
-     ….
-     00:1f.3 0c05: 8086:27da (rev 01)
-     01:00.0 0480: 104c:b005 (rev 01)
-     03:00.0 0200: 14e4:1677 (rev 01)
-     Similarly, one can type “lspci”,
-     local-ubuntu:~$ lspci
-     ….
-     00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev
-     01)
-     01:00.0 Multimedia controller: Texas Instruments Device b005 (rev 01)
-     ....
-
--  The PCIE BARn (n = 0, 1, 2, … , 5) registers are written by Linux PC
-   after enumeration, they should be non-zero. Optionally, if a JTAG
-   emulator is available, one can verify this by looking at address
-   starting from 0x21801010 for 6 32-bit word.
--  Prepare pciedemo.ko in the Linux PC
--  On the Linux PC open a new terminal window to run minicom. First run
-   “sudo minicom –s” to set the correct configuration: 115200bps, 8-N-1,
-   Hardware flow control: OFF, Software flow control: OFF, and select
-   the correct Serial Device. Save then run “sudo minicom” to monitor
-   the port.
--  Type “sudo insmod pciedemo.ko”
--  If a JTAG emulator is available, one can verify that the PC registers
-   for cores other than core 0 should be inside DDR; and magic address
-   for cores other than core 0 should be written with 0xBABEFACE.
-
-Procedure to build and run Linux host loader
-''''''''''''''''''''''''''''''''''''''''''''''''''''
-
--  Create a folder (e.g. pcie_test) in a Linux machine. Copy pciedemo.c,
-   Makefile, pcieDdrInit_66xx.h, pcieBootCode_66xx.h,
-   pcieInterrupt_66xx.h and post_66xx.h from
-   tools\boot_loader\examples\pcie\linux_host_loader to the folder.
--  Type “make”, a pciedemo.ko file should be created
--  By default, this will build the “HelloWorld” demo on little endian
-   6678, which is controlled by the following Marcos in pciedemo.c:
-
-::
-
-     #define BIG_ENDIAN 0
-     #define HELLO_WORLD_DEMO 1
-     #define POST_DEMO 0
-     #define EDMA_INTC_DEMO 0
-     #define EVMC6678L 1
-     #define EVMC6670L 0
-
-One must select the endianness, demo program and target type by toggling
-between 0 and 1 accordingly. Then, type “make clean” and type “make” to
-rebuild the pciedemo.ko.
-
-Note: “HelloWorld” and EDMA_INTC demos can be run on both endianness.
-POST demo can be run on little endian only.
-
--  To insert the module into kernel, type “sudo insmod pciedemo.ko”; to
-   view the kernel message, type “dmesg”; to remove the module from
-   kernel, type “sudo rmmod
-
-pciedemo.ko”
-
-The role of IBL in PCIE boot mode
-'''''''''''''''''''''''''''''''''''''''
-
-The Intermediate Boot Loader (IBL) is flashed into I2C EEPROM bus
-address 0x51. IBL provides a workaround for the PLL lockup issue (please
-refer to C6678 errata document, February 2011, advisory 8 for details on
-the PLL lockup issue). For ROM boot modes (EMAC, SRIO, PCIE, Hyperlink,
-etc) and I2C boot mode with bus address 0x50, DSP will initially boot
-from I2C EEPROM bus address 0x51 which does the PLL reset workaround,
-updates the DEVSTAT for appropriate values based on the DIP switch
-settings (SW3 through SW6 settings) and then re-enters the ROM to
-accomplish the desired boot mode. Please note that the re-entry is done
-for all boot modes except for PCIE boot mode and I2C boot mode with bus
-address 0x51.
-
-Below are the steps done in the IBL in PCIE boot mode:
-
--  FPGA samples the boot mode pins
--  FPGA forces the DSP to boot via I2C bus address 0x51
--  PLL is initialized correctly by the IBL on the I2C.
--  IBL reads the sampled boot mode from an FPGA register.
--  IBL checks the boot mode, if it is not I2C boot or it is I2C boot but
-   with bus address 0x50, IBL writes boot mode into the DEVSTAT register
--  IBL then checks if the boot mode is PCIE boot or not. If it is, it
-   executes some PCIE workaround to configure the PCIE registers (mainly
-   to accept spread spectrum clock) and stays inside IBL by first
-   clearing the magic address and then monitoring it for PCIE boot.
-
-For PCIE demos with DDR memory is used, proper DDR configuration is
-required, this doesn’t need the full IBL functionality. Typically DDR
-can be initialized in two ways:
-
--  The Linux host initializes the DDR registers directly through PCIE
-   link.
--  A DDR initialization image is downloaded in the L2 first to
-   initialize the DDR and then reset the magic address with value 0. And
-   then the application image is downloaded in
-
-the DDR. In Processor SDK, the second approach is used.
-
-How HelloWorld boot example works
-'''''''''''''''''''''''''''''''''''''''
-
-The Linux host first pushes the DDR init boot image data to L2 memory of
-core 0, then writes the boot entry address of the DDR init boot image to
-the magic address on core 0, both via PCIE. When the EVM is in PCIE boot
-mode, the IBL code running on the DSP core 0 polls the entry address and
-jumps to that address and starts to boot (initialize the DDR). After DDR
-is properly initialized, the DDR init code clears the magic address and
-keeps on polling it.
-
-Linux host then pushes the HelloWorld boot image data to DDR memory,
-then writes the boot entry address of the HelloWorld boot image to the
-magic address on core 0 to boot core 0. Core 0 starts to boot and print
-the “Hello World” booting information, and then boot all the other cores
-by writing the address of \_c_int00 to the magic address on other cores
-and sending an IPC interrupt to other cores. The RBL running on other
-cores will jump to \_c_int00 and start to boot, each core will write
-0xBABEFACE to its magic address by running a function
-write_boot_magic_number().
-
-Note that host boot application needs to wait for some time after
-pushing the DDR init boot image and before pushing the HelloWorld boot
-image to the DDR, this will ensure DDR is properly initialized.
-
-How POST boot example works
-'''''''''''''''''''''''''''''
-
-The POST example uses L2 only. The Linux host first pushes the POST boot
-image data to L2 memory of core 0, then writes the boot entry address of
-the POST to the magic address on core 0, both via PCIE. The IBL code
-running on the DSP core 0 polls the entry address and jumps to that
-address and starts to boot.
-
-How DSP local reset example works
-'''''''''''''''''''''''''''''''''''''''
-
-A user may want to re-run a PCIE demo without power cycle the Linux PC.
-There is a need to reset the DSP chip from host software. There are
-several types of resets: hard reset, soft reset and CPU local reset.
-Hard reset will reset everything on the device except the PLLs, test,
-emulation logic, and reset isolation modules. Since PCIE doesn’t support
-reset isolation, a hard reset will reset PCIE module as well and all the
-configured PCIE registers (PCIE MMRs) will be lost. Soft reset will
-behave like a hard reset except that the stick bits of PCIE MMRs are
-retained. The PC can’t communicate with PCIE card anymore in both hard
-reset and soft reset cases.
-
-To reset the DSP while keeping the PCIE untouched, the local reset
-example does the following:
-
--  Put all cores in reset via PSC
--  Disable all modules except PCIE and cores via PSC
--  Configure chip level registers DSP_BOOT_ADDRn and IPCGRn: Here the
-   header array converted from DSP local reset example is loaded into
-   each core via PCIE; the \_c_int00 is then written to each
-   DSP_BOOT_ADDRn; finally IPCGRn is written to jump start the DSP local
-   reset example program, which simply polls magic address for a
-   secondary boot.
--  Enable all modules previous disabled via PSC
--  Pull all cores out of reset via PSC
-
-.. note::
-  It is IBL (in local L2) that monitors magic address
-  and boots the DDR init (in local L2) or POST (in local L2) or
-  EDMA-interrupt (in local L2) in those demos. If one wants to load
-  his/her own boot demo code, then it shouldn’t overlap with the IBL
-  code. As a guideline, the IBL uses memory from 0x00800000 to
-  0x0081BDFF. To check the exact memory usage, you can re-build the IBL
-  by following the instructions in
-  tools\boot_loader\ibl\doc\build_instructions.txt and check the
-  resulting ibl_c66x_init.map file. In addition, following local L2 is
-  reserved by RBL and shouldn’t be used: for 6678 ROM PG 1.0, 0x00872DC0
-  – 0x0087FFFF; for 6670 ROM PG 1.0, 0x008F2DC0 – 0x008FFFFF.
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2G.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2G.rst
deleted file mode 100644
index 92ef98ee4..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2G.rst
+++ /dev/null
@@ -1,228 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_K2G
-
-Overview
-^^^^^^^^^^
-
-The Secondary Bootloader (SBL) for K2G does basic hardware
-initialization for the board to load and run applications.
-
-Bootloader Execution Sequence
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  Power On Reset occurs
--  ROM Bootloader (RBL) executes. It checks for bootmode and attempts to
-   load+run the SBL from that bootmode.
--  SBL begins execution from internal memory (MSMC RAM)
-
-   -  Board Initialization is done by a call to **Board_init()** API.
-      For additional details refer to `Processor SDK Board
-      Support <index_board.html#board-support>`__.
-   -  SBL setup includes configuring Pinmux, enable peripheral clocks,
-      set up PLLs, and configure EMIF for DDR.
-
--  SBL finishes setup and looks for "app" to execute next. This
-   user-modifiable application may reside in SD card or QSPI memory
-   depending on the bootmode chosen.
--  Once located, app will be loaded into memory and execution will be
-   branched to the application's entry address
-
-Tools and Binary Formats
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Making Bootable SBL image (MLO)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-RBL loads and runs "MLO", which is a .out executable formatted by TI
-tools. To make a .out, such as SBL, bootable by ROM, you must follow
-these steps:
-
-#. **armhex [.out file] [.rmd file]**
-
-   -  .out file is the file you want to boot, such as sbl.out
-   -  .rmd file is an input file to specify sections information. An
-      example can be found in:
-      <PDK_INSTALL_DIR>/packages/ti/boot/sbl/board/evmK2G/build/sbl.rmd
-   -  armhex is a tool in TI ARM CGT compiler. This generates a [hex
-      file], name of which is specified by the .rmd file
-
-#. **b2ccs [hex file] [ccs file]**
-
-   -  hex file is the output from the previous step
-   -  ccs file can be name of your choosing
-
-#. **ccsAddGphdr -infile [ccs file] -outfile [gphdr file] -headerEndian
-   BE**
-
-   -  gphdr file can be the name of your choosing
-
-#. **ccsAddGptlr -infile [gphdr file] -outfile [gptlr file]**
-
-   -  gptlr file can be the name of your choosing
-
-#. **byteswapccs [gptlr file] [MLO ccs file]**
-
-   -  MLO ccs file can be the name of your choosing
-
-#. **ccs2bin -swap [MLO ccs file] MLO**
-
-   -  MLO will be created after this step
-
-Armhex is part of TI ARM CGT, in
-**<CCS_INSTALL_DIR>/tools/compiler/ti-cgt-arm_x.x.x/bin**. The rest of
-the tools can be found in:
-**<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools**
-
-Making Loadable User Application image (app)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For converting the compiled .out files to a format loadable by TI's
-Secondary Boot Loader (SBL), **you must follow these two steps:**
-
-#. **out2rprc.exe [.out file] [rprc output]**
-#. **MulticoreImageGen.exe LE 55 [output name] 0 [rprc output]**
-
-Out2rprc.exe and MulticoreImageGen.exe are tools supplied by TI and can
-be located in the **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools**
-folder. "rprc output" can be any spare name of your choosing. "output
-name" can also be any name of your choosing.
-
-The '0' used in step 2 refers to the Core ID to boot. By default, '0' is
-MPU (Cortex A15) core 0. You can input a different value to boot to
-other cores. Valid values are:
-
-+------------+-------+
-| Core       | Value |
-+============+=======+
-| MPU Core 0 | 0     |
-+------------+-------+
-| DSP Core 0 | 5     |
-+------------+-------+
-
-If MPU SMP is chosen, the same boot image and entry will be used for all
-MPU cores. SBL can also parse multiple boot images that are concatenated
-together. Simply use MulticoreImageGen as such:
-
-**MulticoreImageGen.exe LE 55 [output name] [Core ID a] [rprc output a]
-[Core ID b] [rprc output b] [Core ID c] [rprc output c] ...**
-
-Boot Modes
-^^^^^^^^^^^
-
-This release of SBL supports MMCSD and QSPI boot modes.
-
-MMCSD Boot Mode
-""""""""""""""""
-
-Preparing the SD card
-'''''''''''''''''''''''
-
-#. To boot the target, the SD card needs to be bootable. Follow the
-   steps at `Creating bootable SD card in windows <index_overview.html#windows-sd-card-creation-guide>`__
-   or `Creating bootable SD card in Linux <index_overview.html#linux-sd-card-creation-guide>`__.
-#. Copy "MLO" and "app" to your SD card.
-
-   -  MLO is the SBL formatted by the aforementioned tools. A pre-built
-      MLO can be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/evmK2G/mmcsd/bin**
-   -  app is the target application to be booted and also formatted by
-      the aforementioned tools. (Note that the tools for making the
-      bootable MLO and the loadable app are different).
-
-Booting via SD Card
-'''''''''''''''''''''
-
-#. Insert micro SD card into the SD card slot of the board
-#. Set the board to MMC/SD bootmode by configuring the DIP switches to
-   '0111'. Verify the bootmode on the LCD display on your board
-#. Open a serial communication terminal (such as TeraTerm, MiniCom,
-   etc.) on host PC and connect to the UART console port
-#. Power on the board
-
-| Below is an example of K2G SBL successfully booting the diagnostic
-  application:
-
-.. Image:: /images/K2g_boot_diag.jpg
-
-QSPI Boot Mode
-""""""""""""""""
-
-Preparing QSPI Flash
-''''''''''''''''''''''
-
-MLO and app needs to be flashed into QSPI memory so that they can be
-booted. MLO will reside at offset 0 and app will reside at offset
-0x80000. QSPI flash memory map:
-
-+----------------+-----+
-| Offset 0x0     | MLO |
-+----------------+-----+
-| Offset 0x80000 | app |
-+----------------+-----+
-
-The images can be flashed into QSPI flash by following steps given
-below:
-
-#. Copy MLO, app, and config to SD card
-
-   -  MLO is the SBL formatted by the aforementioned tools. A pre-built
-      MLO can be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/evmK2G/qspi/bin**
-   -  app is the target application to be booted and also formatted by
-      the aforementioned tools. (Note that the tools for making the
-      bootable MLO and the loadable app are different).
-   -  config helps specify the memory map. The default config file can
-      be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/qspi**.
-      This config file may be altered to custom user settings if needed.
-
-#. In the SD card, rename MLO to "boot". This is the default name
-   specified by the config file.
-#. Insert the SD card into the SD card slot on the board
-#. Connect to the board with CCS. Launch target configuration and
-   connect to the ARM A15 core. GEL file will run on-connect and do
-   basic board-level initialization
-#. Load the flash writer, qspi_flash_writer.out, to the connected core
-
-   -  A pre-built qspi_flash_writer.out can be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/qspi/bin/evmK2G**
-
-#. Run the QSPI flash writer application. You will see the following
-   logs on the EVM's UART console:
-
-::
-
-     *** PDK QSPI Flash Writer ***
-     Copying 'boot' to local memory
-     Begin flashing 'boot' into QSPI
-     Finished flashing 'boot' with size 20010 at offset 0
-     Copying 'app' to local memory
-     Begin flashing 'app' into QSPI
-     Finished flashing 'app' with size 19398 at offset 80000
-     Flashing completed!
-
-.. note:: This application will flash the image at required offset without
-   taking into consideration any overwriting to previously flashed image.
-
-Booting via QSPI
-''''''''''''''''''
-
-#. Set the board to QSPI-48 bootmode by configuring the DIP switches to
-   '1111'. Verify the bootmode on the LCD display on your board
-#. Open a serial communication terminal (such as TeraTerm, MiniCom,
-   etc.) on host PC and connect to the UART console port
-#. Power on the board
-
-Memory Usage
-^^^^^^^^^^^^^^^^^^^^
-
-SBL uses the last 0x40000 memory from MSMC RAM memory.
-
-The SBL memory map is shown below:
-
-.. Image:: /images/SBL_mem_k2g.jpg
-
-.. note::
-   app should not have loadable sections residing in SBL memory region to
-   prevent overwriting SBL during load time. It is, however, free to use
-   SBL memory after it is loaded and running.
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2H_E_L.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2H_E_L.rst
deleted file mode 100644
index 181a64793..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2H_E_L.rst
+++ /dev/null
@@ -1,210 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_K2H/E/L
-
-Overview
-^^^^^^^^^
-
-K2H/K2E/K2L EVMs uses the Secondary Boot Loader (SBL) to configure
-board-related settings and execute a user application. The user
-application can be single core or multicore, and execute on either DSP
-cores or ARM cores. The only restriction is that the load sections must
-not overlap the memory space that SBL uses.
-
-The K2H/K2E/K2L SBL supports ARM master boot using SPI NOR. Please refer
-to the boot mode dip switch settings in the respective EVM hardware page
-(:ref:`link <RTOS-SDK-Supported-Platforms>`)
-to configure your EVM for NOR boot.
-
-Flashing the Bootloader
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-SBL and user application needs to be flashed into SPI NOR.
-
-Refer to `Program EVM Guide <http://processors.wiki.ti.com/index.php/Program_EVM_UG>`__ for
-instructions on using the script, program_evm.js, to automatically flash
-your device.
-
-Usage
-^^^^^^^
-
-#. Flash the bootloader and user application. This can be done
-   automatically with default files by using program_evm.js
-#. Set the EVM to ARM SPI boot mode
-#. Connect UART serial debug cable from EVM to your computer. Open a
-   terminal such as HyperTerminal or TeraTerm to see console output
-#. Power on the EVM
-
-Compilation
-^^^^^^^^^^^^^
-
-The recommended rule-of-thumb to compiling projects in the Processor SDK
-RTOS package is to use the makefiles provided. The makefiles are usable
-after setting up your shell/terminal/command prompt environment with the
-setupenv.bat or setupenv.sh script located in
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>
-
-Refer to `Building RTOS SDK <index_overview.html#building-the-sdk>`__ page on how to
-setup your environment for building within any of the Processor SDK RTOS
-packages.
-
-The SBL package can be found in:
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl
-
-To build:
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl
-     make all BOOTMODE=spi BOARD=<EVM> SOC=<platform>
-
-*<EVM>* can be of values: **evmK2H**, **evmK2E**, **evmK2L**, or
-**evmK2K**
-
-*<platform>* can be of values: **K2H**, **K2E**, **K2L**, or **K2K**
-
-The resulting output will be in [SDK Install
-Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/binary/<platform>/spi/bin
-directory.
-
-Making Loadable User Application image (app)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For converting the compiled .out files to a format loadable by TI's
-Secondary Boot Loader (SBL), you must follow these two steps:
-
-#. **out2rprc.exe [.out file] [rprc output]**
-#. **MulticoreImageGen.exe LE 55 [output name] 0 [rprc output]**
-
-Out2rprc.exe and MulticoreImageGen.exe are tools supplied by TI and can
-be located in the **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools**
-folder. "rprc output" can be any spare name of your choosing. "output
-name" can also be any name of your choosing.
-
-The '0' used in step 2 refers to the Core ID to boot. By default, '0' is
-MPU (Cortex A15) core 0. You can input a different value to boot to
-other cores. Valid values are:
-
-+-----------------------+-----------------------+-----------------------+
-|         K2H           |          K2E          |         K2L           |
-+==========+============+===========+===========+==========+============+
-| **Core** | **Value**  | **Core**  | **Value** | **Core** | **Value**  |
-+----------+------------+-----------+-----------+----------+------------+
-|MPU Core 0|     0      |MPU Core 0 |     0     |MPU Core 0|     0      |
-+----------+------------+-----------+-----------+----------+------------+
-|MPU Core 1|     1      |MPU Core 1 |     1     |MPU Core 1|     1      |
-+----------+------------+-----------+-----------+----------+------------+
-|MPU Core 2|     2      |MPU Core 2 |     2     |MPU SMP   |     4      |
-+----------+------------+-----------+-----------+----------+------------+
-|MPU Core 3|     3      |MPU Core 3 |     3     |DSP Core 0|     5      |
-+----------+------------+-----------+-----------+----------+------------+
-|MPU SMP   |     4      |MPU SMP    |     4     |DSP Core 1|     6      |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 0|     5      |DSP Core 0 |     5     |DSP Core 2|     7      |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 1|     6      |           |           |DSP Core 3|     8      |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 2|     7      |           |           |          |            |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 3|     8      |           |           |          |            |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 4|     9      |           |           |          |            |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 5|     10     |           |           |          |            |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 6|     11     |           |           |          |            |
-+----------+------------+-----------+-----------+----------+------------+
-|DSP Core 7|     12     |           |           |          |            |
-+----------+------------+-----------+-----------+----------+------------+
-
-If MPU SMP is chosen, the same boot image and entry will be used for all
-MPU cores. SBL can also parse multiple boot images that are concatenated
-together. Simply use MulticoreImageGen as such:
-
-**MulticoreImageGen.exe LE 55 [output name] [Core ID a] [rprc output a]
-[Core ID b] [rprc output b] [Core ID c] [rprc output c] ...**
-
-Flash Writers
-^^^^^^^^^^^^^^^
-
-SPI Writer
-""""""""""""
-
-The SPI flash writer, spi_flash_writer.out, is a part of the SBL package
-and allows users to flash multiple images at different offsets into the
-board's SPI NOR flash memory.
-
-Compilation
-'''''''''''''
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/
-     make spi_flashwriter BOARD=<EVM> SOC=<platform>
-
-The binary output will be at:
-
-::
-
-     [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/<platform>
-
-
-Usage
-'''''''''
-
-#. Copy the binaries that you want to flash to: [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/<platform>
-#. In that same directory, there is a file named **config**. Edit that
-   file such that each line has 2 parameters: [name of binary to flash]
-   [SPI NOR offset to flash to]
-#. Set your EVM to NO BOOT. Power on, launch target configuration in
-   CCS, and connect to DSP Core 0
-#. Load and run [SDK Install
-   Path]/pdk_<platform>_<version>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/<platform>/spi_flash_writer.out
-#. You should see the flash progress output on UART terminal
-
-|
-
-Boot Example
-^^^^^^^^^^^^^^
-
-Below is an example output of evmK2H booting after having images flashed
-in by program_evm.js:
-
-::
-
-    **** PDK SBL ****
-    Boot succesful!
-    Begin parsing user application
-    Jumping to user application...
-
-
-    TMDXEVM6636K2H POST Version 01.00.00.08
-    ------------------------------------------
-    SOC Information
-
-    BMC Version: 0000
-    EFUSE MAC ID is: B4 99 4C B6 E2 5B
-    SA is enabled on this board.
-    PLL Reset Type Status Register: 0x00000001
-    Platform init return code: 0x00000000
-
-    Power On Self Test
-
-    POST running in progress ...
-    POST I2C EEPROM read test started!
-    POST I2C EEPROM read test passed!
-    POST SPI NOR read test started!
-    POST SPI NOR read test passed!
-    POST EMIF16 NAND read test started!
-    POST EMIF16 NAND read test passed!
-    POST external memory test started!
-    POST external memory test passed!
-    POST done successfully!
-
-    POST result: PASS
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_OMAPL13x.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_OMAPL13x.rst
deleted file mode 100644
index 2d367ca60..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_OMAPL13x.rst
+++ /dev/null
@@ -1,410 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_OMAPL13x
-
-Overview
-^^^^^^^^^^
-
-The Secondary Bootloader (SBL) for OMAPL137/OMAPL138/C6748 does basic
-hardware initialization for the board to load and run applications.
-Processor SDK boot support for each of these SoC is shown below
-
-+-------------+-------------+-------------+-------------+-------------+
-| Device      | Cores       | Boot Master | Supported   | HW          |
-|             |             |             | Boot        | Platforms   |
-|             |             |             | modes in    |             |
-|             |             |             | SBL         |             |
-+=============+=============+=============+=============+=============+
-| OMAPL137    | ARM (ARM9)  | DSP         | SPI         | OMAPL137    |
-|             | DSP (C674x) |             |             | EVM         |
-+-------------+-------------+-------------+-------------+-------------+
-| OMAPL138    | ARM (ARM9)  | ARM         | MMCSD       | OMAPL138    |
-|             | DSP (C674x) |             |             | LCDK        |
-+-------------+-------------+-------------+-------------+-------------+
-| C6748       | DSP (C674x) | DSP         | MMCSD       | C6748 LCDK  |
-+-------------+-------------+-------------+-------------+-------------+
-
-Bootloader Execution Sequence
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
--  Power On Reset occurs
--  ROM Bootloader (RBL) executes. It checks for bootmode and attempts to
-   load+run the SBL from that bootmode.
--  SBL begins execution from internal memory (Shared RAM)
-
-   -  Board Initialization is done by a call to **Board_init()** API.
-      For additional details refer to `Processor SDK Board
-      Support <index_board.html#board-support>`__.
-   -  SBL setup includes configuring Pinmux, enable peripheral clocks,
-      set up PLLs, and configure EMIF for SDRAM/DDR.
-
--  SBL finishes setup and looks for "app" to execute next. This
-   user-modifiable application shall reside on the boot media.
--  Once located, app will be loaded into memory and execution will be
-   branched to the application's entry address
-
-Tools and Binary Formats
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Making Bootable SBL image (MLO)
-""""""""""""""""""""""""""""""""
-
-RBL loads and runs "MLO", which is a .out executable formatted by TI
-tools. HexAIS tool should be used to convert the .out into MLO using the
-below command.
-
-Windows Host
-
-**<HexAIS_Tool> -o <output file> -ini <ini file> <input file>**
-
-Linux Host
-
-HexAIS executable can be run on Linux PC by using mono tool as shown
-below
-
-**mono <HexAIS_Tool> -o <output file> -ini <ini file> <input file>**
-
--  <HexAIS_Tool> is HexAIS_OMAP-L137.exe for OMAPL137 and
-   HexAIS_OMAP-L138.exe for OMAPL138/C6748
--  ‘output file’ is name of the output file. MLO in this case
--  ‘ini file’ is configuration file for defining the boot parameters.
-   This file provides option to instruct RBL to take certain actions
-   before loading the MLO into internal memory. Sample ini file is
-   available at **< PDK_INSTALL_DIR
-   >/packages/ti/boot/sbl/soc/<device>**
-
-<device> can be omapl137, omapl138 or c6748
-
--  ‘input file’ is the input .out file name which needs to be converted
-   into MLO
-
-OMAPL137 HexAIS tool is available at **< PDK_INSTALL_DIR
->/packages/ti/boot/sbl/tools/omapl13x_boot_utils/OMAP-L137/GNU/AISUtils**.
-
-OMAPL138/C6748 HexAIS tool is available at **< PDK_INSTALL_DIR
->/packages/ti/boot/sbl/tools/omapl13x_boot_utils/OMAP-L138/GNU/AISUtils**
-
-Making Loadable User Application image (app)
-""""""""""""""""""""""""""""""""""""""""""""""
-
-For converting the compiled .out files to a format loadable by TI's
-Secondary Boot Loader (SBL), you must follow these two steps:
-
-#. **out2rprc.exe [.out file] [rprc output]**
-#. **MulticoreImageGen.exe LE 55 [output name] <Core ID> [rprc output]**
-
-Out2rprc.exe and MulticoreImageGen.exe are tools supplied by TI and can
-be located in the **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools**
-folder. "rprc output" can be any spare name of your choosing. "output
-name" can also be any name of your choosing.
-
-The <Core ID> used in step 2 refers to the Core ID to boot. Use '0' as
-Core ID for ARM core and '1' for DSP core. Valid values are:. You can
-input a different value to boot to other cores. Valid values are:
-
-+----------+-------+
-| Core     | Value |
-+==========+=======+
-| ARM Core | 0     |
-+----------+-------+
-| DSP Core | 1     |
-+----------+-------+
-
-.. note::
-   Program entry point of DSP app images on OMAPL138 platform should be 1KByte aligned for loading and executing the DSP images from
-   ARM core. GPIO LLD LED blink example for C674x core can be used as reference for aligning the DSP entry point to run the DSP code from
-   SBL. Other LLD examples does not work from SBL as is.
-
-Boot Modes
-^^^^^^^^^^^^
-
-This release of SBL supports SPI and MMCSD boot modes.
-
-SPI Boot Mode
-""""""""""""""
-
-Preparing SPI Flash
-'''''''''''''''''''''
-
-MLO and app needs to be flashed into SPI memory so that they can be
-booted. MLO will reside at offset 0 and app will reside at offset
-0x80000. SPI flash memory map:
-
-+----------------+-----+
-| Offset 0x0     | MLO |
-+----------------+-----+
-| Offset 0x80000 | app |
-+----------------+-----+
-
-The images can be flashed into SPI flash by following steps given below:
-
-#. Copy MLO and app to SPI flash writer binary folder -
-   **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/evmOMAPL137**.
-   Make sure config file also present in the SPI flash writer binary
-   folder.
-
-   -  MLO is the SBL formatted by the aforementioned tools. A pre-built
-      MLO can be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/evmOMAPL137/spi/bin**
-   -  app is the target application to be booted and also formatted by
-      the aforementioned tools. (Note that the tools for making the
-      bootable MLO and the loadable app are different).
-   -  config helps specify the memory map. The default config file can
-      be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/evmOMAPL137**.
-      This config file may be altered to custom user settings if needed.
-
-#. Connect the DB9 port of the EVM to host PC. Open serial communication
-   applications like TeraTerm, MiniCom, etc and configure for ‘115200
-   8N1’.
-#. Connect to the board with CCS. Launch target configuration and
-   connect to the DSP C674x core. GEL file will run on-connect and do
-   basic board-level initialization
-#. Load the flash writer, spi_flash_writer.out, to the connected core
-
-   -  A pre-built spi_flash_writer.out can be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/spi/bin/evmOMAPL137**
-
-#. Run the SPI flash writer application. You will see the following logs
-   on the EVM's UART console:
-
-::
-
-     *** PDK SPI Flash Writer ***
-    Opening SPI handle...
-    SPI handle opened!
-    Parsing config file and flashing content to SPI NOR...
-    Parsed config line, received parameters: filename = MLO, address = 0x0
-           Size of MLO is 0xc81c
-           Loading binary to memory ...
-           Finished loading binary to memory!
-           Flashed MLO to offset 0x0!
-           Read flash memory at 0x0, checking flashed content...
-           Verified flash data equal expected data!
-    Parsed config line, received parameters: filename = app, address = 0x80000
-           Size of app is 0x16144
-           Loading binary to memory ...
-           Finished loading binary to memory!
-           Flashed app to offset 0x80000!
-           Read flash memory at 0x80000, checking flashed content...
-           Verified flash data equal expected data!
-    Successfully flashed memory content!
-
-.. note::
-   This application will flash the image at required offset without taking
-   into consideration any overwriting to previously flashed image.
-
-Booting via SPI
-''''''''''''''''''''
-
-#. Set the OMAPL137 EVM to SPI bootmode by configuring the SW2 DIP
-   switches 1-4 to 'OFF ON OFF ON'. Other switch positions on SW2 are
-   don’t care for SPI boot.
-#. Connect the DB9 port of the EVM to host PC. Open serial communication
-   applications like TeraTerm, MiniCom, etc and configure for ‘115200
-   8N1’
-#. Power on the board
-
-Below is an example of OMAPL137 SBL successfully booting the GPIO LED
-blink application
-
-.. Image:: /images/Omapl137_boot_example.jpg
-
-|
-
-MMCSD Boot Mode
-""""""""""""""""
-
-OMAPL138/C6848 RBL does not support reading the boot images as files
-from SD card. Secondary Boot loader image should be written to SD card
-as raw data. Special formatting is needed for SD card to create
-un-formatted area at the beginning of the card to store SBL.
-
-Formatting the SD Card
-''''''''''''''''''''''''
-
-SD card for booting OMAPL138/C6748 needs to be formatted from Linux PC
-due to un-formatted area requirement. Formatting the SD card from
-Windows PC is not supported in this release.
-
-Connect the SD card to Linux PC and use below command to format the SD
-card
-
-**sudo sh create-sdcard-omapl13x.sh <Drive Name>**
-
--  <Drive Name> is name of the drive on which SD card is mounted. Be
-   cautious while selecting the drive name. Running the script with
-   system drive name will corrupt the file system.
--  create-sdcard-omapl13x.sh script is available at
-   **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/omapl13x_sd_card_format**
-
-Preparing the SD Card
-''''''''''''''''''''''
-
-For both OMAPL138 and C6748, MLO needs to be flashed onto SD card
-un-formatted area and app should be copied onto SD card.
-
-MLO can be flashed into SD card un-formatted area by following steps
-given below:
-
-#. Build the MMCSD flash writer using below commands
-
-   -  cd <PDK_INSTALL_DIR>/packages/ti/boot/sbl
-   -  gmake mmcsd_flashwriter SOC=OMAPL138 BOARD=lcdkOMAPL138
-      BOOTMODE=mmcsd
-
-#. Copy 'app' to SD card and insert the card into MMCSD slot of the
-   board
-#. Copy MLO to MMCSD flash writer binary folder -
-   **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/mmcsd/bin/lcdkOMAPL138**.
-   Make sure config file also present in the MMCSD flash writer binary
-   folder.
-
-   -  MLO is the SBL formatted by the aforementioned tools. A pre-built
-      MLO can be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/lcdkOMAPL138/mmcsd/bin**
-   -  app is the target application to be booted and also formatted by
-      the aforementioned tools. (Note that the tools for making the
-      bootable MLO and the loadable app are different).
-   -  config helps specify the memory map. The default config file can
-      be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/mmcsd/bin/lcdkOMAPL138**.
-      This config file may be altered to custom user settings if needed.
-
-#. Connect the USB serial port of the EVM to host PC. Open serial
-   communication applications like TeraTerm, MiniCom, etc and configure
-   for ‘115200 8N1’.
-#. Connect to the board with CCS. Launch target configuration, connect
-   to ARM core first (not needed for C6748) and then connect to the DSP
-   C674x core. GEL file will run on-connect and do basic board-level
-   initialization
-#. Load the flash writer, mmcsd_flash_writer.out, to the connected core
-
-   -  mmcsd_flash_writer.out can be found at:
-      **<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/mmcsd/bin/lcdkOMAPL138**
-
-#. Run the MMCSD flash writer application. You will see the following
-   logs on the EVM's UART console:
-
-::
-
-    Opening MMCSD handle...
-    MMCSD handle opened!
-    Parsing config file and flashing content to MMCSD...
-    Parsed config line, received parameters: filename = MLO, address = 0x200
-           Size of MLO is 0xb9b8
-           Loading binary to memory ...
-           Finished loading binary to memory!
-           Flashed MLO to offset 0x200!
-           Read flash memory at 0x200, checking flashed content...
-           Verified flash data equal expected data!
-    Successfully flashed memory content!
-
-Procedure to flash the MLO described above is applicable to C6748 also.
-Use C6748 for OMAPL138 and lcdkC6748 for lcdkOMAPL138 in all the paths
-mentioned above.
-
-::
-
-    MLO offset in config file is set to 200 by default which indicates that MLO will be written to second sector of the SD card. MLO offset can be any non-
-    zero value which is multiple of 512 and should be within first 2Mbytes of SD card memory. DO NOT set the MLO offset to '0' which will corrupt the file
-    system on the card.
-
-.. note::
-   This application will flash the image at required offset without taking
-   into consideration any overwriting to previously flashed image.
-
-|
-
-Booting via MMCSD
-''''''''''''''''''''
-
-#. Set the OMAPL138/C6748 LCDK to MMCSD bootmode by configuring the SW1
-   DIP switches 1-4 to 'OFF OFF OFF ON'. Other switch positions on SW1
-   are don’t care for MMCSD boot.
-#. Connect the USB serial port of the EVM to host PC. Open serial
-   communication applications like TeraTerm, MiniCom, etc and configure
-   for ‘115200 8N1’
-#. Power on the board
-
-Below is an example of OMAPL138 SBL successfully booting the GPIO LED
-blink application
-
-.. Image:: /images/Omapl138_boot_example.png
-
-|
-
-Memory Usage
-^^^^^^^^^^^^^^^
-
-SBL uses 0x20000 bytes from shared RAM (0x80000000 to 0x8001FFFF).
-
-|
-
-.. note::
-   app should not have loadable sections residing in SBL memory region to
-   prevent overwriting SBL during load time. It is, however, free to use
-   SBL memory after it is loaded and running.
-
-|
-
-Additional Details
-^^^^^^^^^^^^^^^^^^^^
-
-Use below commands to clean and build the SBL and associated tools.
-
-Initial Steps
-"""""""""""""""
-
-Setup the environment variables to configure the build tools
-
-cd <PDK_INSTALL_DIR>/packages
-
-Run pdksetupenv script
-
-cd ti/boot/sbl
-
-Cleaning SBL
-"""""""""""""""
-
-gmake clean SOC=<SoC Name> BOARD=<Board Name> BOOTMODE=<Boot Mode>
-
-Building SBL
-"""""""""""""""
-
-gmake SOC=<SoC Name> BOARD=<Board Name> BOOTMODE=<Boot Mode>
-
-Cleaning Flash Writer
-""""""""""""""""""""""
-
-gmake <Flash Writer>_clean SOC=<SoC Name> BOARD=<Board Name>
-BOOTMODE=<Boot Mode>
-
-building-flash-writer
-""""""""""""""""""""""
-
-gmake <Flash Writer> SOC=<SoC Name> BOARD=<Board Name> BOOTMODE=<Boot
-Mode>
-
--  use 'make' instead of 'gmake' on Linux host
--  <SoC Name> - OMAPL137, OMAPL138 or C6748
--  <Board Name> - evmOMAPL137, lcdkOMAPL138 or lcdkC6748
--  <Boot Mode> - spi or mmcsd as supported by the device
--  <Flash Writer> - spi_flashwriter for spi boot mmcsd_flashwriter for
-   mmcsd boot
-
-::
-
-     Examples:
-     Cleaning & Building OMAPL137 SBL
-     gmake clean SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi
-     gmake SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi
-
-     Cleaning & Building OMAPL137 flash writer
-     gmake spi_flashwriter_clean SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi
-     gmake spi_flashwriter SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi
-
-On successful build, SBL .out and MLO will be created at
-**<PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/<Board Name>/<Boot
-Mode>/bin** and flash writer binary will be created at
-**<PDK_INSTALL_DIR>/packages/ti/boot/sbl/tools/flashWriter/<Boot
-Mode>/bin/<Board Name>**
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Board_Support.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Board_Support.rst
deleted file mode 100644
index abd89a519..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Board_Support.rst
+++ /dev/null
@@ -1,961 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Board_Support
-
-Introduction
--------------
-
-Board library contains a set of general initialization and setup
-functions that are board-specific. This component includes libraries
-for boards supported in the Processor SDK release. Refer to the
-package content for the list of supported boards.Board component also
-includes diagnostic software. Refer to `Processor SDK RTOS
-DIAG <index_board.html#diagnostics>`__ for additional details on
-available diagnostic examples.
-
-Board APIs
-^^^^^^^^^^^
-
-The Board_init() API supports initialization of PLL, peripheral clocks,
-external DDR memory, pinmux and IO Delay configurations. API Reference
-for application:
-
-::
-
-   #. include <ti/board/board.h>
-
-|
-
-Example API pseudo code for Board_init() is as follows:
-
-::
-
-   /* Setting up for pinmux and uart */
-   Board_STATUS ret;
-   Board_initCfg boardCfg;
-
-   boardCfg = BOARD_INIT_MODULE_CLOCK \| BOARD_INIT_PINMUX_CONFIG \|
-   BOARD_INIT_UART_STDIO;
-
-   ret = Board_init(boardCfg);
-
-|
-
-LLD Dependencies
-^^^^^^^^^^^^^^^^^
-
-I2C
-""""
-
-Application need to configure **BOARD_INIT_MODULE_CLOCK** option to have
-I2C operational. I2C is used to read EEPROM data. An I2C handle will be
-opened in polling mode, and closed after the board ID data is retrieved
-from EEPROM using Board_getIDInfo() API.
-
-For DRA7xx EVMs, I2C is also used to configure various I/O expanders and
-board muxes to enable PDK examples to function properly on the EVM. The
-I2C handles are opened in polling mode and closed after the board mux
-initialization has completed.
-
-UART
-"""""
-
-Application need to configure Board_init() with the
-**BOARD_INIT_UART_STDIO** option to use the UART stdio API.
-
-After Board_init() completes, application can invoke UART stdio
-functions such as UART_printf, UART_scanFmt, and etc.
-
-SCICLIENT
-""""""""""
-
-AM65xx/J7xx Board library uses sciclient APIs for configuring the PLL clocks.
-
-
-Application Integration for AM5x/DRA7xx
-----------------------------------------
-
-When configuring pinmux with IO Delay settings for **AM5x** and
-**DRA7xx** boards, there is a hard restriction: the code/data/stack
-during the IO Delay setup must be within local internal memory. Refer to
-SOC TRM for additional information.
-
-The board library specifies two sections for users to define for the
-sole purpose of meeting this requirement. They are:
-**BOARD_IO_DELAY_CODE** and **BOARD_IO_DELAY_DATA**. Below are examples
-of how to specify these section into the local memory, OCMC_RAM1:
-
-In baremetal case with a linker cmd file:
-
-::
-
-   BOARD_IO_DELAY_CODE : {
-
-      . = ALIGN(4);
-      *(BOARD_IO_DELAY_CODE*)
-
-   } > OCMC_RAM1
-
-   BOARD_IO_DELAY_DATA : {
-
-      . = ALIGN(4);
-      *(BOARD_IO_DELAY_DATA*)
-
-   } > OCMC_RAM1
-
-|
-
-In a CCS RTSC project with .cfg file:
-
-::
-
-   Program.sectMap["BOARD_IO_DELAY_DATA"] = "OCMC_RAM1";
-   Program.sectMap["BOARD_IO_DELAY_CODE"] = "OCMC_RAM1";
-
-|
-
-Considerations for DRA7xx devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When integrating the board library in applications on DRA7xx, these
-code/data sections will likely overlap and conflict with the code/data
-sections used by the Secondary Boot Loader (SBL) as both modules will
-assume full access to OCMC_RAM1. Also, as the SBL performs identical
-configuration using the common pad config data structures, the pinmux
-request made by an application will be redundant. Therefore, it is
-advised that the pinmux API be used only when loading the application
-via CCS. When loading via SBL, there are three options available for
-handling this conflict:
-
-#. Place the BOARD_IO_DELAY_DATA/BOARD_IO_DELAY_CODE sections to another
-   internal memory location. The Board library will check to see if the
-   board code/data/stack are located in internal memory before executing
-   the sequence. If another internal memory section is available for
-   placement (e.g. L2SRAM, OCMC_RAM2), then it is acceptable to place
-   the sections in these locations. The Board init sequence will proceed
-   as expected.
-#. Place the BOARD_IO_DELAY_DATA/BOARD_IO_DELAY_CODE sections into
-   external memory. The pinmux subroutine in the Board library checks
-   for code/data/stack placement and will fail if it detects that they
-   reside in DDR and return before performing the configuration. The
-   failure will not affect any other Board init requests as other flags
-   are treated orthogonally.
-#. Remove the BOARD_IO_DELAY_DATA/BOARD_IO_DELAY_CODE sections. This is
-   the preferred solution as it removes redundant code from executing
-   and will optimize code/data size and load speed. In order to remove
-   these sections, two modifications are required:
-
-   -  Place BOARD_IO_DELAY_DATA/BOARD_IO_DELAY_CODE input sections into
-      an output Dummy Section (DSECT). DSECTs are a `Special Linker
-      Section
-      Type <http://processors.wiki.ti.com/index.php/Linker_Special_Section_Types#DSECT_Sections>`__
-      which are relocated for linker resolution but otherwise do not
-      allocate space to a memory map, place sections in the output file,
-      or ever get loaded to the target. In order to place these sections
-      into DSECTS, modify the placement as follows:
-
-Replace:
-::
-
-   Program.sectMap["BOARD_IO_DELAY_DATA"] =
-   "OCMC_RAM1"; Program.sectMap["BOARD_IO_DELAY_CODE"] = "OCMC_RAM1";
-|
-
-With:
-
-::
-
-   Program.sectMap["BOARD_IO_DELAY_DATA"] = new
-   Program.SectionSpec(); Program.sectMap["BOARD_IO_DELAY_CODE"] = new
-   Program.SectionSpec(); Program.sectMap["BOARD_IO_DELAY_DATA"].type =
-   "DSECT"; Program.sectMap["BOARD_IO_DELAY_CODE"].type = "DSECT";
-
-|
-
--  Remove the BOARD_INIT_PINMUX_CONFIG flag from the call to Board_init.
-   Since the BOARD_IO_DELAY_DATA/BOARD_IO_DELAY_CODE sections no longer
-   actually exist, we must instruct the application that it is no longer
-   safe to call the routines and access the data. Otherwise, the CPU
-   will branch to and access undefined memory and cause various
-   exceptions
-
-Custom Board Addition
-----------------------
-This section provides the guidelines for creating a custom board library.
-
-Below image shows the recommended sequence to be followed while porting processor SDK to custom board.
-
-.. Image:: /images/prsdk_rtos_custom_board_porting_steps.png
-
-Board Configurations
-^^^^^^^^^^^^^^^^^^^^^^
-Board library supports different SoC and HW board specific configuration functions.
-Below table shows configurations supported by board library across different platforms.
-
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|         Board Configuration         |    Description          |            References               |   J721E   |  AM65xx   |  AM57xx   |  AM437x   |  AM335x   |   K2G   |  K2-E/H/K/L   |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+=====================================+=========================+=====================================+===========+===========+===========+===========+===========+=========+===============+
-|                                     | Configures pinmux for   |   `Pinmux Tool`_                    |           |           |           |           |           |         |               |
-|    Pinmux                           | interfaces on the HW    |                                     |     x     |     x     |     x     |     x     |     x     |    x    |               |
-|                                     | board.                  |                                     |           |           |           |           |           |         |               |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | Enables power domains   |                                     |           |           |           |           |           |         |               |
-|    SoC Clock Settings               | and clocks for SoC      |   `Clock Tree Tool`_                |     x     |     x     |     x     |     x     |     x     |    x    |       x       |
-|                                     | peripherals             |                                     |           |           |           |           |           |         |               |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | Configures DDR/EMIF     |                                     |           |           |           |           |           |         |               |
-|    DDR Configuration                | controller and DDR      |   `EMIF Tools Appnote`_             |     x     |     x     |     x     |           |           |    x    |       x       |
-|                                     | timing parameters.      |                                     |           |           |           |           |           |         |               |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | Configures PLL modules  |                                     |           |           |           |           |           |         |               |
-|    PLL Configuration                | to generate various     |    NA                               |     x     |     x     |     x     |           |           |    x    |       x       |
-|                                     | clocks used by the SoC. |                                     |           |           |           |           |           |         |               |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | Configures Ethernet     |                                     |           |           |           |           |           |         |               |
-|    Ethernet Configuration           | PHYs on the board.      |    NA                               |     x     |     x     |     x     |     x     |     x     |    x    |               |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | Defines IO instances    |                                     |           |           |           |           |           |         |               |
-|    IO Instances                     | for HW interfaces.      |    NA                               |     x     |     x     |     x     |     x     |     x     |    x    |       x       |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | EEPROM board ID for     |                                     |           |           |           |           |           |         |               |
-|    Board Detection                  | board detection.        |    NA                               |     x     |     x     |     x     |     x     |     x     |    x    |               |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | Provides Common APIs for|                                     |           |           |           |           |           |         |               |
-|    Board Flash APIs                 | accessing flash devices.|    NA                               |     x     |     x     |           |     x     |     x     |    x    |       x       |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-|                                     | Configures SerDes       |                                     |           |           |           |           |           |         |               |
-|    SerDes Configuration             | interface internal      |    NA                               |     x     |     x     |           |           |           |         |               |
-|                                     | muxing and basic setup. |                                     |           |           |           |           |           |         |               |
-|                                     |                         |                                     |           |           |           |           |           |         |               |
-+-------------------------------------+-------------------------+-------------------------------------+-----------+-----------+-----------+-----------+-----------+---------+---------------+
-
-.. _Pinmux Tool: http://processors.wiki.ti.com/index.php/TI_PinMux_Tool
-.. _Clock Tree Tool: http://www.ti.com/tool/CLOCKTREETOOL
-.. _EMIF Tools Appnote: FAQ.html#useful-ddr-configuration-resources
-
-
-Adding custom board library can follow two approaches as mentioned below
-
-|  **Approach 1**: Update files in existing TI board library and modify for custom board.
-|  This approach will be less time consuming since the board library setup is already existing
-   in the processor SDK, but need to maintain TI board library separately for reference.
-|
-|  **Approach 2**: Add custom board to PDK build
-|  This approach involves one time effort of setting up the custom board library but makes it easy
-   to switch between custom board library and TI reference board library. In this approach during migration
-   to updated processor SDK, review and selective updates from existing TI board reference source will need to be considered.
-|
-|
-   Refer the section `Board Library Creation with Custom Name <index_board.html#creating-board-library-with-custom-name>`_
-   for additional steps involved in creating board library with Approach 2.
-|
-
-Creating Board Configurations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Before updating the board library with configurations for custom board, it is recommended to use
-GEL file and CCS for validating the configurations.
-Follow the steps mentioned below
-
-- Update the SoC clock configurations in the GEL file.
-  TI provides `Clock Tree Tool <http://www.ti.com/tool/CLOCKTREETOOL>`_ to simulate the device clocks.
-- Update the PLL clock configurations in GEL file if custom board uses a different input clock than the eval platform and/or needs different clock outputs.
-- Update DDR PHY and timing configurations for custom board.
-  Refer the guidelines described in `Application Report on EMIF Tools <FAQ.html#useful-ddr-configuration-resources>`_
-- After GEL file update is complete, connect to custom board using JTAG, run the GEL script to apply the modified configurations and verify the configured values.
-  Load and run simple hello world example out of SoC internal memory and DDR memory.
-
-
-Updating Board Configurations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Steps for updating the board library configurations for a custom board is described in this section.
-Updating some of the configurations may need additional steps based on the platform.
-Refer `Platform Specific Configuration <index_board.html#platform-specific-configurations>`_ section for more details.
-
-Pinmux
-"""""""
-When the **BOARD_INIT_PINMUX_CONFIG** option is specified, the
-Board_init() API configures the pinmux for the board. If applicable,
-it will also configure IO delay values for those device pads, which
-ensures correct IO timings are met along with the pinmux settings.
-Refer SOC TRM for additional details.
-
-The pinmux data to be configured is generated by the TI pinmux tool.
-Refer to `TI PinMux
-Tool <http://processors.wiki.ti.com/index.php/TI_PinMux_Tool>`__ for
-more information.
-
-Once the pinmux selection is done, Copy the pinmux tool generated files to your custom board library
-implementation folder.
-
-Refer `Platform Specific Configuration <index_board.html#platform-specific-configurations>`_ section for more details on the files generated
-by pinmux tool for different platforms.
-
-SoC Clock Settings
-"""""""""""""""""""""
-The core clocks and module clocks used on the custom board library may
-vary based on the power requirements and external components used on the
-boards.
-
-<Board>_clock.c: Defines functions and structures for configuring the clock and power modules.
-Update this file based on the data from clock tree tool and GEL file validation.
-
-DDR Configuration
-"""""""""""""""""""""
-The board library has the correct DDR initialization sequence to initialize
-the DDR memory on your board. You may need to make changes to the AC timings,
-hardware leveling, and DDR PHY configuration, some or all of which may be
-different than the TI supported platforms. GEL file can be used to verify
-the settings in CCS before modifying the source in the board library.
-
-<Board>_ddr.c: Defines functions and structures for configuring the DDR module.
-Update this file based on the DDR timing parameters specific to custom board.
-
-PLL Configuration
-""""""""""""""""""""
-The SOC board library in the PDK configures the SOC PLL and module clock
-settings to the nominal settings required to be used with the TI
-evaluation platform. If you want to use different clock settings due to
-power consideration, or if you are using a variant of the device that
-needs to be clocked differently, you can enter the PLL and clock
-settings in the board library. All of the PLL and module clock settings
-are consolidated in the following files:
-
-- <Board>.c: Contains calls related to all board-level initialization.
-  <Board> refers to the evaluation platform (For example, evmam335x)
-- <Board>_pll.c: Defines the Board_PLLInit() function that configures the
-  dividers and multipliers for the clock tree.
-
-Ethernet Configuration
-"""""""""""""""""""""""
-The custom board may have external components (flash devices, Ethernet
-PHY, etc.) that are different from the components populated on the
-TI-supported EVM. These components and their support files need to be
-added to the
-pdk_xx_xx_xx_xx/packages/ti/board/src/<customBoardName>/device path
-and linked as part of the board library build.
-
-IO Instances
-"""""""""""""
-If your custom board uses an IO instance different from the TI-supported
-board, the instance needs to be modified in the Pin Mux setup as well
-as in the board_cfg.h file in
-pdk_xx_xx_xx_xx/packages/ti/board/src/<customBoardName>/include
-
-Board Detection
-'''''''''''''''''
- - TI defined board detect mechanism using structure stored in I2C EEPROM
- - Board Lib APIs read and write Board ID to EEPROM on I2C address 0x50
- - Application boards, if available, will have their own EEPROM with board information
- - Structure typically defines:
-
-::
-
-    Board ID (IDK vs GP EVM vs custom)
-    Revision number (board revision to address board level issues)
-    Serial Number (internal tracking)
-    MAC ID  (Custom MAC ID use)
-|
-.. note::
-   Board detection is TI defined mechanism to detect evaluation platform details.
-   This needs to be removed/replicated from board based on customer board implementation.
-   In case board detect mechanism is not used in custom board, check for the Board_getIDInfo() API calls
-   and make necessary changes in the code to avoid dependencies on board detect mechanism.
-
-Board Flash APIs
-'''''''''''''''''
-Board library includes a dedicated flash library to abstract the HW flash interface access
-using a standard set of APIs. In case custom board uses flash devices that are different
-from eval platform, update to board flash APIs is required.
-Check the board flash library available at <PDK_INSTALL_PATH>/packages/ti/board/src/flash and
-make changes required for custom board as needed.
-
-
-Platform Specific Configurations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-J721E
-"""""""
-
-Board File Names
-'''''''''''''''''
-Board library file names for J721E are different when compared with other platforms in processor SDK.
-This is to facilitate the easy migration of board library to custom platforms.
-Read the file name <Board>.c as board_init.c and <Board>_xxx.c/h as board_xxx.c/h in all the
-references in above sections.
-
-Pinmux
-'''''''
-Follow below steps to update pinmux configuration for custom board on J721E platform.
-Pinmux project files provided under j721e_evm board folder can be used as reference for pinmux configuration.
-
-* Download the pinmux files <Platform Name>_pinmux.h and <Platform Name>_pinmux_data.c generated by pinmux tool
-  and copy them to custom board folder.
-* Open 'packages/ti/board/src/j721e_evm/<Platform Name>_pinmux.h' and make below modifications.
-
-   * Change #include "pinmux.h" to #include <ti/board/src/j721e_evm/include/pinmux.h>
-   * Change #include "csl_types.h" to #include <ti/csl/csl_types.h>
-     * Modify 'j721e_evm' in above step if a different name is used for custom board.
-
-.. tip::
-
-    <Platform Name>_pinmux.h file contains the basic pin definition macros which will not change with every
-    pin configuration change. This file generation and above step is one time configuration
-    for a given pinmux tool version.
-
-* Modify the Board_pinmuxConfig() function in 'packages/ti/board/src/j721e_evm/board_pinmux.c' file to remove
-  pinmux configurations specific to EVM addon boards.
-  Look for the comment "Pinmux for Application cards" in the function Board_pinmuxConfig().
-  All the code after this comment till end of the function and 'i2cPinmux' variable can be removed.
-  Board_pinmuxConfig function shall look as below after the update
-
-::
-
-    Board_STATUS Board_pinmuxConfig (void)
-    {
-        Board_STATUS status = BOARD_SOK;
-
-        /* Pinmux for baseboard */
-        Board_pinmuxUpdate(gJ721E_MainPinmuxData,
-                           BOARD_SOC_DOMAIN_MAIN);
-        Board_pinmuxUpdate(gJ721E_WkupPinmuxData,
-                           BOARD_SOC_DOMAIN_WKUP);
-
-        return status;
-    }
-|
-
-* Rebuild the board library with new pinmux configurations
-
-Follow additional steps (optional) below to clean-up the TI EVM addon board specific files.
-
-* Remove below files from SRCS_COMMON build configuration in 'packages/ti/board/src/j721e_evm/src_files_j721e_evm.mk'
-  and remove the files from the board folder 'packages/ti/board/src/j721e_evm'
-
-   * J721E_pinmux_data_gesi.c
-   * J721E_pinmux_data_gesi_cpsw9g.c
-   * J721E_pinmux_data_info.c
-
-SerDes Configuration
-'''''''''''''''''''''
-J721E board library includes SerDes module which configures the SerDes interface internal pinmux
-to route PCIe, USB and SGMII to different interfaces on the board. If custom board uses
-similar design, SerDes configurations (board_serdes_cfg.c) can be reused.
-Otherwise this configuration can be ignored.
-
-AM65xx
-"""""""
-
-Pinmux
-'''''''
-Follow below steps to update pinmux configuration for custom board on AM65xx platforms.
-
- - Download the pinmux files <Platform Name>_pinmux.h and <Platform Name>_pinmux_data.c generated by pinmux tool
- - Copy the files to custom board folder and rename them to match with board name if needed.
- - Rebuild the board library with new pinmux configurations
-
-SerDes Configuration
-'''''''''''''''''''''
-AM65xx board library includes SerDes module which configures the SerDes interface internal pinmux
-to route PCIe, USB and SGMII interfaces to different personality cards. If custom board uses
-similar design, SerDes configurations can be reused. Otherwise this configuration can be ignored.
-
-
-AM57xx
-"""""""
-Pinmux
-'''''''
-Pinmux tool output for AM57xx platform includes IO delay information.
-Below are the files generated by pinmux tool:
-
-- boardPadDelay.h: Includes the prototypes of all structures and functions used
-  by pinmux functions
-
-- boardPadDelayInit.c: Includes the pinmux pad config data for all device pads
-  along with values used to compute Manual/Virtual mode values.This data is used
-  to configure pinmux during board initialization.
-
-- boardPadDelayTune.h: This file includes the compile time macros used to select
-  the Timing modes to be configured for modules during board Initialization.
-
-- boardPadDelayDevice.c: This file includes the pinmuxdata for runtime pinmux
-  configuration of the MMC module.
-
-Copy the above listed files generated by pinmux tool to custom board folder and
-rebuild the board library with updated pinmux configurations.
-
-AM335x/AM437x
-"""""""""""""""
-Pinmux
-'''''''
-Follow below steps to update pinmux configuration for custom board on AM335x/AM437x platforms.
-
-- Download the pinmux files <Platform Name>pinmux.h and <Platform
-  Name>_pinmux_data.c generated by pinmux tool
-
-- At the bottom of <Platform Name>pinmux.h change extern pinmuxBoardCfg_t
-  g<Platform Name>PinmuxData[]; to extern pinmuxBoardCfg_t g<Custom Board
-  Name>PinmuxData[];
-
-- Change <Platform Name>_pinmux_data.c to <Platform Name>_<Custom Board
-  Name>pinmux_data.c
-
-- Change g<Platform Name>PinmuxData to g<Custom Board Name>PinmuxData at the end
-  of the file in <Platform Name>_<Custom Board Name>pinmux_data.c
-
-- The last step is to invoke the PinMuxModuleConfig in the file
-  <BoardName>_pinmux.c that is found at
-  <PDK_INSTALL_PATH>\packages\ti\board\src\<BoardName>.
-
-For Example to add three instances of UART in the pinmux setup, users can add:
-
-::
-
-    /* UART */
-     status = PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 0U, NULL);
-     status = PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 1U, NULL);
-     status = PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 4U, NULL);
-
-- Rebuild the board library with new pinmux configurations
-
-K2G
-""""
-Pinmux
-'''''''
-Follow below steps to update pinmux configuration for custom board on K2G platforms.
- - Download the pinmux files <Platform Name>pinmux.h and <Platform Name>_pinmux_data.c generated by pinmux tool
- - Copy the files to custom board folder and rename them to match with board name if needed.
- - Rebuild the board library with new pinmux configurations
-
-
-Custom Board Validation
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-Validate the basic functionality of custom board using hardware diagnostics before bringing-up
-RTOS applications or Linux. Hardware diagnostics help verify the functionality of on-board
-peripherals and external interfaces of each board.
-
-Refer `Board Diagnostics <index_board.html#diagnostics>`_ section for more details on the
-diagnostic tests supported as part of processor SDK.
-
-Below are the recommended diagnostic tests which can be validated on custom board
-
- - External memory (DDR): DDR timing and leveling setting can be checked out using mem_test
- - Debug UART: Debug UART pin functionality
- - Boot Media: Validate functionality of SD/MMC, OSPIor any other boot interfaces
- - Board ID/EEPROM test: Recommend checking out/writing ID on personality EEPROM.
-   This also checkout I2C pin functionality
- - Ethernet PHY: Ethernet diagnostics tests read PHY configuration over MDIO and
-   check for Link up status. Good first step before bringing up any network stack
-
-
-Creating Board Library with Custom Name
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section describes how to create a board library with custom name using
-AM572x as an example. Due to dependencies on the starterware, AM335x/AM437x
-board library creation is different and is described in the
-`section for AM335x/AM437x <index_board.html#creating-custom-board-library-for-am335x-and-am437x>`__.
-
-As mentioned in section `Board Configurations <index_board.html#board-configurations>`__,
-adding custom board library can follow one of two approaches. This section provides detailed
-instructions for the second approach - adding a custom board to PDK build.
-
-Instructions to add custom Board to the PDK build
-""""""""""""""""""""""""""""""""""""""""""""""""""
-Follow below steps for creating board library with custom name.
-AM572x platform is used as reference in the examples wherever needed.
-
-**Step 1: Creating new directory for custom board library**
-
-In <PDK_INSTALL_PATH>/packages/ti/board/src,
-create new directory myCustomBoard and copy files from existing board
-library package which closely matches your custom board design.
-
-**Step 2: Updating names and makefile inside the customBoard package**
-
-In <PDK_INSTALL_PATH>/packages/ti/board/src/myCustomBoard, rename file
-src_files_<Board>.mk to src_files_myCustomBoard.mk. This file will
-need a bit of work depending on what elements of board you need for your
-platform. At a minimum, modify SRCDIR and INCDIR to have correct paths to
-the newly created directory in previous step:
-
-::
-
-    SRCDIR += src/myCustomBoard src/myCustomBoard/device src/myCustomBoard/include
-    INCDIR += src/myCustomBoard src/myCustomBoard/device src/myCustomBoard/include
-
-**Step 3: Adding MACRO based inclusion of updated board_cfg.h
-corresponding to custom Board**
-
-In packages/ti/board/board_cfg.h, add the lines pointing to board_cfg.h
-file in your customBoard package so that updated peripheral instances
-and board specific defines can be picked up
-
-::
-
-    #if defined (myCustomBoard)
-    #include <ti/board/src/myCustomBoard/include/board_cfg.h>
-    #endif
-
-**Step 4: Update top level board package makefile to include build for
-customBoard library**
-
-Modify makefile packages/ti/board/build/makefile.mk which includes all relevant
-makefiles for low level driver(LLD), source files relevant to
-board and the common board.c file.
-
--  Add customBoard build for board.c and boardStub.c (notice the newly added
-   myCustomBoard):
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD),evmAM335x icev2AM335x skAM335x bbbAM335x evmAM437x idkAM437x skAM437x myCustomBoard evmAM572x idkAM571x idkAM572x evmK2H evmK2K evmK2E evmK2L evmK2G iceK2G evmC6678 evmC6657))
-    # Common source files across all platforms and cores
-    SRCS_COMMON += board.c
-    endif
-
-    ifeq ($(BOARD),$(filter $(BOARD),evmAM335x icev2AM335x iceAMIC110 skAM335x bbbAM335x evmAM437x idkAM437x skAM437x myCustomBoard evmAM572x idkAM571x idkAM572x evmK2H evmK2K evmK2E evmK2L iceK2G evmC6678 evmC6657 evmOMAPL137 lcdkOMAPL138 idkAM574x evmDRA72x evmDRA75x evmDRA78x evmTDAxx j721e_sim j721e_qt j7200_evm tpr12_evm))
-    # Board stub function enabled for all the boards except evmK2G
-    SRCS_COMMON += boardStub.c
-    endif
-
-
--  Add customBoard build for board library source files and LLD files:
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard evmAM572x idkAM571x idkAM572x))
-    include $(PDK_BOARD_COMP_PATH)/src/$(BOARD)/src_files_$(BOARD).mk
-    include $(PDK_BOARD_COMP_PATH)/src/src_files_lld.mk
-    endif
-
-**Step 5: Update Global makerules**
-
-Makefile packages/ti/build/makerules/build_config.mk defines the global CFLAGS
-used to compile different PDK components. Add the following line in the BOARD
-specific configurations:
-
-::
-
-    CFLAGS_GLOBAL_myCustomBoard  = -DSOC_AM572x -DmyCustomBoard=myCustomBoard
-
-The SOC_AM572x macro ensures that the CSL applicable to this SOC will be
-included in the build. Use the SoC name that corresponds to the platform of your custom board.
-
-
-**Optional step to update RTSC platform definition** If you have a
-custom RTSC platform definition for your custom board that updates the
-memory and platform configuration using RTSC Tool then you need to
-update the platform.mk file that associates the RTSC platform with the
-corresponding board library
-
-In packages/ti/build/makerules/platform.mk, add the following lines:
-
-
-::
-
-     ifeq ($(BOARD),$(filter $(BOARD), evmAM572x))
-       PLATFORM_XDC = "ti.platforms.evmAM572X"
-     endif
-
-::
-
-     ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
-       PLATFORM_XDC = "evmAM572XCustom"
-     endif
-
-.. note::
-   The SYSBIOS platforms follow the convention to consolidate all
-   platform definitions under SYSBIOS_INSTALL_PATH/packages/ti/platforms/\*
-   hence the convention ti.platorms.<platformName> but for custom platform,
-   users are not required to follow this convention.
-
-**Step 6: Update source files corresponding to drivers used in board
-library**
-
-Makefile src_files_lld.mk file adds source files corresponding to LLD
-drivers used in the board library. Usually most boards utilize control
-driver like I2C (for programming the PMIC or reading EEPROM), UART
-drivers (for IO) and boot media drivers like (SPI/QSPI, MMC or NAND). In
-the example below, we assume that the custom Board library has
-dependency on I2C, SPI and UART LLD drivers. Since the LLD drivers will
-be linked to the application along with board library, board library
-only needs <driver>_soc.c corresponding to SOC used on the custom Board.
-
-In packages/ti/board/src/src_files_lld.mk, add the following lines:
-
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
-    SRCDIR +=  $(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x
-
-::
-
-    INCDIR +=  $(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x \
-               $(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x
-
-::
-
-    # Common source files across all platforms and cores
-    SRCS_COMMON += I2C_soc.c UART_soc.c SPI_soc.c
-    endif
-
-
-.. note::
-   For all LLD drivers linked to the board library you need to include
-   corresponding <drv>_soc.c file. For example if you include GPIO driver
-   for setting board mux then GPIO_soc.c needs to be added to LLD source
-   files.
-
-**Step 7: Add custom Board to BOARDLIST and update CORELIST**
-
-In packages/ti/board/board_component.mk, modify the build to add your
-custom board and specify the cores for which you want to build the board
-library. Example to build board library for only A15 and C66x cores,
-limit the build by specify only a15_0 and C66x in the CORELIST
-
-::
-
-    board_lib_BOARDLIST       = myCustomBoard evmAM335x icev2AM335x skAM335x bbbAM335x evmAM437x idkAM437x skAM437x evmAM572x idkAM571x idkAM572x evmK2H evmK2K evmK2E evmK2L evmK2G iceK2G \
-
-::
-
-    #board_lib_am572x_CORELIST = c66x a15_0 ipu1_0
-    board_lib_am572x_CORELIST = a15_0 c66x
-
-**Step 8: Update .bld files for XDCTOOL based build steps**
-
-Make corresponding changes in packages/ti/board/config.bld, by adding
-the following lines:
-
-::
-
-    var myCustomBoard = {
-       name: "myCustomBoard",
-       ccOpts: "-DmyCustomBoard -DSOC_AM572x",
-       targets: [C66LE,A15LE ]
-    }
-
-::
-
-    var boards = [ evmAM335x, icev2AM335x, skAM335x, bbbAM335x, evmAM437x, idkAM437x, skAM437x, myCustomBoard, evmAM572x, idkAM571x, idkAM572x, evmK2H, evmK2K, evmK2E, evmK2L, evmK2G, evmC6678, evmC6657 ];
-
-Also, in packages/ti/board/package.bld, add the following line:
-
-::
-
-    Pkg.otherFiles[Pkg.otherFiles.length++] = "src/myCustomBoard/src_files_myCustomBoard.mk";
-
-
-**Step 9: Add custom board to board list**
-
-Add myCustomBoard to AM572x board list in file packages/ti/build/soc_info.mk:
-
-::
-
-    BOARD_LIST_am572x = evmAM572x idkAM572x myCustomBoard
-
-
-**Step 10: Build the custom board library with the updated settings**
-
-First change directory to <PDK_INSTALL_PATH>/packages and run pdksetupenv.bat.
-
-Then change directory to <PDK_INSTALL_PATH>/packages/ti/board and build the board library:
-
-::
-
-    gmake LIMIT_SOCS=am572x LIMIT_BOARDS=myCustomBoard LIMIT_CORES=a15_0
-
-
-Creating Custom Board Library for AM335x and AM437x
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section describes how to create a custom board library for AM335x/AM437x.
-Currently the AM335x and AM437x board libraries reuse the board support code in
-legacy starterware (now part of the PDK). Therefore, rebuilding the board
-library involves compiling the starterware source code. Both approaches of
-creating a custom board library are described in this section:
-
-- Modifying an existing TI board
-- Adding a new custom board
-
-Modifying an Existing TI Board for AM335x/AM437x
-""""""""""""""""""""""""""""""""""""""""""""""""
-
-This approach is less time consuming since the board library setup already
-exists in PDK, but requires users to back up the existing TI board library for reference.
-The instructions below use AM335x GP EVM as the existing board to modify. Users
-may choose to modify any other existing board and the procedure is the same.
-
-**Step 1: Generating a new pinmux configuration**
-   - Download and run the `Pinmux Tool`_.
-   - Use "Open an Existing Design" and open <PDK_INSTALL_PATH>/packages/ti/starterware/tools/pinmux_config/am335x/gpevm_config.pinmux.
-   - Use the tool to change the configuration and make sure there are no conflicts.
-   - When configuration is finalized, save the starterware pinmux files as shown below:
-
-.. Image:: /images/pinmux_save_files.jpg
-
-**Step 2: Using newly generated pinmux files for the board to be modified**
-
-- Open am335x_pinmux.h saved in previous step and replace the following line at the bottom of the file
-
-::
-
-  extern pinmuxBoardCfg_t gAM335xPinmuxData[];
-
-with the following lines from <PDK_INSTALL_PATH>/packages/ti/starterware/board/am335x/am335x_pinmux.h:
-
-::
-
-  /** \brief Pinmux configuration data for the board. Auto-generated from
-             Pinmux tool. */
-  extern pinmuxBoardCfg_t gGpevmPinmuxData[];
-
-  /** \brief Pinmux configuration data for the board. Auto-generated from
-             Pinmux tool. */
-  extern pinmuxBoardCfg_t gEvmskPinmuxData[];
-
-  /** \brief Pinmux configuration data for the board. Auto-generated from
-             Pinmux tool. */
-  extern pinmuxBoardCfg_t gBbPinmuxData[];
-
-  /** \brief Pinmux configuration data for the board. Auto-generated from
-             Pinmux tool. */
-  extern pinmuxBoardCfg_t gBbbPinmuxData[];
-
-  /** \brief Pinmux configuration data for the board. Auto-generated from
-             Pinmux tool. */
-  extern pinmuxBoardCfg_t gIceV1PinmuxData[];
-
-  /** \brief Pinmux configuration data for the board. Auto-generated from
-             Pinmux tool. */
-  extern pinmuxBoardCfg_t gIceV2PinmuxData[];
-
-  /** \brief Pinmux configuration data for the board. Auto-generated from
-             Pinmux tool for IceV2, but with AMIC11x naming. Intended for
-             manual deviation from IceV2, if applicable. */
-  extern pinmuxBoardCfg_t gAMIC11xPinmuxData[];
-
-
-- Rename am335x_pinmux_data.c saved in previous step to am335x_gpevm_pinmux_data.c.
-   Then replace the following line toward the end of this file
-
-::
-
-  pinmuxBoardCfg_t gAM335xPinmuxData[] =
-
-
-with
-
-::
-
-  pinmuxBoardCfg_t gGpevmPinmuxData[] =
-
-
-- Replace am335x_pinmux.h and am335x_gpevm_pinmux_data.c in folder
-   <PDK_INSTALL_PATH>/packages/ti/starterware/board/am335x with the two files newly
-   generated and modified above. It is recommended to keep a copy of this folder as
-   a reference before replacing the two files.
-
-**Step 3: Updating board library files accordingly**
-
-- Update pinmux configuration in <PDK_INSTALL_PATH>/packages/ti/board/src/evmAM335x_pinmux.c.
-  For example, to add another UART instance, the following line can be added to
-  function Board_pinmuxConfig():
-
-::
-
-     status = PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 1U, NULL);
-
-- Update power and clocking in <PDK_INSTALL_PATH>/packages/ti/board/src/evmAM335x.c.
-  For example, to enable power and clocking for the second UART instance, the
-  following line can be added to function Board_moduleClockInit():
-
-::
-
-    status = PRCMModuleEnable(CHIPDB_MOD_ID_UART, 1U, 0U);
-
-
-- Update LLD initialization if necessary in <PDK_INSTALL_PATH>/packages/ti/board/src/evmAM335x_lld_init.c.
-  For example, to initialize the second UART, following line can be added to
-  function Board_uartStdioInit():
-
-::
-
-    UART_stdioInit(1);
-
-
-**Step 4: Rebuilding board library for the modified board**
-
-- Setup build environment:
-
-::
-
-    C:\ti\pdk_am335x_1_0_17\packages>pdksetupenv.bat
-
-
-- Rebuild board library:
-
-::
-
-    C:\ti\pdk_am335x_1_0_17\packages\ti\board>gmake LIMIT_SOCS=am335x LIMIT_BOARDS=evmAM335x
-
-
-**Step 5: Rebuilding the boot loader**
-
-After the board library is rebuilt, the application can be built against the new
-board library. If the secondary boot loader is used to initialize the board, the
-boot loader will also need to be rebuilt according to section
-`Building AM335x/AM437x Bootloader <index_Foundational_Components.html#building-the-bootloader>`__.
-
-For example, issue following command under <PDK_INSTALL_PATH>/packages/ti/starterware
-to build MMCSD boot loader for AM335x:
-
-::
-
-    gmake bootloader BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am335x-evm PROFILE=release -s KW_BUILD=no
-
-
-Adding a New Custom Board for AM335x/AM437x
-"""""""""""""""""""""""""""""""""""""""""""
-
-For this approach, due to the board library's dependencies on starterware for AM335x/AM437x,
-additional steps are needed on top of what's described in section
-`Board Library Creation with Custom Name <index_board.html#creating-board-library-with-custom-name>`_.
-Please follow all the steps given in that section to setup the custom board,
-and do the following before building the custom board library:
-
-- First, make sure "var myCustomBoard" is added to packages/ti/board/config.bld
-  and it includes all custom starterware files, especially the pinmux data
-  source file. For example,
-
-::
-
-    var myCustomBoard = {
-        name: "myCustomBoard",
-        ccOpts: "-DmyCustomBoard -DSOC_AM335X -DAM335X_FAMILY_BUILD -Dam335x -DBUILDCFG_MOD_UART -DBUILDCFG_MOD_GPIO  -DBUILDCFG_MOD_I2C  -DBUILDCFG_MOD_MCSPI  -DBUILDCFG_MOD_QSPI -DBUILDCFG_MOD_PRU_ETH -DBUILDCFG_MOD_MMCSD  -DBUILDCFG_MOD_CPSW -DBUILDCFG_MOD_PWMSS -DBUILDCFG_MOD_DSS -DBUILDCFG_MOD_USB -DBUILDCFG_MOD_GPMC -DBUILDCFG_MOD_DCAN -DBUILDCFG_MOD_MCASP -DBUILDCFG_MOD_VPFE -DBUILDCFG_MOD_MDIO -DBUILDCFG_MOD_DMTIMER -DBUILDCFG_MOD_EDMA3CC -DBUILDCFG_MOD_EDMA3TC -DBUILDCFG_MOD_RTC -DBUILDCFG_MOD_WDT -DBUILDCFG_MOD_ADC -DBUILDCFG_MOD_LCDC",
-        stwFiles: ["$(PDK_INSTALL_PATH)/ti/starterware/board/am335x/am335x_myCustomBoard_pinmux_data.c",
-                ...
-    }
-
-- Second, in packages/ti/board/src/src_files_starterware.mk, add custom board
-  build option and add custom pinmux data source file. For example,
-
-::
-
-    ifeq ($(BOARD),$(filter $(BOARD), evmAM335x icev2AM335x iceAMIC110 skAM335x bbbAM335x myCustomBoard))
-                 ...
-
-        ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
-            SRCS_COMMON += am335x_myCustomBoard_pinmux_data.c
-        endif
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Boot.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Boot.rst
deleted file mode 100644
index 5d9bf55a6..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Boot.rst
+++ /dev/null
@@ -1,336 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Boot
-
-.. rubric:: Overview
-   :name: overview-1
-
-| This page provides an overview about the Secondary Bootloader support
-  provided in Processor SDK RTOS.
-
-| The Secondary Bootloader (SBL) sets-up the PLL clocks, powers on the
-  I/O Peripherals, initializes the DDR, loads the application image into
-  DDR & brings the target cores for applicable SOCs out of reset.
-  Additional details including execution boot flow is covered in more
-  elaborate detail under individual SOC section.
-
-.. rubric:: Boot Modes
-   :name: boot-modes
-
-.. rubric:: MMCSD
-   :name: mmcsd
-
-MMCSD bootloader is required to boot target using an SD card containing
-bootloader and application images. When the board is powered ON the ROM
-bootloader detects the MMCSD bootloader image and loads it to the
-internal memory.The bootloader initializes the board, copies the
-application image from SD card to the DDR memory and gives control to
-the application.
-
-.. rubric:: QSPI
-   :name: qspi
-
-A flash device interfaced with QSPI is flashed with QSPI bootloader and
-application images. When the board is powered ON the ROM bootloader
-detects the bootloader image from flash device and loads it to the
-internal memory. The Bootloader initializes the board, copies the
-application image from QSPI device to the DDR memory and gives control
-to the application.
-
-.. rubric:: UART
-   :name: uart
-
-A Serial connection is used for transferring the bootloader binary from
-PC to target board through XMODEM protocol. The bootloader on execution
-prompts for application image to transfer through XMODEM. On providing
-the path, the application binary is transferred through serial
-connection to DDR memory and the control is passed to application to
-execute.
-
-.. rubric:: MCSPI/SPI
-   :name: mcspispi
-
-A SPI flash device flashed with MCSPI/SPI bootloader and application
-images is used for booting the board. When the board is powered ON the
-ROM bootloader detects the bootloader image from flash device and loads
-it to the internal memory. The Bootloader initializes the board, copies
-the application image from flash to the DDR memory and gives control to
-the application.
-
-.. rubric:: NAND
-   :name: nand
-
-NAND flash with bootloader and and application images is used for
-booting the board. When the board is powered ON the ROM bootloader
-detects the bootloader image from flash device and loads it to the
-internal memory. The bootloader initializes the board, copies the
-application image from flash to the DDR memory and gives control to the
-application.
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-For information on boot mode setting, see the applicable :ref:`EVM Hardware
-User Guide <RTOS-SDK-Supported-Platforms>`.
-
-.. raw:: html
-
-   </div>
-
-.. rubric:: `AM335x/AM437x <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM335x/AM437x>`__
-   :name: am335xam437x
-
-Refer `Processor SDK RTOS BOOT
-AM335x/AM437x <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM335x/AM437x>`__ for
-more information including procedure to boot via different modes for all
-supported BOARDs.
-
-.. rubric:: `AM57x <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM57x>`__
-   :name: am57x
-
-Refer `Processor SDK RTOS BOOT
-AM57x <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM57x>`__ for more information
-including procedure to boot via different modes for all supported
-BOARDs.
-
-.. rubric:: `C66x <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_C66x>`__
-   :name: c66x
-
-Refer `Processor SDK RTOS BOOT
-C66x <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_C66x>`__ for more information
-including procedure to boot via different modes for all supported
-BOARDs.
-
-.. rubric:: `K2G <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_K2G>`__
-   :name: k2g
-
-Refer `Processor SDK RTOS BOOT
-K2G <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_K2G>`__ for more information
-including procedure to boot via different modes for all supported
-BOARDs.
-
-.. rubric:: `K2H/K2E/K2L <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_K2H/E/L>`__
-   :name: k2hk2ek2l
-
-Refer `Processor SDK RTOS BOOT
-K2H/E/L <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_K2H/E/L>`__ for more
-information including procedure to boot via different modes for all
-supported BOARDs.
-
-.. rubric:: `OMAPL137/OMAPL138/C6748 <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_OMAPL13x>`__
-   :name: omapl137omapl138c6748
-
-Refer `Processor SDK RTOS BOOT
-OMAPL13x <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_OMAPL13x>`__ for more
-information including procedure to boot via different modes for all
-supported BOARDs.
-
-.. rubric:: Common Steps to debug application boot
-   :name: common-steps-to-debug-application-boot
-
-Bootloading an application is a system level issue which is impacted by
-hardware as well as software setup. There are some common steps that
-users are expected to check while debugging boot related issues. This
-section discusses common issues to checkout when debugging application
-boot.
-
-|
-
-.. rubric:: Hardware Debug Steps
-   :name: hardware-debug-steps
-
-.. raw:: html
-
-   <div class="toccolours" style="width:1600px">
-
-**Input clocks and power sequencing**
-
--  Ensure that correct power sequencing is occurring on your board.
-   Power sequencing specifications can be found in the data manual.
--  Check the system clock and ensure this is outputting the expected
-   frequency and the signal is swinging rail to rail (should be a 1.8V
-   signal). If you have an external oscillator, it should be outputting
-   a square wave at the desired frequency. If you are using a crystal ,
-   you should have a sine wave at the desired frequency at XTALIN.
-   XTALOUT should be similar (may be distorted a little).
--  Check the power on reset signal PORZ. This signal should stay low
-   throughout the power sequencing and go high when the power AND high
-   frequency clock are stable.
--  If the device has an OBSCLK or CLKOUT then ensure that this pin
-   provides the correct output that matches your software
-   configurations.
-
-.. rubric:: **Boot pins:**
-   :name: boot-pins
-
-Best way to confirm what the device ROM bootloader reads from the pins
-is to read the register where the Boot pins are latched into the device:
-
--  For AM335x/AM437x: Check the Control_status register
--  For AM57xs: Check CTRL_CORE_BOOTSTRAP register
--  For C66x/K2X devices: Check the DEVSTAT register
--  For OMAPL13x/C674x devices: Check BOOTCFG register
-
-.. rubric:: **Boot media connectivity**
-   :name: boot-media-connectivity
-
-Users are required to test their boot interface by running boot loader
-independent diagnostic tests that confirm that the SOC can read and
-write from the boot interface. Processor SDK RTOS provides Diagnostic
-utilities for K2G/AMXX devices and provides POST utility for keystone
-devices with which the TI EVM was tested.
-
-TI Technical documentation like Technical reference manual (AMXX
-devices), Bootloader USer guide (for C66x/K2X devices) and Bootloader
-Application notes for OMAPLxx/C674x list default behavior or the ROM
-bootloader and limitations and constraints for each boot mode.
-Application developers need to account for this while designing their
-system to ensure smooth bring up process.
-
-.. rubric:: **Signalling on boot media and reset pins**
-   :name: signalling-on-boot-media-and-reset-pins
-
-If software and other hardware debug steps have not helped identify the
-issue, you may need to hook up a scope or protocol analyzer to check the
-clocks and the data transfers from the boot media to check if there is
-any issues that can be identified. Another commonly known issue that
-impacts boot is noise on the power lines which may cause the SOC to
-reset or cause a hang on the boot core. Provide these scope shots to TI
-on E2E forums so TI engineers can confirm that there are no issues.
-
-.. raw:: html
-
-   </div>
-
-.. rubric:: Software Debug Steps
-   :name: software-debug-steps
-
-.. raw:: html
-
-   <div class="toccolours" style="width:1600px">
-
-.. rubric:: SBL and app Entry points
-   :name: sbl-and-app-entry-points
-
-If you don`t see your bootloader executing post boot, a good sanity
-check is for you to look at the map file for the bootloader and ensure
-that the entry point matches with the location in the TI or GPHeader in
-the boot image. this can be done by looking at the entry point in the
-MLO/_ti.bin/GPheader and ensure that it matches with the location of
-symbol Entry in the .out/map file for the bootloader.
-
-.. rubric:: SBL and App memory map
-   :name: sbl-and-app-memory-map
-
-The SBL execute from device onchip memory so if your application is also
-using Onchip memory in addition to DDR memory, developers need to ensure
-that the code sections in the application do not overlap with memory
-sections that are used by the SBL. This can cause the SBL to hang during
-the application boot process and go into an abort state.
-
-To check what memory region is used by the SBL please locate the map
-file created from building the bootloader.
-
-.. rubric:: Flash Programming verification
-   :name: flash-programming-verification
-
-It is essential to understand that the flash programmer that you use has
-not just the ability to write the image to flash but should also be able
-to verify that the image written to flash matches the image that you
-have created on your host machine. you can use TI flash programming
-utilities as reference and ensure that the production flashing tools use
-a method to erase, write and then verify the boot image that is written
-to the flash.
-
-|
-
-.. rubric:: DDR timings and configuration /SBL
-   :name: ddr-timings-and-configuration-sbl
-
-The Processor SDK bootloader ships with DDR clock and timing settings
-that apply to the external memory devices that have been used in TI
-evaluation platforms. When running the code on custom platforms, users
-may be required to change these setting to match the timings required by
-custom design. We highly recommend that users create a GEL script
-similar to one provided by TI and test the memory interface with the new
-settings before using them in the secondary bootloader to setup external
-memory. `**Processor SDK Diagnostics** <index_board.html#diagnostics>`__
-provides a mem_test that can be used to test read and writes to the
-entire DDR address space for confirming the SOC EMIF settings.
-
-.. rubric:: Emulator based debugging of boot
-   :name: emulator-based-debugging-of-boot
-
-The processor SDK RTOS bootloader is like any other application that can
-be loaded over the emulator and debugged. Steps to connect an emulator
-to the EVM have been described in the :ref:`Hardware Setup Guides <RTOS-SDK-Supported-Platforms>`
-that is linked to the Processor SDK RTOS documentation.
-
-Loading the bootloader over emulator can be very useful step in
-debugging the system boot. Before generating the final binary for
-bootloader, the build generates the .out file for the bootloader which
-is then formatted in a boot format that the ROM bootloader(RBL) can
-interpret. This .out can be loaded over the emulator similar to any
-other application. If you load the debug version of the bootloader, you
-can single step through the code that initializes the SOC and also part
-of the SBL code that loads the app from the boot media.
-
-.. raw:: html
-
-   <div
-   style="margin: 5px; padding: 2px 10px; background-color: #ecffff; border-left: 5px solid #3399ff;">
-
-**NOTE**
-SBL runs from onchip memory so users can load the SBL.out even without
-using the GEL file but using the GEL sometimes helps with putting the
-core in a clean state so usage of the GEL is optional
-
-.. raw:: html
-
-   </div>
-
-**Alternate Approach:**
-
-**Add a spinlock in SBL main**
-
-In some occasions the RBL may load the SBL but there may be some issue
-that you need to debug in the SBL. In this case you can add a spinlock
-loop at the start of main in SBL and allow the first stage boot to
-complete normally and then connect to the core when you connect the core
-will be held in the spinlock condition waiting for you to connect.
-
-Example:
-
-.. code-block:: c
-
-    volatile int exitSpinLock = 0;
-    void Debug_spinLock(void)
-    {
-        while (exitSpinLock == 0) { }
-    }
-
-You will then have to "release" the core by toggling the variable which
-the while loop is blocking on. You can either do this manually by
-halting CCS, examining the variable in the watch window and then
-changing the value before continuing execution on the core, or you can
-use a GEL script.
-
-**Use an IO input to stall the core until user input is received:**
-
-.. code-block:: c
-
-    printf("Hit enter to continue:");
-    getchar();
-
-.. rubric:: System state at boot failure
-   :name: system-state-at-boot-failure
-
-A useful data point for TI to debug boot related issues is to isolate
-commonly known initialization and to understand how far the bootloader
-has executed correctly before it runs into any issues. Users are
-required to capture ARM/DSP clocks, Program counter value, Entry points
-detected, pinmux configuration and confirm DDR initialization and target
-core states. This helps minimize the number of variables in the system
-boot and helps us zero in on the most likely cause for the boot failure.
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Boot_Debug.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Boot_Debug.rst
deleted file mode 100644
index cd6e154fd..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Boot_Debug.rst
+++ /dev/null
@@ -1,197 +0,0 @@
-Common Steps to debug application boot
-----------------------------------------
-
-Bootloading an application is a system level issue which is impacted by
-hardware as well as software setup. There are some common steps that
-users are expected to check while debugging boot related issues. This
-section discusses common issues to checkout when debugging application
-boot.
-
-|
-
-Hardware Debug Steps
-^^^^^^^^^^^^^^^^^^^^^^
-
-.. raw:: html
-
-   <div class="toccolours" style="width:1600px">
-
-**Input clocks and power sequencing**
-
--  Ensure that correct power sequencing is occurring on your board.
-   Power sequencing specifications can be found in the data manual.
--  Check the system clock and ensure this is outputting the expected
-   frequency and the signal is swinging rail to rail (should be a 1.8V
-   signal). If you have an external oscillator, it should be outputting
-   a square wave at the desired frequency. If you are using a crystal ,
-   you should have a sine wave at the desired frequency at XTALIN.
-   XTALOUT should be similar (may be distorted a little).
--  Check the power on reset signal PORZ. This signal should stay low
-   throughout the power sequencing and go high when the power AND high
-   frequency clock are stable.
--  If the device has an OBSCLK or CLKOUT then ensure that this pin
-   provides the correct output that matches your software
-   configurations.
-
-**Boot pins:**
-
-Best way to confirm what the device ROM bootloader reads from the pins
-is to read the register where the Boot pins are latched into the device:
-
--  For AM335x/AM437x: Check the Control_status register
--  For AM57xs: Check CTRL_CORE_BOOTSTRAP register
--  For C66x/K2X devices: Check the DEVSTAT register
--  For OMAPL13x/C674x devices: Check BOOTCFG register
-
-**Boot media connectivity**
-
-Users are required to test their boot interface by running boot loader
-independent diagnostic tests that confirm that the SOC can read and
-write from the boot interface. Processor SDK RTOS provides Diagnostic
-utilities for K2G/AMXX devices and provides POST utility for keystone
-devices with which the TI EVM was tested.
-
-TI Technical documentation like Technical reference manual (AMXX
-devices), Bootloader USer guide (for C66x/K2X devices) and Bootloader
-Application notes for OMAPLxx/C674x list default behavior or the ROM
-bootloader and limitations and constraints for each boot mode.
-Application developers need to account for this while designing their
-system to ensure smooth bring up process.
-
-**Signalling on boot media and reset pins**
-
-If software and other hardware debug steps have not helped identify the
-issue, you may need to hook up a scope or protocol analyzer to check the
-clocks and the data transfers from the boot media to check if there is
-any issues that can be identified. Another commonly known issue that
-impacts boot is noise on the power lines which may cause the SOC to
-reset or cause a hang on the boot core. Provide these scope shots to TI
-on E2E forums so TI engineers can confirm that there are no issues.
-
-.. raw:: html
-
-   </div>
-
-Software Debug Steps
-^^^^^^^^^^^^^^^^^^^^^
-
-.. raw:: html
-
-   <div class="toccolours" style="width:1600px">
-
-.. rubric:: SBL and app Entry points
-   :name: sbl-and-app-entry-points
-
-If you don`t see your bootloader executing post boot, a good sanity
-check is for you to look at the map file for the bootloader and ensure
-that the entry point matches with the location in the TI or GPHeader in
-the boot image. this can be done by looking at the entry point in the
-MLO/_ti.bin/GPheader and ensure that it matches with the location of
-symbol Entry in the .out/map file for the bootloader.
-
-.. rubric:: SBL and App memory map
-   :name: sbl-and-app-memory-map
-
-The SBL execute from device onchip memory so if your application is also
-using Onchip memory in addition to DDR memory, developers need to ensure
-that the code sections in the application do not overlap with memory
-sections that are used by the SBL. This can cause the SBL to hang during
-the application boot process and go into an abort state.
-
-To check what memory region is used by the SBL please locate the map
-file created from building the bootloader.
-
-.. rubric:: Flash Programming verification
-   :name: flash-programming-verification
-
-It is essential to understand that the flash programmer that you use has
-not just the ability to write the image to flash but should also be able
-to verify that the image written to flash matches the image that you
-have created on your host machine. you can use TI flash programming
-utilities as reference and ensure that the production flashing tools use
-a method to erase, write and then verify the boot image that is written
-to the flash.
-
-|
-
-.. rubric:: DDR timings and configuration /SBL
-   :name: ddr-timings-and-configuration-sbl
-
-The Processor SDK bootloader ships with DDR clock and timing settings
-that apply to the external memory devices that have been used in TI
-evaluation platforms. When running the code on custom platforms, users
-may be required to change these setting to match the timings required by
-custom design. We highly recommend that users create a GEL script
-similar to one provided by TI and test the memory interface with the new
-settings before using them in the secondary bootloader to setup external
-memory. `**Processor SDK Diagnostics** <index_board.html#diagnostics>`__
-provides a mem_test that can be used to test read and writes to the
-entire DDR address space for confirming the SOC EMIF settings.
-
-.. rubric:: Emulator based debugging of boot
-   :name: emulator-based-debugging-of-boot
-
-The processor SDK RTOS bootloader is like any other application that can
-be loaded over the emulator and debugged. Steps to connect an emulator
-to the EVM have been described in the :ref:`Hardware Setup Guides <RTOS-SDK-Supported-Platforms>`
-that is linked to the Processor SDK RTOS documentation.
-
-Loading the bootloader over emulator can be very useful step in
-debugging the system boot. Before generating the final binary for
-bootloader, the build generates the .out file for the bootloader which
-is then formatted in a boot format that the ROM bootloader(RBL) can
-interpret. This .out can be loaded over the emulator similar to any
-other application. If you load the debug version of the bootloader, you
-can single step through the code that initializes the SOC and also part
-of the SBL code that loads the app from the boot media.
-
-.. note::
-   SBL runs from onchip memory so users can load the SBL.out even without
-   using the GEL file but using the GEL sometimes helps with putting the
-   core in a clean state so usage of the GEL is optional
-
-
-**Alternate Approach:**
-
-**Add a spinlock in SBL main**
-
-In some occasions the RBL may load the SBL but there may be some issue
-that you need to debug in the SBL. In this case you can add a spinlock
-loop at the start of main in SBL and allow the first stage boot to
-complete normally and then connect to the core when you connect the core
-will be held in the spinlock condition waiting for you to connect.
-
-Example:
-
-::
-
-    volatile int exitSpinLock = 0;
-    void Debug_spinLock(void)
-    {
-        while (exitSpinLock == 0) { }
-    }
-
-You will then have to "release" the core by toggling the variable which
-the while loop is blocking on. You can either do this manually by
-halting CCS, examining the variable in the watch window and then
-changing the value before continuing execution on the core, or you can
-use a GEL script.
-
-**Use an IO input to stall the core until user input is received:**
-
-::
-
-    printf("Hit enter to continue:");
-    getchar();
-
-.. rubric:: System state at boot failure
-   :name: system-state-at-boot-failure
-
-A useful data point for TI to debug boot related issues is to isolate
-commonly known initialization and to understand how far the bootloader
-has executed correctly before it runs into any issues. Users are
-required to capture ARM/DSP clocks, Program counter value, Entry points
-detected, pinmux configuration and confirm DDR initialization and target
-core states. This helps minimize the number of variables in the system
-boot and helps us zero in on the most likely cause for the boot failure.
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics.rst
deleted file mode 100644
index 30882865d..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics.rst
+++ /dev/null
@@ -1,1072 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_DIAG
-
-Overview
------------
-
-The Processor SDK RTOS Diagnostic package is designed to be a set of
-baremetal tests to run on a given board to provide data path continuity
-testing on peripherals. For K2H/K2E/K2L/C66x devices, this functionality
-is provided by `POST <index_board.html#power-on-self-test>`__.
-
-Building the Examples
-----------------------
-
-Pre-requisites to Building
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-#. Set your environment using pdksetupenv.bat or pdksetupenv.sh. The
-   diagnostic application uses the same environment variables as the
-   board library build. Refer to the `Processor SDK RTOS
-   Building <index_overview.html#building-the-sdk>`__ page for
-   information on setting up your build environment.
-#. You will need the following libraries built:
-
--  Board
--  UART
--  GPIO
--  I2C
--  SPI
--  CSL
--  ICSS
--  PRUSS
--  MMCSD
--  EMAC
--  USB
--  UDMA
--  SCICLIENT
-
-(Note: not every library is used for every application, and these
-libraries should come pre-built with any fresh installation of the
-Processor SDK)
-
-Compiling the Diagnostic Applications
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To build the diagnostic examples:
-
-#. **cd <PDK>/packages/ti/board/diag**
-#. **make <BOARD>**
-
-This will make the diagnostic applications for a specific $BOARD.
-Output files will be located in: **<PDK>/packages/ti/board/bin/<BOARD>**
-
-Creating the SD Card Loadable Files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For converting the compiled .out files to a format loadable by TI's
-Secondary Boot Loader (SBL), you must follow these two steps:
-
-#. **out2rprc.exe [.out file] [rprc output]**
-#. **MulticoreImageGen.exe LE 55 [output name] 0 [rprc output]**
-
-Out2rprc.exe and MulticoreImageGen.exe are tools supplied by TI and can
-be located in the **<PDK>/packages/ti/boot/sbl/tools** folder. "rprc
-output" can be any spare name of your choosing. "output name" can also
-be any name of your choosing. **For diagnostic applications, your final
-output name must have the keyword "TEST" in it.** You will have to do
-this process for every .out application you wish to be loadable on the
-SD card.
-
-Alternatively, there is also a make target to automate this process:
-
-#. **cd <PDK>/packages/ti/board/diag**
-#. **make <BOARD>_sd**
-
-This will compile all the applications for a specific $BOARD, and also
-create the SD card loadable files. The output files will be located in:
-**<PDK>/packages/ti/board/bin/<BOARD>/sd**. Note that the framework
-application is named "app" to allow it to be the default application to
-be loaded by the SBL.
-
-.. note::
-    Diagnostic tests on AM65xx platform supports A53 and R5 cores.
-    A53 binary path: <PDK>/packages/ti/board/bin/<BOARD>/sd/armv8.
-    R5 binary path: <PDK>/packages/ti/board/bin/<BOARD>/sd/armv7.
-
-Creating the SPI Flash Loadable Files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-SPI boot shall be the primary boot option for the platforms (Ex: AMIC110
-ICE) which does not support SD card interface. All the diagnostic tests
-are integrated into framework binary for the ease of use in the case of
-SPI boot. Integrated diagnostic framework test binary can be loaded and
-executed through UART port.
-
-Use below command to build the diagnostic tests and create SPI flash
-loadable files.
-
--  **make <BOARD>_spi**
-
-|
-
-Make targets
-^^^^^^^^^^^^^^^
-
-The simplest invocation is to use "make <BOARD>" to compile all the
-applications. Here is a list of make targets implemented for the
-diagnostic makefile:
-
--  **make <BOARD>** - compile all diagnostic applications for one
-   specific BOARD
--  **make clean** - clean and remove all applications for all supported
-   BOARDs
--  **make <BOARD>_clean** - clean and remove all application for one
-   specific BOARD
--  **make <BOARD>_sd** - compile all diagnostic applications for one
-   specific BOARD and create the SD card loadable files with those
-   compiled applications
--  **make <BOARD>_spi** - compile all diagnostic applications for one
-   specific BOARD and create the SPI flash loadable files with those
-   compiled applications
-
-The <BOARD> supported depends on your Processor SDK RTOS variant. Refer
-to following table for available <BOARD> for each Processor SDK RTOS
-variant:
-
-+-----------+-----------+-----------+-----------+-----------+-----------+------------+
-| make      | am335x    | am437x    | am57xx    | k2g       | omapl13x  | AM65xx     |
-| target /  |           |           |           |           |           |            |
-| Variant   |           |           |           |           |           |            |
-+===========+===========+===========+===========+===========+===========+============+
-| <Board>   | evmAM335x | evmAM437x | idkAM572x | evmK2G    | evmOMAPL1 | am65xx_evm |
-|           | skAM335x  | skAM437x  | idkAM571x | iceK2G    | 37        | am65xx_idk |
-|           | bbbAM335x | idkAM437x | evmAM572x |           | (No Boot  | (Supports  |
-|           | icev2AM33 |           | idkAM574x |           | support.  | A53 & R5   |
-|           | 5x        |           |           |           |           | cores)     |
-|           | iceAMIC11 |           |           |           | Diagnosti |            |
-|           | 0         |           |           |           | cs        |            |
-|           |           |           |           |           | need to   |            |
-|           |           |           |           |           | run from  |            |
-|           |           |           |           |           | CCS)      |            |
-+-----------+-----------+-----------+-----------+-----------+-----------+------------+
-
-.. note::
-   OMAPL137 EVM diagnostic tests does not support executing from
-   a boot device. Use the command **make evmOMAPL137** to build the
-   diagnostics. Diagnostics test binaries need to be executed from CCS.
-
-Running the Diagnostic Examples
------------------------------------
-
-Loading through SD Card (Default Method)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Your SD card must be set up to a bootable format. Refer to the
-`Processor SDK RTOS Boot <index_Foundational_Components.html#boot>`__ page
-for information on how the SD card is handled.
-
-You will need to compile the diagnostic applications for your BOARD,
-created their respective SD card loadable files, and copied them onto an
-SD card. You will also need the SBL (renamed to "MLO") on the SD card.
-To do so:
-
-#. cd <PDK>/packages/ti/board/diag
-#. make <BOARD>_sd
-#. copy all the content under <PDK>/packages/ti/board/bin/<BOARD>/sd to
-   your SD card
-#. copy the MLO to your SD card (default location at
-   <PDK>/packages/ti/boot/sbl/binary/<BOARD>/mmcsd
-#. insert your SD card into your board and power on your board
-#. open Terminal emulator program eg: Teraterm to connect to the board's
-   UART console
-
-.. note::
-    Use MAIN UART0 console for running the tests on A53 core and MCU UART console
-    for running the tests on R5 core for AM65xx platform.
-
-#. press the "Hard Reset" button on your board. (This is to force
-   re-booting, and not absolutely necessary. Because Terminal emulator
-   program is opened after boot is powered on, you would've missed the
-   initial printout messages. This step is for demonstration and
-   confidence checking that the board has booted correctly)
-
-.. note::
-    Diagnostic tests on AM65xx platform supports A53 and R5 cores.
-    A53 binary path: <PDK>/packages/ti/board/bin/<BOARD>/sd/armv8.
-    R5 binary path: <PDK>/packages/ti/board/bin/<BOARD>/sd/armv7.
-
-.. note::
-    SBL binary name is different on AM65xx platform and requires
-    system firmware binary also to be copied to SD card.
-    Copy the sbl_mmcsd_img_mcu1_0_release.tiimage file from
-    <PDK>/packages/ti/boot/sbl/binary/mmcsd/<BOARD> to SD card and
-    rename it to tiboot3.bin.
-    Copy the system firmware image <PDK>/packages/ti/drv/sciclient/soc/V0/sysfw.bin to SD card
-    (for AM65xx SR2, copy "sysfw_sr2.bin" instead and rename it "sysfw.bin" on the SD card)
-
-You should see the following screen when board is bootted with diagnostic binaries in SD card:
-
-.. Image:: /images/Diag-screen1.jpg
-
-The framework diagnostic application should be loaded through SBL, and
-gives you the options:
-
--  help - prints the command menu and descriptions of the commands
--  run - run a diagnostic application found on the SD card
--  status - current status of the framework run
-
-Below is an example of running a diagnostic application:
-
-.. Image:: /images/Diag-screen2.jpg
-
-Result of return from above run:
-
-.. Image:: /images/Diag-screen3.png
-
-Loading through SPI Flash
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section describes creating the diagnostic test images for SPI flash
-booting, programming and running them from SPI flash. Currently SPI boot
-is supported only by iceAMIC110 platform.
-
-You will need to compile the diagnostic applications for your BOARD,
-create their respective SPI flash loadable files, and program them onto
-SPI flash. To do so:
-
-#. cd <PDK>/packages/ti/board/diag
-#. make <BOARD>_spi
-#. Start CCS and launch target configuration file for AMIC110 ICE board
-#. Connect the target, load and run the SPI flash writer binary.
-   Prebuilt SPI flash writer is available at **<AM335x
-   PDK>\packages\ti\starterware\tools\flash_writer\spi_flash_writer_AM335X.out**
-#. Choose option 1 to initiate image flashing
-#. Enter the file name as SPI bootloader along with full path **(Ex:
-   <AM335x
-   PDK>\packages\ti\starterware\binary\bootloader\bin\am335x-evm\gcc\bootloader_boot_mcspi_a8host_release_ti.bin)**
-#. Enter offset as 0
-#. Wait until flashing completes successfully
-#. Rerun the SPI flash writer binary and program diagnostic framework
-   loader at offset 20000. Diagnostic framework loader binary will be
-   available at **<AM335x
-   PDK>\packages\ti\board\bin\iceAMIC110\spi\app**
-#. Rerun the SPI flash writer binary and program diagnostic framework at
-   offset 40000. Diagnostic framework binary will be available at
-   **<AM335x PDK>\packages\ti\board\bin\iceAMIC110\spi\framework**
-
-Sample CCS output of SPI flash writer is shown below:
-
-.. Image:: /images/Spi_flash_writer_output.jpg
-
-|
-
-#. open Terminal emulator program eg: Teraterm to connect to the board's
-   UART console
-#. press the "Hard Reset" button on your board. (This is to force
-   re-booting, and not absolutely necessary. Because Terminal emulator
-   program is opened after boot is powered on, you would've missed the
-   initial printout messages. This step is for demonstration and
-   confidence checking that the board has booted correctly)
-
-You should see the following screen:
-
-.. Image:: /images/Amic110_ice_spi_boot_diag1.jpg
-
-|
-| The framework diagnostic application should be loaded through SBL, and
-  gives you the options:
-
--  help - prints the command menu and descriptions of the commands
--  run - run a diagnostic application found on the SD card
--  status - current status of the framework run
-
-Below is an example of running a diagnostic application:
-
-.. Image:: /images/Amic110_ice_spi_boot_diag2.jpg
-
-|
-| Result of return from above run:
-
-.. Image:: /images/Amic110_ice_spi_boot_diag3.jpg
-
-|
-
-Running or debugging on CCS
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To debug your application, CCS can give you access to the chip's memory
-and register values. You can follow the below steps to load and run an
-application in CCS. If you have a SD card loadable image, and is able to
-load your application, you can connect to the A15 core in CCS and load
-symbols without having to load and run the entire application. After
-running "make all" or "make $BOARD", the output files should be
-generated under <PDK>/packages/ti/board/bin/ directory. You will have to
-navigate down to the $BOARD you're building (eg. idkAM572x, evmAM572x,
-etc.) and the $TARGET core you're building for (eg. armv7).
-
-**For the existing diagnostic applications, you may need to define
-PDK_RAW_BOOT before compiling**. This is done by adding the line
-"#define PDK_RAW_BOOT" to an individual application source file or to
-<PDK>/packages/ti/board/src/<BOARD>/include/board_cfg.h to apply for all
-applications. This is used because the default diagnostic loading method
-is through SD card, and the pinmux is done already. Adding this option
-only forces the diagnostic applications to do pinmuxing within the
-application itself (and not depend it being done).
-
-To run on CCS:
-
-#. Connect USB cable to the board's JTAG
-#. Connect the UART serial cable. For the IDK boards, the UART console
-   is the same as the usb JTAG connector, so no additional cable is
-   necessary.
-#. Plug in power cord to your board
-#. Press the power button on the board to turn the board on
-#. Setup and run CCSv6.1 (or higher). Follow the `Processor SDK RTOS
-   Getting Started
-   Guide <index_overview.html#processor-sdk-rtos-getting-started-guide>`__ on how
-   to setup your CCS to connect to the board
-#. Launch target configuration for the board
-#. Connect to the core that you built your application for. For example:
-   for idkAM572x armv7 projects, click on the Cortex A-15 MPU0 core and
-   press the connect button
-#. Load the program by pressing the load button and navigate the
-   explorer to the .out file that you want to load
-#. Press the Run button to run the program
-#. Check UART console to see if anything is printed out. \**If nothing
-   is printed out, pause the core and see where the program counter is
-   at. If it is at 0x3808c (or near it), try reloading the program and
-   running again.
-
-.. note:: Diagnostics are built for both DSP (C674x) and ARM (arm9) cores
-   on omapl13x platform.
-
-Running on a different ARM core
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The diagnostic baremetal applications are typically targeted for Core 0
-of an ARM corepac. It is possible to load and run it on one of the
-subcores in CCS. To do so, please consider the following:
-
-#. Enable Cache - setup typically only enables cache for the main ARM
-   core. You may have to explicitly enable the data and instruction
-   cache. See relevant cache functions under pdk/packages/ti/csl/arch.
-#. [For AM57x boards] Set OPP to high - SBL would set OPP to high for
-   Core 0, but may not do it for the subcores. You can do so by using
-   the GEL file. After connecting to the core, run the function under
-   Scripts -> AM572x PRCM CLOCK configuration ->
-   AM572x_PRCM_Clock_Config_OPPHIGH (similarly named for AM571x).
-
-Diagnostic Applications
------------------------------
-
-
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                      Name                       |    Description    | AM65xx | AM65xx | GP     | IDK           | IDK    | EVM | ICE | EVM    | SK     | BBB    | ICEv2  | EVM    | SK     | IDK    | EVM      | ICE     |
-|                                                 |                   | EVM    | IDK    | AM572x | AM572x/AM574x | AM571x | K2G | K2G | AM335x | AM335x | AM335x | AM335x | AM437x | AM437x | AM437x | OMAPL137 | AMIC110 |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+=================================================+===================+========+========+========+===============+========+=====+=====+========+========+========+========+========+========+========+==========+=========+
-|                                                 | Test for device   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    lcdTouchscreen_TEST                          | detection and     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | read the X, Y     |        |        |        |               |        |     |     |    x   |  x     |        |        |  x     |  x     |        |          |         |
-|                                                 | and Z axis        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | values to confirm |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | values within     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | range.            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Test for ADC      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    adc_TEST                                     | configuration for |        |        |        |               |        |     |     |    x   |  x     |        |        |    x   |  x     |        |          |         |
-|                                                 | Channel sequencing|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and One shot mode |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operation.        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Test for device   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    ambient_TEST                                 | detection on board|        |        |        |               |        |     |     |    x   |        |        |        |    x   |        |        |          |         |
-|                                                 | and working of    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the light sensor. |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes to GPIO in |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    buzzer_TEST                                  | connected to a    |        |        |        |               |        |     |     |    x   |        |        |        |    x   |        |        |          |         |
-|                                                 | buzzer. Requires  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | user to verify    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | sound             |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Probes the clock  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    clock_TEST                                   | generator on      |        |        |        |               |        |     |  x  |        |        |        |        |        |        |        |          |         |
-|                                                 | I2C bus           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Read voltage,     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    currentMonitor_TEST                          | current on I2C    |   x    |   x    |        |               |        |     |  x  |        |        |        |        |        |        |        |          |         |
-|                                                 | devices           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Read voltage,     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    currentMonitorStress_TEST                    | current on I2C    |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | devices. Test is  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | repeated for 100  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | cycles. Press 'b' |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to stop the test  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | before completing |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | test cycles.      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Does DCAN loopback|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    dcan_TEST                                    | writes and reads. |        |        |        |     x         |    x   |  x  |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Passes on         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | successful return.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Reads the EEPROM  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    eeprom_TEST                                  | and prints out the|    x   |    x   |    x   |     x         |    x   |  x  |  x  |    x   |    x   |    x   |     x  |    x   |    x   |    x   |          |    x    |
-|                                                 | board's ID        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | information.      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Passes on         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | successful I2C    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | reads. EEPROM will|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | need to be        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | programmed prior  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | in order for a    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | correct read.     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Sends packet o    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    emac_TEST                                    | PHY loopback t    |        |        |        |               |        |     |  x  |        |        |        |        |        |        |        |          |         |
-|                                                 | verify MAC        |   x    |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operations        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies EMAC     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    emacStress_TEST                              | Ethernet ports by |   x    |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | sending and       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | receiving 10240   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | packets.          |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes to and read|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    emmc_TEST                                    | from eMMC memory. |    x   |    x   |    x   |    x          |  x     |  x  |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Passes on reading |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | back the correct  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | value as the one  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | written           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes to and read|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    emmcStress_TEST                              | from eMMC memory. |    x   |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Test covers the   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | entire eMMC memory|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | The main          |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    app                                          | diagnostic        |    x   |    x   |    x   |     x         |    x   |  x  |  x  |    x   |    x   |    x   |     x  |    x   |    x   |    x   |          |    x    |
-|                                                 | application. This |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | is loaded by SBL  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and can load other|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | diagnostic        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | applications on   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the SD card.      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Sends and receive |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    gmac_TEST                                    | packets over      |        |        |        |    x          |    x   |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ethernet, both    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | internally and    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | externally. Passes|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | on receiving all  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | packets.          |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes to the GPIO|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    haptics_TEST                                 | pin connected to a|        |        |        |    x          |  x     |     |     |        |        |        |        |   x    |        |        |          |         |
-|                                                 | motor (haptics).  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Requires user to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verify that the   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | motor is active.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests HDMI        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    hdmi_TEST                                    | display output    |        |        |        |               |        |  x  |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Configures one    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    icssEmac_TEST                                | ICSS EMAC port    |        |        |        |     x         |  x     |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and tests         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | functionality via |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | packet loopback.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests LCD display |   x    |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    lcd_TEST                                     | output and touch  |        |        |        |               |        |  x  |     |        |        |        |        |        |        |        |          |         |
-|                                                 | input             |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Prompts the user  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    lcdTouchscreen_TEST                          | for touches on the|        |        |        |     x         |   x    |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | LCD touchscreen   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and report back   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | its location.     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Requires user to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | input 9           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | simultaneous      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | touches to        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verify pass.      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Cycles through    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    led_TEST                                     | GPIO LEDs on the  |    x   |    x   |    x   |     x         |   x    |  x  |  x  |    x   |    x   |   x    |   x    |    x   |    x   |    x   |          |    x    |
-|                                                 | board. Requires   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | user to verify    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the LEDs blink.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Cycles through    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    ledStress_TEST                               | GPIO LEDs on the  |    x   |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board. Requires   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | user to verify    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the LEDs blink.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Test is repeated  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for 100 cycles.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Press 'b' to stop |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the test before   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | completing test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | cycles.           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Cycles through the|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    ledIndustrial_TEST                           | I2C LEDs on the   |   x    |   x    |        |     x         |   x    |     |  x  |        |        |        |        |        |        |        |          |         |
-|                                                 | board. Requires   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | user to verify    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | LEDs blink.       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Cycles through the|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    ledIndustrialStress_TEST                     | I2C LEDs on the   |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board. Requires   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | user to verify    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | LEDs blink.       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Test is repeated  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for 100 cycles.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Press 'b' to stop |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the test before   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | completing test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | cycles.           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Attempts one      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mcspi_TEST                                   | write and read on |        |        |        |     x         |   x    |     |     |        |        |        |        |        |        |    x   |          |    x    |
-|                                                 | the MCSPI header. |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Requires user to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verify the value  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | being read back   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | is as expected.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes and reads  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mem_TEST                                     | to external (DDR) |   x    |   x    |   x    |     x         |    x   |  x  |  x  |    x   |   x    |   x    |   x    |    x   |    x   |    x   |          |    x    |
-|                                                 | memory of the     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board. Value      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | written/read is   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the address of    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the word. This is |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | done two times,   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for value and     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ~value            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | (complement), to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | test for all bits.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes and reads  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    memStress_TEST                               | to external (DDR) |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | memory of the     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board. Walking 1's|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and walking 0's   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | tests are executed|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | on the whole DDR  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | memory            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes to and     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mmcsd_TEST                                   | read from MMCSD   |   x    |   x    |   x    |     x         |    x   |     |     |    x   |   x    |   x    |   x    |    x   |    x   |    x   |          |         |
-|                                                 | memory. Passes on |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | reading back the  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | correct value as  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the one written   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes to and     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mmcsdStress_TEST                             | read from MMCSD   |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | memory. Passes on |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | reading back the  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | correct value as  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the one written.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Entire SD card    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | memory starting   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | from 1.5GB offset |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | is written/read   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests reading and |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    nand_TEST                                    | writing to NAND   |        |        |        |               |        |  x  |     |        |        |        |        |        |        |        |          |         |
-|                                                 | flash memory      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests reading and |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    norflash_TEST                                | writing to NOR    |   x    |   x    |        |               |        |  x  |     |        |        |        |        |        |        |        |          |         |
-|                                                 | flash memory      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests reading and |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    norflashStress_TEST                          | writing to NOR    |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | flash memory.     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Entire NOR flash  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | memory is accessed|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Light up the OLED |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    oled_TEST                                    | display to verify |        |        |        |               |        |     |  x  |        |        |        |        |        |        |        |          |         |
-|                                                 | functionality     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Writes and reads  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    pmic_TEST                                    | to the PMIC       |        |        |   x    |     x         |    x   |     |     |     x  |    x   |    x   |   x    |    x   |    x   |        |          |         |
-|                                                 | controller. This  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | is to verify      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ability to use    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | I2C to control    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | PMIC. Test passes |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | on successful read|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and write.        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests the Quad    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    qspi_TEST                                    | SPI by writing    |        |        |        |     x         |    x   |  x  |  x  |        |        |        |        |        |    x   |        |          |         |
-|                                                 | and reading back  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the value written |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to memory. Test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | passes on correct |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | data read back.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests the rotary  |        |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    rotarySwitch_TEST                            | switch at the     |        |        |        |               |        |     |  x  |        |        |        |        |        |        |        |          |         |
-|                                                 | 10 possible       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | positions         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Test for setting  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    rtc_TEST                                     | date and time to  |        |        |        |               |        |     |     |    x   |    x   |    x   |    x   |    x   |    x   |    x   |          |         |
-|                                                 | RTC registers and |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | running the clock |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests reading     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    temperature_TEST                             | back from         |   x    |   x    |   x    |               |        |  x  |     |    x   |        |        |        |    x   |        |        |          |         |
-|                                                 | temperature sensor|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | via I2C. Test     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | passes on         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | successful I2C    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | reads.            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests reading     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    temperatureStress_TEST                       | back from         |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | temperature sensor|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | via I2C. Test     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | passes on         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | successful I2C    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | reads.            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Test is repeated  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for 100 cycles.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Press 'b' to stop |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the test before   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | completing test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | cycles.           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests uart        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    uart2usb_TEST                                | messages over usb |        |        |        |               |        |  x  |     |        |        |        |        |        |        |        |          |         |
-|                                                 | port.             |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Data Path         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    uart_TEST                                    | continuity test   |   x    |   x    |   x    |    x          |    x   |  x  |  x  |    x   |    x   |    x   |    x   |    x   |     x  |    x   |          |         |
-|                                                 | for UART output.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Requires user to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verify that       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | outputs do appear |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | on console.       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies UART port|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    uartStress_TEST                              | with large block  |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | of data transfer. |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Sends 10MB of data|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | from the board to |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | serial console.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Teraterm script   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | loops the data    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | back to the board.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Data recieved on  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the board and     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verified.         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | RS485 to RS232    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | coverter is needed|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to run the test on|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | AM65xx platform.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Need to run this  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | test from CCS.    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | SD boot support is|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | not available.    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | On-board          |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mcasp_TEST                                   | audio codec       |        |        |        |               |        |  x  |     |        |        |        |        |        |        |        |    x     |         |
-|                                                 | functionality is  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | exercised by this |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | test. Audio       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | supplied at EVM   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | audio input port  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | will loopback to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | audio output port.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | This test is      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | intended to       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | demonstrate       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | baremetal         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | functionality of  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | mcasp, edma3 and  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | i2c CSL modules   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | without depending |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | on the LLD        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | libraries. No     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | console output is |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | supported by this |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | test.             |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Multi-channel     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mcaspAudioDC_TEST                            | audio daughter    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |    x     |         |
-|                                                 | card              |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | functionality is  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | exercised by      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | this test. Audio  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | supplied at audio |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | DC input ports    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | will loopback to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | audio DC output   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ports. This test  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | is intended to    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | demonstrate bare  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | metal             |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | functionality of  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | mcasp, edma3 and  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | spi CSL modules   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | without depending |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | on the LLD        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | libraries. No     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | console output is |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | supported by      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | this test.	      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Demonstrates the  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    pwm_TEST                                     | usage of PWM CSL  |        |        |   x    |               |        |  x  |     |    x   |        |        |        |        |        |    x   |          |         |
-|                                                 | FL APIs by        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | configuring the   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | PWM module to     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | generate a pulse  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | of 1KHz with      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | different         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | duty cycle - 25,  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | 50 and 75%.       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies the USB  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    usbDevice_TEST                               | device mode       |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operation of      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board under test. |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | USB modules       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operates at high  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | speed (2.0)       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Board is exposed  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | as USB MSC device |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to host PC during |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the test.         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies the USB  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    usbHost_TEST                                 | host mode         |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operation of      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | boardf under test.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | USB modules       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operates at high  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | speed (2.0)       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | File write/read   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and data          |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verification on   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the connected USB |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | device is done    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies the USB  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    usbHostStress_TEST                           | host mode         |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operation of      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | boardf under test.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | USB modules       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | operates at high  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | speed (2.0)       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | File write/read   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and data          |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verification on   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the connected USB |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | device is done    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Test is repeated  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for 100 cycles.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Press 'b' to stop |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the test before   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | completing test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | cycles.           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests the Octal   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    ospi_TEST                                    | SPI by writing    |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and reading back  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the value written |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to memory. Test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | passes on correct |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | data read back.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests the Octal   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    ospiStress_TEST                              | SPI by writing    |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and reading back  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the value written |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to memory. Test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | passes on correct |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | data read back.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Entire OSPI flash |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | memory is accessed|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Tests the PCIe    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    pcie_TEST                                    | interface in      |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | end point and     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | rootcomplex mode  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | using two boards. |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Data is sent from |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | one board to other|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and sent it back  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to the first board|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for verification. |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies boot     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    bootEeprom_TEST                              | EEPROM by writing |    x   |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | a block of data,  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | reading back      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | written data      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for correctness.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies boot     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    bootEepromStress_TEST                        | EEPROM read/write |    x   |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | covering entire   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | memory.           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Test for setting  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    extRtc_TEST                                  | date and time to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | external RTC and  |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | running the clock |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Test for setting  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    extRtcStress_TEST                            | date and time to  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | external RTC and  |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | running the clock.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Test is repeated  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for 100 cycles.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Press 'b' to stop |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the test before   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | completing test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | cycles.           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies ICSSG    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    icssgEmac_TEST                               | EMAC ports in     |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | loopback with one |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | port connected to |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | another port.     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | 10 packets are    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | sent and received |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies ICSSG    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    icssgEmacStress_TEST                         | EMAC ports in     |   x    |   x    |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | loopback with one |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | port connected to |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | another port.     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | 10240 packets are |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | sent and received |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | during the test.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Cycles through    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    icssgLed_TEST                                | LEDs on the IDK   |        |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | application       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board.            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Cycles through    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    icssgLedStress_TEST                          | LEDs on the IDK   |        |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | application       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board.            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Test is repeated  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | for 100 cycles.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Press 'b' to stop |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the test before   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | completing test   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | cycles.           |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies boot mode|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    bootSwitch_TEST                              | switch by         |    x   |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | configuring boot  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | strap pins as     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | GPIOs and reading |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the pin state with|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | boot switch set in|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | different patterns|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies push     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    button_TEST                                  | buttons on the    |    x   |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board. Test       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | prompts for       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | pressing a        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | specific button   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | which will be     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | detected by the   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | test.             |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies MCAN     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mcan_TEST                                    | ports on the      |        |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board with two    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ports connected   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | with each other.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Data is sent from |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | one port and      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | received on       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | another port. Both|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ports are         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | veirified for Tx  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and Rx            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies MCAN     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    mcanStress_TEST                              | ports on the      |        |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board with two    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ports connected   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | with each other.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | 10240 packets     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | are sent from     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | one port and      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | received on       |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | another port. Both|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | ports are         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | veirified for Tx  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | and Rx            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies PRU UART |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    rs485_TEST                                   | port on the       |        |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board.            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Supports board to |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board test and    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | single board test.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | RS485 to RS232    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | coverter is needed|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to run the test on|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | AM65xx platform   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies PRU UART |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    rs485Stress_TEST                             | port on the       |        |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board.            |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Sends 10MB of data|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | from the board to |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | serial console.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Teraterm script   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | loops the data    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | back to the board.|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Data recieved on  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the board and     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | verified.         |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | RS485 to RS232    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | coverter is needed|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | to run the test on|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | AM65xx platform.  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 |                   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Need to run this  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | test from CCS.    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | SD boot support is|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | not available.    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-|                                                 | Verifies basic    |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|    Power On Self Test                           | memory devices    |   x    |    x   |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | on the board and  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | displays the      |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | board ID details. |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Executed on boot  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | automatically     |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | before displaying |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | diag main menu.   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | Can be skipped by |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | entering 'b' in   |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | the serial console|        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | within 5 secs of  |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-|                                                 | diag boot.        |        |        |        |               |        |     |     |        |        |        |        |        |        |        |          |         |
-+-------------------------------------------------+-------------------+--------+--------+--------+---------------+--------+-----+-----+--------+--------+--------+--------+--------+--------+--------+----------+---------+
-
-| Some diagnostic applications expect additional jumpers or hardware
-  settings to complete. Refer to below section.
-
-Additional Jumper or Hardware Settings
-----------------------------------------
-
-Current Monitor
-^^^^^^^^^^^^^^^^
-
-For iceK2G, this test expects J16 and J17 to be connected with jumper
-shunts. This enables the current monitors to be used.
-
-GMAC
-^^^^^
-
-For idkAM572x, idkAM571x, idkAM574x and evmAM572x, this test expects
-loopback plugs to be used on both Ethernet ports. These loopback plugs
-will loopback the TX lines back to the RX lines. The Ethernet ports are
-the RJ-45 connectors labeled "Ethernet" on the board.
-
-ICSS EMAC
-^^^^^^^^^^
-
-For idkAM572x, idkAM574x and idkAM571x, this test expects loopback plug
-to be used on J6. These loopback plugs will loopback the TX lines back
-to the RX lines. For iceK2G, this test expects loopback plugs to be used
-on all four ICSS EMAC ports.
-
-LCD Touchscreen
-^^^^^^^^^^^^^^^^^^
-
-For idkAM572x, idkAM574x and idkAM571x, this test expects the LCD module
-to be connected. This requires the two ribbon cables (one for display,
-one for the capacitive-touch IC) to be connected.
-
-McSPI
-^^^^^^^
-
-For idkAM572x, idkAM574x and idkAM571x, this test expects pins to be
-connected to the Industrial I/O header. The Industrial I/O header, J37,
-has two columns in parallel, one of which is the McSPI input and the
-other being VDD. Thus, connecting any row with a jumper will yield a '1'
-read on that McSPI input. By connecting the first, second, third, and
-forth row with jumpers would yield 0x1, 0x2, 0x4, and 0x8 being read
-respectively.
-
-PWM
-^^^^^
-
-PWM output generated while running the diagnostic test can be verified
-at below pins.
-
-evmK2G - J12 pin 33
-
-evmAM572x - P17 pin 5
-
-idkAM437x - J16 pin 14
-
-evmAM335x - J5 pin 13
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics_Execution.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics_Execution.rst
deleted file mode 100644
index 11f0c6303..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics_Execution.rst
+++ /dev/null
@@ -1,7471 +0,0 @@
-
-Overview
-----------
-Detailed test procedure and additional HW setup needed for running the processor SDK board diagnostic tests are explained
-in the following sections. Logs shown for each test are for sample reference, actual logs may slightly vary from platform to platform.
-
-Two different modes of diagnostic tests are supported - Functional and Stress. Functional tests verify basic functionality of an
-interface to confirm the interface HW connectivity. Stress tests verify the functionality of an interface under stress conditions which will
-confirm the stability of the HW interface.
-
-Refer to `Diagnostic Applications <index_board.html#diagnostic-applications>`_ section for details of the platforms
-supported by each of the diagnostic tests described below.
-
-Application/Daughter cards required for running the test are not mentioned in the test setup assuming the tests are run with full HW kit.
-
-Functional Tests
-------------------
-This section describes the test procedure and setup for diagnostic functional tests.
-
-Accelerometer Test
-^^^^^^^^^^^^^^^^^^
-This test verifies the Accelerometer sensor on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘accelerometer_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for Accelerometer test is shown below
-
-::
-
-    *********************************************
-    *         Accelerometer Test                *
-    *********************************************
-
-    Test:                Expected Result:    Actual Result:    Result:
-    ----------------     ----------------    --------------    -------
-    0x32                 PASS
-    Self-Test(X Axis)    120-550             247               PASS
-    Self-Test(Y axis)    120-550             192               PASS
-    Self-Test(Z Axis)    140-750             349               PASS
-    Exiting
-
-|
-
-ADC Test
-^^^^^^^^^^^^^
-This test verifies ADC interface on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘adc_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for ADC test is shown below
-
-::
-
-    *********************************************
-    *                 ADC Test                  *
-    *********************************************
-
-    Voltage sensed on the AN0 line : 846mV
-    Voltage sensed on the AN1 line : 1156mv
-
-    Test PASSED!
-
-|
-
-Boot EEPROM Test
-^^^^^^^^^^^^^^^^^
-This test verifies Boot EEPROM memory. First and last page of the EEPROM are written with
-a test pattern and read back for data verification.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-Make sure pins 2-3 of J44 and J45 headers on AM65x CP board are shorted
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘bootEeprom_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for boot EEPROM test is shown below
-
-::
-
-    *********************************************
-    *              Boot EEPROM Test             *
-    *********************************************
-
-    Running Boot EEPROM test
-
-    Detecting the Boot EEPROM device...
-
-    Boot EEPROM device detection successful
-
-    Boot EEPROM boundary verification test...
-
-    Verifying the Boot EEPROM first page...
-
-    Verifying the Boot EEPROM last page...
-
-    Boot EEPROM boundary verification test successful
-
-    Boot EEPROM test Passed
-
-|
-
-Boot Switch Test
-^^^^^^^^^^^^^^^^^^
-Test verifies boot mode switch by configuring boot strap pins as GPIOs and reading the
-pin state with boot switch set in different patterns. Test prompts to set the boot switch
-with a specific pattern and waits for user confirmation of the setting.
-ON-OFF-ON... sequence indicated by the test starts from switch position 1.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘bootSwitch_TEST’
- - Setup the boot switch as instructed by the serial console log
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for boot switch test is shown below
-
-::
-
-    *********************************************
-    *             Boot Switch Test              *
-    *********************************************
-    Set All switches to OFF
-    Press Enter after setting the switches
-
-    Set the Switches to ON-OFF-ON-OFF...
-    Press Enter after setting the switches
-
-    Set the Switches to OFF-ON-OFF-ON...
-    Press Enter after setting the switches
-
-    Set All switches to ON
-    Press Enter after setting the switches
-
-    Test Passed
-|
-
-
-Button Test
-^^^^^^^^^^^^^^^^^
-Verifies push buttons on the board. Test prompts for pressing a specific button
-which should be detected by the test and displayed on the console.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘button_TEST’
- - Press the button as instructed by the test messages on the serial console.
- - Verify the test log on serial console. Make sure the button press is detected properly.
-
-.. note::
-   Button release detection is supported only on AM65xx platform.
-
-Test Log
-"""""""""""
-Sample log for push button test is shown below
-
-::
-
-    *********************************************
-    *                 Button Test               *
-    *********************************************
-
-    Running button test...
-    Button SW  5            WAIT      Waiting for button press Button Pressed
-    Button SW  5            WAIT      Waiting for button release Button released
-    Button SW  5            PASS
-    Button SW  6            WAIT      Waiting for button press Button Pressed
-    Button SW  6            WAIT      Waiting for button release Button released
-    Button SW  6            PASS
-    Test PASSED!
-
-|
-
-Buzzer Test
-^^^^^^^^^^^^
-This test verifies the Buzzer interface on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘buzzer_TEST’
- - Verify the Buzzer sound on the HW platform
- - Verify the test log on serial console
- - Press 'y' to confirm proper buzzer output or any other key to indicate failure
-
-Test Log
-"""""""""
-Sample log for buzzer test is shown below
-
-::
-
-    *********************************************
-    *               Buzzer Test                *
-    *********************************************
-
-    Testing Buzzer sound
-    Press 'y' to verify pass: y
-    Received: y
-
-    Test PASSED!
-|
-
-Clock Generator Test
-^^^^^^^^^^^^^^^^^^^^^^
-This test verifies clock generator interface on the HW platform under test.
-Need to probe and confirm the clocks during the test.
-
-Test Accessories
-"""""""""""""""""
-Oscilloscope to verify the clock outputs
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘clock_TEST’
- - Verify the test log on serial console
- - Verify the clock generator output clocks and confirm the result on the serial console
-
-Test Log
-"""""""""""
-Sample log for clock generator test is shown below
-
-::
-
-    **********************************
-           CLOCK GENERATOR Test
-    **********************************
-
-    Running Clock generator Detect Test
-
-    Clock generator Detection Successful!
-
-    Clock generator Detect Test Passed!
-
-
-    Running Clock generator probe Test
-
-    Probe the clock generator clock outputs
-    Are the signals generated properly ?
-    Press 'Y' to confirm, any other key to deny
-    y
-
-    Clock generator probe Test Passed!
-
-    Clock generator Test Passed!
-
-    Clock generator Tests Completed!!
-
-    -----------------X-----------------
-
-|
-
-Current Monitor Test
-^^^^^^^^^^^^^^^^^^^^^^
-Test reads the voltage and current values from different current monitor devices available on the board.
-All the current monitor devices available on the board are verified during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-For iceK2G, this test expects J16 and J17 to be connected with jumper
-shunts. This enables the current monitors to be used.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘currentMonitor_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for current monitor test is shown below
-
-::
-
-    **********************************************
-    *            Current Monitor Test            *
-    **********************************************
-
-    Running Current Monitor Test...
-
-    Verifying Device VDD_CORE at Address - 0x40
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 16777
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 9
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 800
-    Bus Voltage = 1000mV
-    Reading the Power register...
-    Power Register Value = 3
-    Power = 915mW
-    Reading the Current register...
-    Current Register Value = 74
-    Current = 11mA
-
-
-    Verifying Device VDD_MCU at Address - 0x41
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 16777
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 1534
-    Shunt Voltage = 3mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 797
-    Bus Voltage = 996mV
-    Reading the Power register...
-    Power Register Value = 501
-    Power = 19108mW
-    Reading the Current register...
-    Current Register Value = 12566
-    Current = 383mA
-
-
-    Verifying Device VDD_MPU at Address - 0x42
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 27962
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 6
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 802
-    Bus Voltage = 1002mV
-    Reading the Power register...
-    Power Register Value = 3
-    Power = 503mW
-    Reading the Current register...
-    Current Register Value = 82
-    Current = 7mA
-
-
-    Verifying Device SoC_DVDD3V3 at Address - 0x43
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 27962
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 15
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 2665
-    Bus Voltage = 3331mV
-    Reading the Power register...
-    Power Register Value = 28
-    Power = 2670mW
-    Reading the Current register...
-    Current Register Value = 205
-    Current = 18mA
-
-
-    Verifying Device SoC_DVDD1V8 at Address - 0x44
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 5592
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 108
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 1442
-    Bus Voltage = 1802mV
-    Reading the Power register...
-    Power Register Value = 21
-    Power = 3204mW
-    Reading the Current register...
-    Current Register Value = 295
-    Current = 26mA
-
-
-    Verifying Device SoC_AVDD1V8 at Address - 0x45
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 41943
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 1196
-    Shunt Voltage = 2mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 1442
-    Bus Voltage = 1802mV
-    Reading the Power register...
-    Power Register Value = 387
-    Power = 14760mW
-    Reading the Current register...
-    Current Register Value = 5358
-    Current = 65mA
-
-
-    Verifying Device SoC_VDDS_DDR at Address - 0x46
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 8388
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 256
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 956
-    Bus Voltage = 1195mV
-    Reading the Power register...
-    Power Register Value = 50
-    Power = 1335mW
-    Reading the Current register...
-    Current Register Value = 1049
-    Current = 63mA
-
-
-    Verifying Device VDD_DDR at Address - 0x47
-    Setting the configuration register...
-    Setting the calibration register...
-    Calibration Value = 8388
-    Reading the Shunt Voltage register...
-    Shunt Voltage Register Value = 38
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage Register Value = 957
-    Bus Voltage = 1196mV
-    Reading the Power register...
-    Power Register Value = 8
-    Power = 689mW
-    Reading the Current register...
-    Current Register Value = 156
-    Current = 9mA
-
-|
-
-DCAN Test
-^^^^^^^^^^
-This test verifies the DCAN ports on the HW platform under test.
-Test supports verifying the DCAN interface in internal and external loopback modes.
-
-Test Accessories
-"""""""""""""""""
-DCAN loopback cable (for evmK2G)
-
-Test Setup
-"""""""""""
-Connect two DCAN ports (P2 and P3) with DCAN loopback cable - only on evmK2G
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘dcan_TEST’
- - Follow the instructions on serial console to select the DCAN instance
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for DCAN test is shown below
-
-::
-
-    *********************************************
-    *                 DCAN Test                 *
-    *********************************************
-
-
-    **** DCAN APPLICATION TEST ****
-    Menu:
-    1. DCAN External Loopback test - DCAN1 Instance
-    2. DCAN Internal Loopback test - DCAN2 Instance
-    x. Exit
-    Select DCAN APPLICATION TEST : 1
-
-    DCAN External Loopback Test App: DCAN1 MSG OBJ 1 (TX) to DCAN1 MSG OBJ 2 (RX)
-
-    DCAN -- External Loopback Testmode test Passed!!
-
-
-    **** DCAN APPLICATION TEST ****
-    Menu:
-    1. DCAN External Loopback test - DCAN1 Instance
-    2. DCAN Internal Loopback test - DCAN2 Instance
-    x. Exit
-    Select DCAN APPLICATION TEST : 2
-
-    DCAN Internal Loopback Test App: DCAN2 MSG OBJ 1 (TX) to DCAN2 MSG OBJ 2 (RX)
-
-    DCAN -- Internal Loopback Testmode test Passed!!
-
-
-    **** DCAN APPLICATION TEST ****
-    Menu:
-    1. DCAN External Loopback test - DCAN1 Instance
-    2. DCAN Internal Loopback test - DCAN2 Instance
-    x. Exit
-    Select DCAN APPLICATION TEST : x
-
-    DCAN Application Test exiting...
-
-|
-
-EEPROM Test
-^^^^^^^^^^^^^^^^^^^^^
-This test reads and displays the board ID details from the EEPROM memory.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘eeprom_TEST’
- - Verify the board ID details displayed on the serial console
-
-Test Log
-"""""""""""
-Sample log for Board ID EEPROM test is shown below
-
-::
-
-    *********************************************
-    *              EEPROM Test                  *
-    *********************************************
-    header: aa5533ee
-    boardName: 66AK2GICE
-    version: 1.0A
-    serialNum: 09164P540001
-    Test PASSED!
-
-|
-
-.. note::
-   Board ID content shown in the above log changes from platform to platform.
-
-
-EMAC Test
-^^^^^^^^^^^
-This test verifies the EMAC Ethernet port on HW platform under test.
-Ethernet link and data transmit/receive are verified during this test.
-Ethernet interface is configured for 100mbps speed and 10 packets are sent/received during the test.
-Ethernet cable disconnect/reconnect and data transfer after cable connection is also verified during the test.
-
-Test Accessories
-""""""""""""""""""
-Ethernet loopback cables/plugs
-
-Test Setup
-"""""""""""
-Connect the Ethernet loopback cables to the EMAC Ethernet port (RJ-45) on the board.
-Check below table for the details of EMAC Ethernet ports used by the test on different platforms.
-
-+---------------+-----------------+
-| HW Platform   | Ethernet Port   |
-+===============+=================+
-| iceK2G        | J10             |
-+---------------+-----------------+
-| am65xx_evm    | J12 on CP board |
-+---------------+-----------------+
-| am65xx_idk    | J12 on CP board |
-+---------------+-----------------+
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘emac_TEST’
- - Follow the instructions on serial console for disconnecting and connecting the cable during the test.
- - Verify the test log on serial console
-
-
-Test Log
-"""""""""
-
-Sample log for Ethernet loopback test is shown below
-
-::
-
-    ************************************************
-    *             ETHERNET LOOPBACK Test           *
-    ************************************************
-
-    Reading Ethernet PHY Register Dump...
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x7949
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x8c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-    EMAC loopback test application initialization
-    main: emac_open success
-    Configuring Phy
-    Waiting for Link Status
-    Link is UP!!
-
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-    Sending Packet: 6
-    Sending Packet: 7
-    Sending Packet: 8
-    Sending Packet: 9
-    Sending Packet: 10
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-    Received Packet: 6
-    Received Packet: 7
-    Received Packet: 8
-    Received Packet: 9
-    Received Packet: 10
-
-    Packets sent: 10, Packets received: 10
-
-    Ethernet Loopback test passed
-    All tests completed
-    Please disconnect the loopback cable
-    Link is Down
-    Please reconnect the loopback cable
-    Link is UP
-
-    Reading Ethernet PHY Register Dump...
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1000
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4006
-    PHY Register 0x0009 - 0x1000
-    PHY Register 0x000a - 0x0000
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-    EMAC loopback test application initialization
-    main: emac_open success
-    Configuring Phy
-    Waiting for Link Status
-    Link is UP!!
-
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-    Sending Packet: 6
-    Sending Packet: 7
-    Sending Packet: 8
-    Sending Packet: 9
-    Sending Packet: 10
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-    Received Packet: 6
-    Received Packet: 7
-    Received Packet: 8
-    Received Packet: 9
-    Received Packet: 10
-
-    Packets sent: 10, Packets received: 10
-
-    Ethernet Loopback test passed
-    All tests completed
-
-|
-
-eMMC Test
-^^^^^^^^^^
-This test verifies eMMC memory interface on the HW platform under test.
-16KB of data is written and read during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘emmc_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for eMMC test is shown below
-
-::
-
-    *********************************************
-    *                 eMMC Test                 *
-    *********************************************
-
-    PASS: Read/Write Success for this pattern
-|
-
-External RTC Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies setting the time, date and running the clock for on-board RTC interface.
-RTC configuration is done through I2C interface. Time and date are read for 5 times for every 5secs
-during the test to demonstrate operation of the RTC clock.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘extRtc_TEST’
- - Verify the test log on serial console
- - Confirm the test result by pressing 'y' if RTC time/date changes properly or press any key for failure
-
-Test Log
-"""""""""""
-Sample log for external RTC test is shown below
-
-::
-
-    *********************************************
-    *                 RTC Test                  *
-    *********************************************
-
-    Setting Time...
-
-    Setting Date...
-
-    Reading Time...
-
-    Reading Date...
-
-
-    Displaying time: 11:59:53 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 11:59:57 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 12:0:2 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:7 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:12 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:17 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-    If the time and date increment, press 'y' to indicate pass or any other character to indicate failure
-    y
-
-    RTC test passed...
-
-|
-
-GMAC Test
-^^^^^^^^^^
-This test verifies the GMAC Ethernet ports of the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-Ethernet loopback cables/plugs
-
-Test Setup
-"""""""""""
-Connect the Ethernet loopback cables to the GMAC Ethernet port (RJ-45) on the board.
-Check below table for the details of GMAC Ethernet ports used by the test on different platforms.
-
-+---------------+-----------------+
-| HW Platform   | Ethernet Port   |
-+===============+=================+
-| idkAM571x     | J10 & J12       |
-+---------------+-----------------+
-| idkAM572x     | J10 & J12       |
-+---------------+-----------------+
-| idkAM574x     | J10 & J12       |
-+---------------+-----------------+
-| evmAM572x     | Both ports of P5|
-+---------------+-----------------+
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘gmac_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for GMAC test is shown below
-
-::
-
-    *********************************************
-    *                 GMAC Test                 *
-    *********************************************
-    Test                    Port    Link    Link-Speed              Status    Error
-    --------------------    ----    ----    --------------------    ------    ---------------------------
-    Phy Loopback               1    Up    Phy Loopback            PASS
-    10Mbps Full-Duplex         1    Up    10Mbps Full duplex      PASS
-    100Mbps Half-Duplex        1    Up    100Mbps Half duplex     PASS
-    100Mbps Full-Duplex        1    Up    100Mbps Full duplex     PASS
-    Phy Loopback               2    Up    Phy Loopback            PASS
-    10Mbps Full-Duplex         2    Up    10Mbps Full duplex      PASS
-    100Mbps Half-Duplex        2    Up    100Mbps Half duplex     PASS
-    100Mbps Full-Duplex        2    Up    100Mbps Full duplex     PASS
-    Exiting
-|
-
-Haptics Test
-^^^^^^^^^^^^
-This verifies haptics motor using vibrations on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘haptics_TEST’
- - Verify the test log on serial console
- - Check for the vibrations on the HW platform
-
-Test Log
-"""""""""
-Sample log for Haptics test is shown below
-
-::
-
-    *********************************************
-    *               Haptics Test                *
-    *********************************************
-
-    Testing Haptics (vibration)
-    Press 'y' to verify pass: y
-    Received: y
-
-    Test PASSED!
-|
-
-HDMI Test
-^^^^^^^^^^
-This test verifies HDMI display port on the HW platform under test.
-Color bar and different colors are displayed on HDMI monitor during the test.
-
-Test Accessories
-"""""""""""""""""
- - HDMI Display
- - HDMI cable
-
-Test Setup
-"""""""""""
-Connect the HDMI Display to the HDMI port on the board.
-Check below table for the details of HDMI ports used by the test on different platforms.
-
-+---------------+-----------------+
-| HW Platform   | HDMI Port       |
-+===============+=================+
-| evmK2G        | J36             |
-+---------------+-----------------+
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘hdmi_TEST’
- - Verify the color bar and different colors displayed on the HDMI Monitor.
- - Verify the test log on serial console and confirm test result.
-
-Test Log
-"""""""""
-Sample log for HDMI test is shown below
-
-::
-
-    ***********************
-           HDMI Test
-    ***********************
-    Running HDMI Device Detect Test
-    sil9022 HDMI Chip version = b0
-    HDMI Device Detect Test Passed
-
-    Displaying Colorbar... WAIT  Press 'y' if Colorbar is displayed, any other key for failure: y
-    Display Colorbar   - PASS
-    Displaying WHITE... WAIT  Press 'y' if WHITE is displayed, any other key for failure: y
-    Display WHITE - PASS
-    Displaying BLUE... WAIT  Press 'y' if BLUE is displayed, any other key for failure: y
-    Display BLUE - PASS
-    Displaying GREEN... WAIT  Press 'y' if GREEN is displayed, any other key for failure: y
-    Display GREEN - PASS
-    Displaying RED... WAIT  Press 'y' if RED is displayed, any other key for failure: y
-    Display RED - PASS
-    Displaying PURPLE... WAIT  Press 'y' if PURPLE is displayed, any other key for failure: y
-    Display PURPLE - PASS
-    Displaying PINK... WAIT  Press 'y' if PINK is displayed, any other key for failure: y
-    Display PINK - PASS
-    Displaying BLACK... WAIT  Press 'y' if BLACK is displayed, any other key for failure: y
-    Display BLACK - PASS
-    Displaying YELLOW... WAIT  Press 'y' if YELLOW is displayed, any other key for failure: y
-    Display YELLOW - PASS
-
-    HDMI Tests Completed!!
-
-    -----------------X-----------------
-
-|
-
-ICSS EMAC Test
-^^^^^^^^^^^^^^
-This test verifies ICSS EMAC Ethernet port on HW platform under test.
-PRU-ICSS Ethernet ports are configured for 100mbps speed and 5 packets are sent/received during the test.
-
-Test Accessories
-"""""""""""""""""
-Ethernet loopback cables/plugs
-
-Test Setup
-"""""""""""
-Connect the Ethernet loopback cables to the PRU-ICSS Ethernet ports (RJ-45) on the board.
-Check below table for the details of Ethernet ports used by the test on different platforms.
-
-+---------------+-----------------------+
-| HW Platform   | ICSS Ethernet Port    |
-+===============+=======================+
-| idkAM571x     | J6                    |
-+---------------+-----------------------+
-| idkAM572x     | J6                    |
-+---------------+-----------------------+
-| idkAM574x     | J6                    |
-+---------------+-----------------------+
-| iceK2G        | All ports of J8 & J9  |
-+---------------+-----------------------+
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘icssEmac_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for ICSS EMAC test is shown below
-
-::
-
-    PRU_ICSS0 Loopback Test
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS0 port 0 LINK IS UP
-    PRU_ICSS0 port 1 LINK IS UP
-
-    Sending Packets on Port 0
-    Sending Pkt 0
-    Received pkt: 0
-    Sending Pkt 1
-    Received pkt: 1
-    Sending Pkt 2
-    Received pkt: 2
-    Sending Pkt 3
-    Received pkt: 3
-    Sending Pkt 4
-    Received pkt: 4
-
-    Sending Packets on Port 1
-    Sending Pkt 0
-    Received pkt: 0
-    Sending Pkt 1
-    Received pkt: 1
-    Sending Pkt 2
-    Received pkt: 2
-    Sending Pkt 3
-    Received pkt: 3
-    Sending Pkt 4
-    Received pkt: 4
-    All tests have passed
-
-    PRU_ICSS0 Loopback Test Completed!
-
-
-    PRU_ICSS1 Loopback Test
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS1 port 0 LINK IS UP
-    PRU_ICSS1 port 1 LINK IS UP
-
-    Sending Packets on Port 0
-    Sending Pkt 0
-    Received pkt: 0
-    Sending Pkt 1
-    Received pkt: 1
-    Sending Pkt 2
-    Received pkt: 2
-    Sending Pkt 3
-    Received pkt: 3
-    Sending Pkt 4
-    Received pkt: 4
-
-    Sending Packets on Port 1
-    Sending Pkt 0
-    Received pkt: 0
-    Sending Pkt 1
-    Received pkt: 1
-    Sending Pkt 2
-    Received pkt: 2
-    Sending Pkt 3
-    Received pkt: 3
-    Sending Pkt 4
-    Received pkt: 4
-    All tests have passed
-
-    PRU1_ICSS0 Loopback Test Completed!
-
-|
-
-ICSSG EMAC Test
-^^^^^^^^^^^^^^^^^
-This port to port Ethernet test verifies the PRU-ICSS gigabit Ethernet interface on the board under test.
-During the test, Ethernet interface is configured for 1000mbps speed with one port of an ICSS instance
-is connected to another port. 5 packets are sent from one port and received by another port.
-Both the ports are verified for transmit and receive. All the ICSSG EMAC ports available on the board
-verified during the test.
-Note that ICSSG EMAC Test can also run on a am65xx_idk with Interposer daughter card. For details
-of Interposer daughter card, please refer to  `Device Drivers <index_device_drv.html#emac>`_
-
-Test Accessories
-""""""""""""""""""
-Ethernet cables
-
-Test Setup
-""""""""""""
-Connect Ethernet cable between two ports of an PRU-ICSS instance. Make such connections on all the PRU-ICSS ports available
-Check below table for the detials of ICSSG Ethernet ports used by the test on different platforms
-
-+---------------+-----------------------+
-| HW Platform   | ICSSG Ethernet Port   |
-+===============+=======================+
-| am65xx_evm    | Two ports on          |
-|               | J14 of CP board.      |
-+---------------+-----------------------+
-| am65xx_idk    | Two ports on          |
-|               | J14 of CP board.      |
-|               |                       |
-|               | Two ports on          |
-|               | J1 of IDK board.      |
-|               |                       |
-|               | Two ports on          |
-|               | J3 of IDK board.      |
-+---------------+-----------------------+
-| am65xx_idk    | Two ports on          |
-| with          | J14 of CP board.      |
-| Interposer    |                       |
-| card          |                       |
-|               | Two ports on          |
-|               | J3 of IDK board.      |
-+---------------+-----------------------+
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘icssgEmac_TEST’
- - Verify the test log on serial console
-
-
-Test Log
-""""""""""
-
-Sample log for ICSGG Ethernet test is shown below
-
-::
-
-    ***************************************
-    *           ICSSG EMAC TEST           *
-    ***************************************
-
-
-    Reading Ethernet PHY Register Dump...
-
-
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x7c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0003
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x3c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0003
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x3c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0003
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x7c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0003
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x7c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0003
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x3c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0003
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-    port 0:  FW is ready
-    Port 0:  FlowId 2
-    Port 0:  Config FW Complete
-    port 1:  FW is ready
-    Port 1:  FlowId 3
-    Port 1:  Config FW Complete
-    port 2:  FW is ready
-    Port 2:  FlowId 10
-    Port 2:  Config FW Complete
-    port 3:  FW is ready
-    Port 3:  FlowId 11
-    Port 3:  Config FW Complete
-    port 4:  FW is ready
-    Port 4:  FlowId 18
-    Port 4:  Config FW Complete
-    port 5:  FW is ready
-    Port 5:  FlowId 19
-    Port 5:  Config FW Complete
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 0 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 1 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 2 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 3 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 4 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 5 LINK IS UP!
-
-
-    Sending Packets on Port - 0
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-
-    Receiving Packets on Port - 1
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-
-    Packets Sent: 5, Packets Received: 5
-    Port 0 Send to Port 1 Receive Test Passed!
-
-
-    Sending Packets on Port - 1
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-
-    Receiving Packets on Port - 0
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-
-    Packets Sent: 5, Packets Received: 5
-    Port 1 Send to Port 0 Receive Test Passed!
-
-
-    Sending Packets on Port - 2
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-
-    Receiving Packets on Port - 3
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-
-    Packets Sent: 5, Packets Received: 5
-    Port 2 Send to Port 3 Receive Test Passed!
-
-
-    Sending Packets on Port - 3
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-
-    Receiving Packets on Port - 2
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-
-    Packets Sent: 5, Packets Received: 5
-    Port 3 Send to Port 2 Receive Test Passed!
-
-
-    Sending Packets on Port - 4
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-
-    Receiving Packets on Port - 5
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-
-    Packets Sent: 5, Packets Received: 5
-    Port 4 Send to Port 5 Receive Test Passed!
-
-
-    Sending Packets on Port - 5
-    Sending Packet: 1
-    Sending Packet: 2
-    Sending Packet: 3
-    Sending Packet: 4
-    Sending Packet: 5
-
-    Receiving Packets on Port - 4
-    Received Packet: 1
-    Received Packet: 2
-    Received Packet: 3
-    Received Packet: 4
-    Received Packet: 5
-
-    Packets Sent: 5, Packets Received: 5
-    Port 5 Send to Port 4 Receive Test Passed!
-
-
-    ICSSG Ethernet Port to Port Test Passed!
-    All Tests Completed
-
-|
-
-LCD Test
-^^^^^^^^^^
-This test verifies LCD display on the HW platform under test.
-Displaying color bar, LCD backlight control and touch verification is done during the test.
-
-Test Accessories
-"""""""""""""""""
-LCD Display
-
-Test Setup
-"""""""""""
-Connect the LCD Display to the HW platform under test.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘lcd_TEST’
- - Verify the color bar displayed on the LCD display.
- - Verify that LCD backlight is getting changed during backlight control test
- - Provide touch inputs during the touch interface test and confirm that positions are detected properly
- - Verify the test log on serial console
-
-.. note::
-   Touch interface test is not supported on all the platforms.
-   Refer to LCD Touchscreen Test for touch interface test on other platforms.
-
-Test Log
-"""""""""
-Sample log for LCD test is shown below
-
-::
-
-    *********************************************
-    *              Display Test                 *
-    *********************************************
-
-    LCD Board detect successfully
-
-    Running LCD Display Test...
-    DSS application started...
-    LCD configured successfully
-    Overlay configuration done
-    Video Port configuration done
-    Display the colour bar with maximum brightness
-
-    LCD Display Test Successfully
-
-    Running LCD Backlight Test
-
-    Changing Backlight... WAIT, Check the LCD panel
-
-    Increasing the brightness by varying the
-    duty cycle percentage form 0 to 100...
-
-
-    Decreasing the brightness by varying the
-    duty cycle percentage form 100 to 0...
-      Press 'y' if Brightness is Increasing & Decreasing, Any other key for failure: y
-    Change Backlight - PASS
-
-    Running LCD Touch Detect Test
-
-    Running the LCD touch detect test...
-
-    Reading the touch device details
-    Reading the product ID...
-    The prod Id read is - 928
-    Reading the firmware version...
-    The firmware version read is - `ABC
-    Clearing the buffer status register...
-
-
-    Waiting for user to provide 20 single point touches...
-    (x - 371, y - 497)
-    (x - 672, y - 284)
-    (x - 371, y - 497)
-    (x - 785, y - 620)
-    (x - 819, y - 334)
-    (x - 857, y - 449)
-    (x - 387, y - 495)
-    (x - 679, y - 314)
-    (x - 792, y - 644)
-    (x - 805, y - 428)
-    (x - 821, y - 379)
-    (x - 909, y - 570)
-    (x - 909, y - 570)
-    (x - 794, y - 697)
-    (x - 807, y - 718)
-    (x - 824, y - 747)
-    (x - 952, y - 648)
-    (x - 829, y - 753)
-    (x - 839, y - 754)
-    (x - 890, y - 442)
-    LCD touch detect test passed!
-
-|
-
-LCD Touchscreen Test
-^^^^^^^^^^^^^^^^^^^^^
-This test verifies the LCD Touchscreen on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-LCD Display
-
-Test Setup
-"""""""""""
-Connect the LCD Display to the HW platform under test.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘lcdTouchscreen_TEST’
- - Provide multiple touch points to verify multi-touch input detection
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for LCD Touchscreen test is shown below
-
-::
-
-    *********************************************
-    *             Touchscreen Test              *
-    *********************************************
-    Input 9 touches to exit test
-    Touch   t1              t2              t3              t4              t5              t6              t7              t8              t9
-    1        343, 389       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    2        343, 389       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    3        343, 389       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    4        343, 389       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    5        343, 389       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    6        343, 389       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    7        426, 637       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    8        426, 637       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    9        426, 637       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-    9        426, 637       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095       4095,4095
-
-|
-
-ICSS LED Test
-^^^^^^^^^^^^^^
-This test verifies LEDs connected to PRU-ICSS ports.
-All the LEDs are turned ON and OFF for 3 times during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘icssgLed_TEST’
- - Confirm that all the PRU-ICSS LEDs on the board are toggling during the test
- - Verify the test log on serial console
- - Confirm the test result by pressing 'y' in case of success and any other key for failure
-
-Test Log
-"""""""""""
-Sample log for ICSS LED test is shown below
-
-::
-
-    *********************************************
-    *              ICSS LED Test                *
-    *********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: y
-    Received: y
-
-    Test PASSED!
-
-|
-
-Industrial LED Test
-^^^^^^^^^^^^^^^^^^^^
-This test verifies industrial LEDs connected to I2C interface on the HW platform under test.
-All the LEDs are turned ON and OFF for 3 times during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘ledIndustrial_TEST’
- - Confirm that all the industrial LEDs on the board are toggling during the test
- - Verify the test log on serial console
- - Confirm the test result by pressing 'y' in case of success and any other key for failure
-
-Test Log
-"""""""""""
-Sample log for industrial LED test is shown below
-
-::
-
-    *********************************************
-    *            Industrial LED Test            *
-    *********************************************
-
-    Running Industrial LED test...
-    Verifying LED's connected to I2C IO Expander target device...
-
-    Testing Industrial LEDs
-    Cycling Ethernet LEDs for 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: y
-    Received: y
-
-    Testing Industrial LEDs on AM65x IDK Board
-    Cycling Ethernet LEDs for 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: y
-    Received: y
-
-    Industrial LED test Passed
-
-|
-
-LED Test
-^^^^^^^^^^^
-This test verifies general purpose user LEDs on the HW platform under test.
-All the LEDs are turned ON and OFF for 3 times during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘led_TEST’
- - Confirm that all the general purpose user LEDs on the board are toggling during the test
- - Verify the test log on serial console
- - Confirm the test result by pressing 'y' in case of success or any other key for failure
-
-Test Log
-"""""""""""
-Sample log for LED test is shown below
-
-::
-
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: y
-    Received: y
-
-    Test PASSED!
-
-|
-
-Light Sensor Test
-^^^^^^^^^^^^^^^^^^
-This test verifies the Ambient Light Sensor on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘ambient_light_sensor_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for Light Sensor test is shown below
-
-::
-
-    *********************************************
-    *         Ambient Light Test                *
-    *********************************************
-
-    Test:                Expected Result:    Actual Result:    Result:
-    ----------------     ----------------    --------------    -------
-    PowerUp/Read         0x03                PASS
-    Read ADC 0           >=0x80              0x95              PASS
-    Read ADC 1           >=0x80              0xAC              PASS
-    PowerDown            0x00                0x0               PASS
-    Read ADC 0           0x00                0x00              PASS
-    Read ADC 1           0x00                0x00              PASS
-
-|
-
-MCAN Test
-^^^^^^^^^^
-Verifies MCAN ports on the HW platform with two MCAN ports connected with each other.
-Data is sent from one port and received on another port. Both the ports are verified for Tx and Rx.
-
-Test Accessories
-"""""""""""""""""
-MCAN port to port loopback cable
-
-Test Setup
-"""""""""""
-Connect two MCAN ports on the board to each other with MCAN cable.
-Check below table for the details of MCAN ports used by the test on different platforms.
-
-+---------------+-----------------+
-| HW Platform   | MCAN Ports      |
-+===============+=================+
-| am65xx_idk    | Two ports on P1 |
-|               | connector of    |
-|               | IDK board       |
-+---------------+-----------------+
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘mcan_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for MCAN test is shown below
-
-::
-
-    ***********************************************
-    *                MCAN Test                    *
-    ***********************************************
-    MCANSS Revision ID:
-    scheme:0x1
-    Business Unit:0x2
-    Module ID:0x8e0
-    RTL Revision:0x5
-    Major Revision:0x1
-    Custom Revision:0x0
-    Minor Revision:0x1
-    CAN-FD operation is enabled through E-Fuse.
-    Endianess Value:0x87654321
-    Successfully configured MCAN0
-    MCANSS Revision ID:
-    scheme:0x1
-    Business Unit:0x2
-    Module ID:0x8e0
-    RTL Revision:0x5
-    Major Revision:0x1
-    Custom Revision:0x0
-    Minor Revision:0x1
-    CAN-FD operation is enabled through E-Fuse.
-    Endianess Value:0x87654321
-    Successfully configured MCAN1
-
-
-    Transmitting Data on MCAN Port0 and Receiving on MCAN port 1
-
-    Sending Packet - 1
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x30
-
-    Message DataByte2:0xb9
-
-    Message DataByte3:0xd6
-
-    Message DataByte4:0xfb
-
-    Message DataByte5:0x4b
-
-    Message DataByte6:0x87
-
-    Message DataByte7:0x27
-
-    Message DataByte8:0x97
-
-    Message DataByte9:0x58
-
-    Message DataByte10:0x0
-
-    Message DataByte11:0xc0
-
-    Message DataByte12:0xd4
-
-    Message DataByte13:0xe
-
-    Message DataByte14:0x3
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x100008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x30
-
-    Message DataByte2:0xb9
-
-    Message DataByte3:0xd6
-
-    Message DataByte4:0xfb
-
-    Message DataByte5:0x4b
-
-    Message DataByte6:0x87
-
-    Message DataByte7:0x27
-
-    Message DataByte8:0x97
-
-    Message DataByte9:0x58
-
-    Message DataByte10:0x0
-
-    Message DataByte11:0xc0
-
-    Message DataByte12:0xd4
-
-    Message DataByte13:0xe
-
-    Message DataByte14:0x3
-
-    Received Packet - 1
-
-
-    Sending Packet - 2
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xcb
-
-    Message DataByte2:0x62
-
-    Message DataByte3:0xc5
-
-    Message DataByte4:0xf2
-
-    Message DataByte5:0xf0
-
-    Message DataByte6:0x42
-
-    Message DataByte7:0xd0
-
-    Message DataByte8:0x5e
-
-    Message DataByte9:0x8
-
-    Message DataByte10:0xf0
-
-    Message DataByte11:0x26
-
-    Message DataByte12:0x97
-
-    Message DataByte13:0xb
-
-    Message DataByte14:0x26
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xcb
-
-    Message DataByte2:0x62
-
-    Message DataByte3:0xc5
-
-    Message DataByte4:0xf2
-
-    Message DataByte5:0xf0
-
-    Message DataByte6:0x42
-
-    Message DataByte7:0xd0
-
-    Message DataByte8:0x5e
-
-    Message DataByte9:0x8
-
-    Message DataByte10:0xf0
-
-    Message DataByte11:0x26
-
-    Message DataByte12:0x97
-
-    Message DataByte13:0xb
-
-    Message DataByte14:0x26
-
-    Received Packet - 2
-
-
-    Sending Packet - 3
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xe4
-
-    Message DataByte2:0xe6
-
-    Message DataByte3:0x81
-
-    Message DataByte4:0x1b
-
-    Message DataByte5:0x8a
-
-    Message DataByte6:0x71
-
-    Message DataByte7:0x39
-
-    Message DataByte8:0x78
-
-    Message DataByte9:0x7a
-
-    Message DataByte10:0xa7
-
-    Message DataByte11:0x22
-
-    Message DataByte12:0xdb
-
-    Message DataByte13:0x19
-
-    Message DataByte14:0x62
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xe4
-
-    Message DataByte2:0xe6
-
-    Message DataByte3:0x81
-
-    Message DataByte4:0x1b
-
-    Message DataByte5:0x8a
-
-    Message DataByte6:0x71
-
-    Message DataByte7:0x39
-
-    Message DataByte8:0x78
-
-    Message DataByte9:0x7a
-
-    Message DataByte10:0xa7
-
-    Message DataByte11:0x22
-
-    Message DataByte12:0xdb
-
-    Message DataByte13:0x19
-
-    Message DataByte14:0x62
-
-    Received Packet - 3
-
-
-    Sending Packet - 4
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x18
-
-    Message DataByte2:0x13
-
-    Message DataByte3:0x56
-
-    Message DataByte4:0x19
-
-    Message DataByte5:0x54
-
-    Message DataByte6:0x55
-
-    Message DataByte7:0xc6
-
-    Message DataByte8:0x40
-
-    Message DataByte9:0x45
-
-    Message DataByte10:0xa0
-
-    Message DataByte11:0x5a
-
-    Message DataByte12:0x4e
-
-    Message DataByte13:0x51
-
-    Message DataByte14:0xdb
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x18
-
-    Message DataByte2:0x13
-
-    Message DataByte3:0x56
-
-    Message DataByte4:0x19
-
-    Message DataByte5:0x54
-
-    Message DataByte6:0x55
-
-    Message DataByte7:0xc6
-
-    Message DataByte8:0x40
-
-    Message DataByte9:0x45
-
-    Message DataByte10:0xa0
-
-    Message DataByte11:0x5a
-
-    Message DataByte12:0x4e
-
-    Message DataByte13:0x51
-
-    Message DataByte14:0xdb
-
-    Received Packet - 4
-
-
-    Sending Packet - 5
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xf0
-
-    Message DataByte2:0x79
-
-    Message DataByte3:0x8a
-
-    Message DataByte4:0xaa
-
-    Message DataByte5:0x8b
-
-    Message DataByte6:0xe3
-
-    Message DataByte7:0x8f
-
-    Message DataByte8:0x5c
-
-    Message DataByte9:0xf6
-
-    Message DataByte10:0x1c
-
-    Message DataByte11:0xa0
-
-    Message DataByte12:0x41
-
-    Message DataByte13:0x4c
-
-    Message DataByte14:0xeb
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xf0
-
-    Message DataByte2:0x79
-
-    Message DataByte3:0x8a
-
-    Message DataByte4:0xaa
-
-    Message DataByte5:0x8b
-
-    Message DataByte6:0xe3
-
-    Message DataByte7:0x8f
-
-    Message DataByte8:0x5c
-
-    Message DataByte9:0xf6
-
-    Message DataByte10:0x1c
-
-    Message DataByte11:0xa0
-
-    Message DataByte12:0x41
-
-    Message DataByte13:0x4c
-
-    Message DataByte14:0xeb
-
-    Received Packet - 5
-
-
-
-    Transmitting Data on MCAN Port1 and Receiving on MCAN port 0
-
-    Sending Packet - 1
-
-    Message successfully transferred with payload Bytes:0xf
-    Receiving data on port0
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x1f
-
-    Message DataByte2:0x44
-
-    Message DataByte3:0x40
-
-    Message DataByte4:0x68
-
-    Message DataByte5:0x7a
-
-    Message DataByte6:0x5d
-
-    Message DataByte7:0xf5
-
-    Message DataByte8:0x3e
-
-    Message DataByte9:0xa5
-
-    Message DataByte10:0xb7
-
-    Message DataByte11:0xe3
-
-    Message DataByte12:0x36
-
-    Message DataByte13:0x3a
-
-    Message DataByte14:0x76
-
-    Received Packet - 1
-
-
-    Sending Packet - 2
-
-    Message successfully transferred with payload Bytes:0xf
-    Receiving data on port0
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xb0
-
-    Message DataByte2:0xbd
-
-    Message DataByte3:0x67
-
-    Message DataByte4:0x34
-
-    Message DataByte5:0x8c
-
-    Message DataByte6:0x9
-
-    Message DataByte7:0x6
-
-    Message DataByte8:0xab
-
-    Message DataByte9:0x4c
-
-    Message DataByte10:0x2b
-
-    Message DataByte11:0x13
-
-    Message DataByte12:0x4a
-
-    Message DataByte13:0xe1
-
-    Message DataByte14:0x7d
-
-    Received Packet - 2
-
-
-    Sending Packet - 3
-
-    Message successfully transferred with payload Bytes:0xf
-    Receiving data on port0
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xde
-
-    Message DataByte2:0x32
-
-    Message DataByte3:0xf2
-
-    Message DataByte4:0x26
-
-    Message DataByte5:0xb9
-
-    Message DataByte6:0x8e
-
-    Message DataByte7:0x4e
-
-    Message DataByte8:0x65
-
-    Message DataByte9:0x8d
-
-    Message DataByte10:0xd5
-
-    Message DataByte11:0xda
-
-    Message DataByte12:0xee
-
-    Message DataByte13:0x73
-
-    Message DataByte14:0x7e
-
-    Received Packet - 3
-
-
-    Sending Packet - 4
-
-    Message successfully transferred with payload Bytes:0xf
-    Receiving data on port0
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xe7
-
-    Message DataByte2:0x13
-
-    Message DataByte3:0xa0
-
-    Message DataByte4:0x99
-
-    Message DataByte5:0xe
-
-    Message DataByte6:0x63
-
-    Message DataByte7:0x95
-
-    Message DataByte8:0x3f
-
-    Message DataByte9:0x27
-
-    Message DataByte10:0xcf
-
-    Message DataByte11:0xb2
-
-    Message DataByte12:0xb0
-
-    Message DataByte13:0xc5
-
-    Message DataByte14:0xef
-
-    Received Packet - 4
-
-
-    Sending Packet - 5
-
-    Message successfully transferred with payload Bytes:0xf
-    Receiving data on port0
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xb1
-
-    Message DataByte2:0x1c
-
-    Message DataByte3:0xe5
-
-    Message DataByte4:0xef
-
-    Message DataByte5:0xaa
-
-    Message DataByte6:0x40
-
-    Message DataByte7:0x77
-
-    Message DataByte8:0xac
-
-    Message DataByte9:0x70
-
-    Message DataByte10:0x77
-
-    Message DataByte11:0x3
-
-    Message DataByte12:0xef
-
-    Message DataByte13:0xc5
-
-    Message DataByte14:0x70
-
-    Received Packet - 5
-
-
-     MCAN diagnostic test completed.
-
-|
-
-McASP Audio Test
-^^^^^^^^^^^^^^^^^
-Verifies McASP audio interface on the board.
-Audio samples are received through codec input and sent back to codec audio output during the test.
-Codec control channel is verified through I2C interface and audio channel is verified through McASP interface.
-
-Test Accessories
-"""""""""""""""""
- - Audio LINE IN cable.
- - Headphone.
-
-Test Setup
-"""""""""""
-Connect audio LINE IN cable to audio input port and headphone to audio output port on the HW platform under test.
-Check below table for the details of audio ports used by the test on different platforms.
-
-+---------------+-----------------+-----------------+
-| HW Platform   | Audio IN Port   | Audio OUT Port  |
-+===============+=================+=================+
-| evmK2G        | J32             | J33             |
-+---------------+-----------------+-----------------+
-| evmOMAPL137   | P3              | P5              |
-+---------------+-----------------+-----------------+
-
-Test Execution
-"""""""""""""""
- - Start playing audio at the audio source driving the audio input connected to input port
- - Select the menu option to run ‘mcasp_TEST’
- - Verify that the audio being played at input is looped back to audio headset/speaker connected to output port
- - Verify that the audio plays without any noise on left and right channels.
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for McASP audio test is shown below
-
-::
-
-    *********************************************
-    *         AUDIO Loopback Test               *
-    *********************************************
-
-    Playing Audio on left channel
-
-    Playing Audio on right channel
-
-    Playing Audio on both left and right
-
-    Audio Loopback test completed
-
-|
-
-McASP AudioDC Test
-^^^^^^^^^^^^^^^^^^
-This test verifies the audio interface on the multi-channel audio daughter card for the OMAPL137 EVM.
-
-Test Accessories
-"""""""""""""""""
- - 4 Audio LINE IN cables
- - 4 Headphones
-
-Test Setup
-"""""""""""
- - Connect LINE IN cables to all the audio input ports (J5 to J8) on the audio daughter card.
- - Connect headsets to all the audio output ports (J9 to J12) on the audio daughter card.
-
-Test Execution
-""""""""""""""""
- - Start playing audio at the audio source driving the audio input connected to input ports
- - Load and execute the McASP AudioDC test using CCS
- - Listen to the Audio played back through the Headphones
- - Verify that the audio plays without any noise on left and right channels.
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for McASP AudioDC test is shown below
-
-::
-
-    *******************************************
-    *         Audio DC Loopback Test          *
-    *******************************************
-
-    Starting Audio Loopback...
-    Check the Headset/Speaker Audio Output
-
-    Audio DC Loopback Test Completed!
-    Audio DC Loopback Test Passed!!
-
-|
-
-McSPI Test
-^^^^^^^^^^^^
-This test verifies reading the industrial input data through McSPI interface.
-Need to provide input to industrial input channels while running the test.
-
-Except for iceAMIC110, this test expects pins to be
-connected to the Industrial I/O header. The Industrial I/O header,
-has two columns in parallel, one of which is the McSPI input and the
-other being VDD. Thus, connecting any row with a jumper will yield a '1'
-read on that McSPI input. By connecting the first, second, third, and
-forth row with jumpers would yield 0x1, 0x2, 0x4, and 0x8 being read
-respectively.
-
-Test Accessories
-"""""""""""""""""
-Wires to short pins on industrial I/O header.
-
-Test Setup
-"""""""""""
-Short the rows on industrial I/O header.
-Check below table for the details of industrial IO header used by the test on different platforms.
-
-+---------------+-----------------------+
-| HW Platform   | Industrial I/O Header |
-+===============+=======================+
-| idkAM571x     | J37                   |
-+---------------+-----------------------+
-| idkAM572x     | J37                   |
-+---------------+-----------------------+
-| idkAM574x     | J37                   |
-+---------------+-----------------------+
-| idkAM437x     | J1                    |
-+---------------+-----------------------+
-
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘mcspi_TEST’
- - Verify the test log on serial console
- - Confirm the test result by pressing 'y' in case the input provided to industrial I/O header is read properly,
-   else press any other key to indicate failure.
-
-Test Log
-"""""""""""
-Sample log for McSPI test is shown below
-
-::
-
-    *********************************************
-    *                MCSPI Test                 *
-    *********************************************
-
-    Testing MCSPI...
-    Data transferred: aa
-    Data received: 20
-    Press 'y' to verify pass, 'r' to read again,
-    or any other character to indicate failure: y
-    User input:  y
-
-    Test PASSED!
-|
-
-Memory (DDR) Test
-^^^^^^^^^^^^^^^^^^
-This test verifies the DDR memory of the HW platform under test.
-Address bus test is performed with a test pattern and its compliment during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘mem_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-
-Sample DDR test log is shown below
-
-::
-
-    *********************************************
-    *              DDR Memory Test              *
-    *********************************************
-
-    Testing writing and reading memory
-    board_external_memory_test: Start address (0x80000000),            end address (0xffffffff)
-    First test started
-    Writing to test area...
-            Write up to 0x80000000 done
-            Write up to 0x90000000 done
-            Write up to 0xa0000000 done
-            Write up to 0xb0000000 done
-            Write up to 0xc0000000 done
-            Write up to 0xd0000000 done
-            Write up to 0xe0000000 done
-            Write up to 0xf0000000 done
-    Write finished!
-    Checking values...
-            Read up to 0x80000000 okay
-            Read up to 0x90000000 okay
-            Read up to 0xa0000000 okay
-            Read up to 0xb0000000 okay
-            Read up to 0xc0000000 okay
-            Read up to 0xd0000000 okay
-            Read up to 0xe0000000 okay
-            Read up to 0xf0000000 okay
-    Second test started
-    Writing complementary values to test area...
-            Write up to 0x80000000 done
-            Write up to 0x90000000 done
-            Write up to 0xa0000000 done
-            Write up to 0xb0000000 done
-            Write up to 0xc0000000 done
-            Write up to 0xd0000000 done
-            Write up to 0xe0000000 done
-            Write up to 0xf0000000 done
-    Write finished!
-    Checking values...
-            Read up to 0x80000000 okay
-            Read up to 0x90000000 okay
-            Read up to 0xa0000000 okay
-            Read up to 0xb0000000 okay
-            Read up to 0xc0000000 okay
-            Read up to 0xd0000000 okay
-            Read up to 0xe0000000 okay
-            Read up to 0xf0000000 okay
-    Board memory test passed!
-
-|
-
-MMCSD Test
-^^^^^^^^^^^^^
-This test verifies SD card interface on the platform under test.
-16KB of data is written and read during the test.
-
-Test Accessories
-"""""""""""""""""
-SD card.
-
-Test Setup
-"""""""""""
-Insert the SD card into MMCSD slot of the board.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘mmcsd_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for SD card test is shown below
-
-::
-
-    *********************************************
-    *                MMCSD Test                 *
-    *********************************************
-
-    PASS: Read/Write Success for this pattern
-
-|
-
-Nand Test
-^^^^^^^^^
-This test verifies NAND flash memory on the HW platform under test.
-Reading the NAND flash information and NAND page write/read with different test patterns
-is done during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘nand_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for NAND test is shown below
-
-::
-
-    ***********************
-           NAND Test
-    ***********************
-
-    Running NAND Flash Chip Detect Test
-    Device Id - 0x0
-    Manufacturer Id - 0x0
-    Device Width - 16
-    Block Count - 2048
-    Page Count - 64
-    Page Size - 2048
-    Spare Area Size - 64
-    Column Address - 1024
-
-    NAND Flash Chip Detect Test Passed
-
-    Running NAND Flash Block Erase Test
-    NAND Flash Test: Erase Data Verification Passed
-
-    NAND Flash Block Erase Test Passed
-
-    Running NAND Flash Memory Access Test - Test Pattern 1
-    NAND Flash Test: Data Verification Passed
-
-    Running NAND Flash Memory Access Test - Test Pattern 2
-    NAND Flash Test: Data Verification Passed
-
-    NAND Flash Memory Access Test Passed
-
-    NAND Flash Test Passed!
-
-    NAND Flash Tests Completed!!
-
-    -----------------X-----------------
-
-|
-
-NOR Flash Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies the NOR flash memory connected to SPI interface.
-One page of flash is written and read back for data verification during the test.
-
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘norflash_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for NOR flash test is shown below
-
-::
-
-    *********************************************
-    *            SPI FLASH Test                 *
-    *********************************************
-    Reading Flash Device ID...
-    Device ID 0 - 0x20
-    Device ID 1 - 0xba
-    Device ID 2 - 0x18
-    Flash Device ID Match!
-
-    Flash Device ID Read Passed!
-
-    Verifying Sector - 0
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    SPI NOR Flash Test Passed
-
-|
-
-OLED Display Test
-^^^^^^^^^^^^^^^^^
-This test verifies the OLED display on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘oled_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for OLED Display test is shown below
-
-::
-
-    ********************************
-            OLED DISPLAY Test
-    ********************************
-
-    Running Oled display Detect Test
-
-    Oled display Detection Successful!
-
-    Oled display Detect Test Passed!
-    OLED LCD Display test PASS
-
-    Oled display Test Passed!
-
-    Oled Tests Completed!!
-
-    -----------------X-----------------
-
-|
-
-OSPI Flash Test
-^^^^^^^^^^^^^^^^^^^
-This test verifies the flash memory connected to OSPI interface.
-One page of flash is written and read back for data verification during the test.
-
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘ospi_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for OSPI flash test is shown below
-
-::
-
-    *********************************************
-    *            OSPI FLASH Test                *
-    *********************************************
-
-    OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x2c
-
-     Verifying the OSPI Flash first page...
-    OSPI NOR Flash first page verification Successful
-
-     Verifying the OSPI Flash last page...
-    OSPI NOR Flash last page verification Successful
-
-    OSPI NOR Flash verification Successful
-|
-
-PCIe (2-lane) Test
-^^^^^^^^^^^^^^^^^^^
-This test verifies the two-lane PCIe ports on the AM65x IDK kit.
-Two AM65x IDK kits are required to run this test.
-Both the boards should be equipped with SD cards having the same diagnostic test binaries.
-
-.. note::
-   Current version of test is exercising only one lane of the 2-lane PCIe card.
-
-Test Accessories
-"""""""""""""""""
- - Two AM65x IDK kits
- - PCIe two-lane cable
-
-Test Setup
-"""""""""""
- - Connect PCIe ports on both the IDK kits with a two-lane PCIe cable.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘pcie_TEST’ on both the boards
- - Press ‘R’ on first board serial console to enable rootcomplex operation
- - Press ‘E’ on second board serial console to enable endpoint operation
- - Verify the test log on serial console.
-
-Test Log
-"""""""""""
-Sample log for 2-lane PCIe test is shown below
-
-Sample log for board running in RC mode
-
-::
-
-    **********************************************
-    *                PCIe Test                   *
-    **********************************************
-    Enter: E for Endpoint or R for Root Complex
-    R
-    * RC mode *
-    This is PCIE RC
-    Link is up
-    link status reg =0x30130000
-    Link speed:Gen3
-    RC writes a pattern to EP
-    RC received data, loopback test passed
-
-|
-
-Sample log for board running in EP mode
-
-::
-
-    **********************************************
-    *                PCIe Test                   *
-    **********************************************
-    Enter: E for Endpoint or R for Root Complex
-    E
-    * EP mode *
-    This is PCIE EP
-    Link is up
-    link status reg =0x10130000
-    Link speed:Gen3
-    EP received data and will write back
-
-|
-
-PCIe (1-lane) Test
-^^^^^^^^^^^^^^^^^^^
-This test verifies the one-lane PCIe ports on the AM65x EVM kit.
-Two AM65x EVM kits are required to run this test.
-Both the boards should be equipped with SD cards having the same diagnostic test binaries.
-
-Test Accessories
-"""""""""""""""""
- - Two AM65x EVM kits
- - PCIe one-lane cable
-
-Test Setup
-"""""""""""
- - Connect PCIe ports on both the EVM kits with a one-lane PCIe cable.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘pcie_TEST’ on both the boards
- - Press ‘R’ on first board serial console to enable rootcomplex operation
- - Press ‘E’ on second board serial console to enable endpoint operation
- - Verify the test log on serial console.
-
-Test Log
-"""""""""""
-Sample log for 1-lane PCIe test is shown below
-
-Sample log for board running in RC mode
-
-::
-
-    **********************************************
-    *                PCIe Test                   *
-    **********************************************
-    Enter: E for Endpoint or R for Root Complex
-    R
-    * RC mode *
-    This is PCIE RC
-    Link is up
-    link status reg =0x30130000
-    Link speed:Gen3
-    RC writes a pattern to EP
-    RC received data, loopback test passed
-
-|
-
-Sample log for board running in EP mode
-
-::
-
-    **********************************************
-    *                PCIe Test                   *
-    **********************************************
-    Enter: E for Endpoint or R for Root Complex
-    E
-    * EP mode *
-    This is PCIE EP
-    Link is up
-    link status reg =0x10130000
-    Link speed:Gen3
-    EP received data and will write back
-
-|
-
-PMIC Test
-^^^^^^^^^
-This test verifies PMIC interface on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘pmic_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for PMIC test is shown below
-
-::
-
-    *********************************************
-    *                PMIC Test                  *
-    *********************************************
-    Testing PMIC module...
-    PMIC ID = 0x51043990
-    Initial PMIC voltage = 0xff
-    Setting PMIC voltage to 0x44
-    done!
-    PMIC voltage after = 0x44
-    Setting PMIC voltage to original value
-    Final voltage value = 0xff
-    Test PASSED!
-|
-
-PWM Test
-^^^^^^^^^
-This test verifies the PWM module to generate a pulse of 1KHz with different
-duty cycles on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-Oscilloscope to confirm the PWM output
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘pwm_TEST’
- - Verify the test log on serial console
- - Verify the PWM output to cofirm the duty cycle generated by the test
-
-Refer below table for the PWM output signals generated by the test on different platforms
-
-+---------------+-----------------+
-| HW Platform   | PWM Output Pin  |
-+===============+=================+
-| evmK2G        | J12 pin 33      |
-+---------------+-----------------+
-| evmAM572x     | P17 pin 5       |
-+---------------+-----------------+
-| idkAM437x     | J16 pin 14      |
-+---------------+-----------------+
-| evmAM335x     | J5 pin 13       |
-+---------------+-----------------+
-
-Test Log
-"""""""""
-Sample log for PWM test is shown below
-
-::
-
-    *********************************************
-    *                 PWM Test                  *
-    *********************************************
-
-    Generating 1KHz PWM pulse with 25 Duty Cycle
-
-    Generating 1KHz PWM pulse with 50 Duty Cycle
-
-    Generating 1KHz PWM pulse with 75 Duty Cycle
-
-    PWM Test Completed!
-|
-
-QSPI Test
-^^^^^^^^^
-This test verifies the QSPI flash on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘qspi_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for QSPI test is shown below
-
-::
-
-    *********************************************
-    *                 QSPI Test                 *
-    *********************************************
-
-    Testing QSPI read/write...
-    Test PASSED!
-|
-
-Rotary Switch Test
-^^^^^^^^^^^^^^^^^^^^^
-This test verifies reading the rotary switch inputs on HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘rotarySwitch_TEST’
- - Verify the test log on serial console
- - Confirm the test result by pressing 'y' in case rotary switch input is read properly, else any other key to indicate failure.
-
-Test Log
-"""""""""""
-Sample log for rotary switch test is shown below
-
-::
-
-    ********************************
-           ROTARY SWITCH Test
-    ********************************
-
-    Running Rotary switch Detect Test
-
-    Rotary switch Detection Successful!
-
-    Rotary switch Detect Test Passed!
-
-    Running Rotary switch position Test
-
-    The rotary switch is at position 7
-
-    Rotary switch position Test Passed!
-
-    Press 'r' to run the test again,
-    or any other character to exit: y
-
-    Rotary switch Test Passed!
-
-    Rotary switch Tests Completed!!
-
-    -----------------X-----------------
-
-|
-
-RS485 UART Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies RS485 interface on platform under test.
-RS485 interface is connected to PRU-ICSS port of the SoC.
-Test outputs a test string through RS485 UART interface and receives user input as confirmation.
-RS485 to RS232 USB cable is used on AM65x IDK platform to run the test.
-
-Test Accessories
-"""""""""""""""""
-RS485 to RS232 USB cable (AM65x IDK)
-
-Test Setup
-"""""""""""
-am65x_idk:
- - Connect RS485 to RS232 USB cable between RS485 UART port of the board and host PC.
- - Setup serial console application on host PC with below configurations
- ::
-
-    Baud rate    -    115200
-    Data length  -    8 bit
-    Parity       -    None
-    Stop bits    -    1
-    Flow control -    None
-
-Test Execution
-"""""""""""""""
-am65x_idk:
- - Select the menu option to run ‘rs485_TEST’
- - Verify the test log on serial console
- - Confirm the test result on RS485 UART console
-
-Test Log
-"""""""""""
-Sample log for RS485 UART test (am65xx_idk) is shown below
-
-Main test console log
-::
-
-    *********************************************
-    *           PRU-ICSS UART Test              *
-    *********************************************
-
-    Check PRU UART console for the test logs
-
-    PRU-ICSS UART Test Passed!!
-
-    PRU-ICSS UART Test Completed!
-|
-
-RS485 UART console log
-::
-
-    *********************************************
-    *           PRU-ICSS UART Test              *
-    *********************************************
-
-    Testing UART print to console at 115.2k baud rate
-    Press 'y' to verify pass: Test Passed
-|
-
-RTC Test
-^^^^^^^^^
-This test verifies the on-chip RTC Timer on the HW platform under test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘rtc_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for RTC test is shown below
-
-::
-
-    ***********************************************
-    *                 RTC Test                    *
-    ***********************************************
-
-    Current Date and Time:
-    10:23:52  21:6:16 Sunday
-    Test Passed!
-|
-
-Temperature Sensor Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies reading the ambient temperature from temperature sensor interface.
-Test verifies all the temperature sensor devices on the board.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘temperature_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for temperature sensor test is shown below
-
-::
-
-    *********************************************
-    *          Temperature Sensor Test          *
-    *********************************************
-
-    Running temperature sensor test...
-    Read temperature register value - 568
-
-    Temperature read from the temperature sensor
-     target address - 0x48 is 35 degree centigrade
-    Read temperature register value - 520
-
-    Temperature read from the temperature sensor
-     target address - 0x49 is 32 degree centigrade
-    Temperature sensor test Passed!
-
-|
-
-Timer Test
-^^^^^^^^^^^
-This test verifies the on-chip timer module to generate 1msec tick on the HW platform under test.
-Test waits for 2secs counting the timer interrupt.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘timer_TEST’
- - Verify the test log on serial console
- - Verify the time that tests waits counting the timer interrupts
- - Press 'y' if the test waits for 2secs or press any key in case wait time is more or less than 2secs
-
-Test Log
-"""""""""
-Sample log for Timer test is shown below
-
-::
-
-    *********************************************
-    *              1MSEC TIMER Test             *
-    *********************************************
-
-    Timer Configured for 1msec interrupt
-    Enabling Timer Interrupts
-    Test waits till Timer generates 2000 (~2secs) interrupts
-
-    Press 'y' if timer ran for correct duration, else any other key:y
-
-    Test PASSED!
-|
-
-UART Test
-^^^^^^^^^^^^
-This test verifies the UART serial port by sending a test string to the UART serial console
-and reading user input to confirm the test result.
-
-Test Accessories
-"""""""""""""""""
-UART serial cable.
-Different platforms may need different cable for verifying the serial port. Refer to HW manual
-for more details.
-
-Test Setup
-"""""""""""
- - Connect the UART serial cable between the board and host PC
- - Setup serial console application on host PC with below configurations
- ::
-
-    Baud rate    -    115200
-    Data length  -    8 bit
-    Parity       -    None
-    Stop bits    -    1
-    Flow control -    None
-
- - Four UART ports are verified on am65xx_evm platform and three UART ports are verified on am65xx_idk platform.
-   Need to make above setup on all serial consoles connected to multiple ports on these platforms.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘uart_TEST’
- - Verify the test log on serial console. Verify the test log on all the serial consoles in case
-   the HW platform supports more than one serial port
-
-Test Log
-"""""""""""
-Sample UART test log is shown below
-
-::
-
-    *********************************************
-    *                 UART Test                 *
-    *********************************************
-
-    Testing UART print to console at 115.2k baud rate
-    Press 'y' to verify pass: y
-    Received: y
-
-    Test PASSED!
-
-|
-
-UART2USB Test
-^^^^^^^^^^^^^^
-This test verifies the UART to USB serial port interface on K2G EVM.
-
-Test Accessories
-"""""""""""""""""
-mini USB cable
-
-Test Setup
-"""""""""""
- - Connect the UART serial cable between the board (J23) and host PC
- - Setup serial console application on host PC with below configurations
- ::
-
-    Baud rate    -    115200
-    Data length  -    8 bit
-    Parity       -    None
-    Stop bits    -    1
-    Flow control -    None
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘uart2usb_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""
-Sample log for UART2USB test is shown below
-
-Log on the main test console
-::
-
-    *************************************************
-    *                 UART2USB Test                 *
-    *************************************************
-
-    Check the messages on UART2USB console
-
-    Received: y
-    Test PASSED!
-|
-
-Log on the UART to USB test console
-::
-
-    Testing UART print to console at 115.2k baud rate
-    Press 'y' to verify pass: y
-
-|
-
-USB Device Test
-^^^^^^^^^^^^^^^^^^
-This test verifies USB device mode operation of the HW platform under test.
-USB interface functions as USB mass storage device during the test.
-On-board memory is used as storage media which can be accessed from USB host PC
-after successful enumeration of the device.
-USB interface operates at high-speed (USB 2.0) during the test.
-
-Test Accessories
-"""""""""""""""""
-USB cable
-
-Test Setup
-"""""""""""
-Connect USB device port of the board to host PC.
-Check below table for the details of USB device port used by the test on different platforms.
-
-+---------------+-----------------+
-| HW Platform   | USB Device Port |
-+===============+=================+
-| am65xx_evm    | J3 on CP board  |
-+---------------+-----------------+
-| am65xx_idk    | J3 on CP board  |
-+---------------+-----------------+
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘usbDevice_TEST’
- - Verify the test log on serial console
- - Check the USB device enumeration on the host PC
- - Verify the data write/read access to new drive displayed on the host PC
-
-Test Log
-"""""""""""
-Sample log for USB device test is shown below
-
-::
-
-    *********************************************
-    *                 USB Device Test           *
-    *********************************************
-
-    Running USB Device test...
-
-    USB device MSC Application!!
-
-    Passed RAMDISKUtilsInit function
-
-    Done configuring USB driver and its interrupts. Ready to use
-
-|
-
-USB Host Test
-^^^^^^^^^^^^^^^^^^
-This test verifies USB host mode operation of the HW platform under test.
-USB interface functions as USB mass storage host during the test.
-USB device connected to the board will be enumerated, a file will be created,
-written with test data and read back to verify the data.
-USB interface operates at high-speed (USB 2.0) during the test.
-
-Test Accessories
-"""""""""""""""""
-USB OTG pen drive or normal USB pen drive with OTG cable
-
-Test Setup
-"""""""""""
-Connect USB pen drive to host port of the board.
-Check below table for the details of USB host port used by the test on different platforms.
-
-+---------------+-----------------+
-| HW Platform   | USB Host Port   |
-+===============+=================+
-| am65xx_evm    | J3 on CP board  |
-+---------------+-----------------+
-| am65xx_idk    | J3 on CP board. |
-|               | J13 on SerDes   |
-|               | board           |
-+---------------+-----------------+
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘usbHost_TEST’
- - Test supports USB host port on CP board and SerDes board on AM65x IDK platform.
-   Choose the board under test in the serial console while running the test on am65xx_idk
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for USB host test on am65xx_evm is shown below
-
-::
-
-    *************************************************
-    *                  USB Host Test                *
-    *************************************************
-
-    USB Host MSC example!!
-
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-    USB Host test Passed
-
-|
-
-Sample log for USB host test on am65xx_idk CP board is shown below
-
-::
-
-    *************************************************
-    *                  USB Host Test                *
-    *************************************************
-
-    USB Host MSC example!!
-
-    Select the options below on which application has to be run
-
-    1.CP board
-    2.Serdes Board
-    1
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-    USB Host test Passed
-
-|
-
-Sample log for USB host test on am65xx_idk SerDes board is shown below
-
-::
-
-    *************************************************
-    *                  USB Host Test                *
-    *************************************************
-
-    USB Host MSC example!!
-
-    Select the options below on which application has to be run
-
-    1.CP board
-    2.Serdes Board
-    2
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-    USB Host test Passed
-
-|
-
-Stress Tests
------------------
-This section describes the test procedure and setup for diagnostic stress tests.
-Stress test execution is done based on the type of interface as listed below
-
-- Memory interfaces: Whole memory is accessed during stress test
-
-- Communication interfaces (Ethernet, UART etc): Bulk data is sent during the
-  stress test
-
-- Control interfaces (On-board I2C, SPI, GPIO control interfaces): Functional
-  test is repeated for 100 iterations
-
-User confirmation for pass/fail status is disabled during the stress test.
-
-Enter the character 'b' to break the stress test before it completes 100 iterations for control interfaces.
-There is no option to break the stress test before completion in case of memory and communication interfaces.
-
-Only partial logs are provided for stress tests for better readability.
-
-Boot EEPROM Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies Boot EEPROM memory. All the pages of the EEPROM are written with
-a test pattern and read back for data verification.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-Make sure pins 2-3 of J44 and J45 headers on AM65x CP board are shorted
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘bootEepromStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for boot EEPROM stress test is shown below
-
-::
-
-    *******************************************
-    *           Boot EEPROM Stress Test       *
-    *******************************************
-
-    Verifying the Boot EEPROM interface under stress conditions...
-
-    Verifying the page number - 0
-
-    Verifying the page number - 1
-
-    Verifying the page number - 2
-
-    Verifying the page number - 3
-
-    Verifying the page number - 4
-
-    Verifying the page number - 5
-
-    Verifying the page number - 6
-
-    Verifying the page number - 7
-
-    Verifying the page number - 8
-
-    Verifying the page number - 9
-
-    Verifying the page number - 10
-
-    Verifying the page number - 11
-
-    Verifying the page number - 12
-
-    Verifying the page number - 13
-
-    Verifying the page number - 14
-
-    Verifying the page number - 15
-
-    Verifying the page number - 16
-
-    Verifying the page number - 17
-
-    Verifying the page number - 18
-
-    Verifying the page number - 19
-
-    Verifying the page number - 20
-
-    ...
-    ...
-    ...
-
-    Verifying the page number - 500
-
-    Verifying the page number - 501
-
-    Verifying the page number - 502
-
-    Verifying the page number - 503
-
-    Verifying the page number - 504
-
-    Verifying the page number - 505
-
-    Verifying the page number - 506
-
-    Verifying the page number - 507
-
-    Verifying the page number - 508
-
-    Verifying the page number - 509
-
-    Verifying the page number - 510
-
-    Verifying the page number - 511
-
-    Boot EEPROM memory verification Successful under stress conditions
-
-    Clearing the Boot EEPROM pages used for testing...
-
-    Clearing the Boot EEPROM pages successful...
-
-|
-
-Current Monitor Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Test reads the voltage and current values from different current monitor devices available on the board.
-All the current monitor devices available on the board are verified during the test.
-Test is repeated for 100 iterations.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-For iceK2G, this test expects J16 and J17 to be connected with jumper
-shunts. This enables the current monitors to be used.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘currentMonitorStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for current monitor stress test is shown below
-
-::
-
-    **********************************************
-    *            Current Monitor Test            *
-    **********************************************
-
-
-    Running Current Monitor Test in Stress Mode for 100 Number of Times...
-
-
-    Verifying Device VDD_CORE at Address - 0x40
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1003mV
-    Reading the Power register...
-    Power = 915mW
-    Reading the Current register...
-    Current = 11mA
-
-
-    Verifying Device VDD_MCU at Address - 0x41
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 4mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 998mV
-    Reading the Power register...
-    Power = 21282mW
-    Reading the Current register...
-    Current = 425mA
-
-
-    Verifying Device VDD_MPU at Address - 0x42
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1002mV
-    Reading the Power register...
-    Power = 503mW
-    Reading the Current register...
-    Current = 7mA
-
-
-    Verifying Device SoC_DVDD3V3 at Address - 0x43
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 3338mV
-    Reading the Power register...
-    Power = 2670mW
-    Reading the Current register...
-    Current = 18mA
-
-
-    Verifying Device SoC_DVDD1V8 at Address - 0x44
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1800mV
-    Reading the Power register...
-    Power = 3204mW
-    Reading the Current register...
-    Current = 26mA
-
-
-    Verifying Device SoC_AVDD1V8 at Address - 0x45
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 3mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1797mV
-    Reading the Power register...
-    Power = 15713mW
-    Reading the Current register...
-    Current = 70mA
-
-
-    Verifying Device SoC_VDDS_DDR at Address - 0x46
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1197mV
-    Reading the Power register...
-    Power = 1388mW
-    Reading the Current register...
-    Current = 66mA
-
-
-    Verifying Device VDD_DDR at Address - 0x47
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1198mV
-    Reading the Power register...
-    Power = 689mW
-    Reading the Current register...
-    Current = 10mA
-
-
-
-
-    Iteration : 1 Current Monitor Test Passed
-
-    ...
-    ...
-    ...
-
-
-    Verifying Device VDD_CORE at Address - 0x40
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1003mV
-    Reading the Power register...
-    Power = 915mW
-    Reading the Current register...
-    Current = 12mA
-
-
-    Verifying Device VDD_MCU at Address - 0x41
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 4mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 998mV
-    Reading the Power register...
-    Power = 21282mW
-    Reading the Current register...
-    Current = 425mA
-
-
-    Verifying Device VDD_MPU at Address - 0x42
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1002mV
-    Reading the Power register...
-    Power = 503mW
-    Reading the Current register...
-    Current = 7mA
-
-
-    Verifying Device SoC_DVDD3V3 at Address - 0x43
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 3337mV
-    Reading the Power register...
-    Power = 2860mW
-    Reading the Current register...
-    Current = 18mA
-
-
-    Verifying Device SoC_DVDD1V8 at Address - 0x44
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1800mV
-    Reading the Power register...
-    Power = 3204mW
-    Reading the Current register...
-    Current = 26mA
-
-
-    Verifying Device SoC_AVDD1V8 at Address - 0x45
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 3mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1797mV
-    Reading the Power register...
-    Power = 15789mW
-    Reading the Current register...
-    Current = 70mA
-
-
-    Verifying Device SoC_VDDS_DDR at Address - 0x46
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1198mV
-    Reading the Power register...
-    Power = 1388mW
-    Reading the Current register...
-    Current = 66mA
-
-
-    Verifying Device VDD_DDR at Address - 0x47
-    Setting the configuration register...
-    Setting the calibration register...
-    Reading the Shunt Voltage register...
-    Shunt Voltage = 0mV
-    Reading the Bus Voltage register...
-    Bus Voltage = 1198mV
-    Reading the Power register...
-    Power = 689mW
-    Reading the Current register...
-    Current = 10mA
-
-
-
-
-    Iteration : 100 Current Monitor Test Passed
-
-
-    Current Monitor Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-|
-
-EMAC Stress Test
-^^^^^^^^^^^^^^^^^
-This test verifies the EMAC Ethernet port on HW platform under test.
-Ethernet link and data transmit/receive are verified during this test.
-Ethernet interface is configured for 100mbps speed and 10240 packets are sent/received during the test.
-
-Test Accessories
-""""""""""""""""""
-Ethernet loopback cables/plugs
-
-Test Setup
-"""""""""""
-Refer `EMAC Test Setup <index_board.html#id40>`_ section for more details
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘emacStress_TEST’
- - Verify the test log on serial console
-
-
-Test Log
-"""""""""
-
-Sample log for Ethernet stress test is shown below
-
-::
-
-    ************************************************
-    *      ETHERNET LOOPBACK STRESS Test           *
-    ************************************************
-
-
-    Reading Ethernet PHY Register Dump...
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x7949
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x0300
-    PHY Register 0x000a - 0x0c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-    EMAC loopback test application initialization
-    main: emac_open success
-    Configuring Phy
-    Waiting for Link Status
-    Link is UP!!
-
-    Sending Packet: 1
-    Received Packet: 1
-    Sending Packet: 2
-    Received Packet: 2
-    Sending Packet: 3
-    Received Packet: 3
-    Sending Packet: 4
-    Received Packet: 4
-    Sending Packet: 5
-    Received Packet: 5
-    Sending Packet: 6
-    Received Packet: 6
-    Sending Packet: 7
-    Received Packet: 7
-    Sending Packet: 8
-    Received Packet: 8
-    Sending Packet: 9
-    Received Packet: 9
-    Sending Packet: 10
-    Received Packet: 10
-    Sending Packet: 11
-    Received Packet: 11
-    Sending Packet: 12
-    Received Packet: 12
-    Sending Packet: 13
-    Received Packet: 13
-    Sending Packet: 14
-    Received Packet: 14
-    Sending Packet: 15
-    Received Packet: 15
-    Sending Packet: 16
-    Received Packet: 16
-    Sending Packet: 17
-    Received Packet: 17
-    Sending Packet: 18
-    Received Packet: 18
-    Sending Packet: 19
-    Received Packet: 19
-    Sending Packet: 20
-    Received Packet: 20
-    Sending Packet: 21
-    Received Packet: 21
-    Sending Packet: 22
-    Received Packet: 22
-    Sending Packet: 23
-    Received Packet: 23
-    Sending Packet: 24
-    Received Packet: 24
-    Sending Packet: 25
-    Received Packet: 25
-    Sending Packet: 26
-    Received Packet: 26
-    Sending Packet: 27
-    Received Packet: 27
-    Sending Packet: 28
-    Received Packet: 28
-    Sending Packet: 29
-    Received Packet: 29
-    Sending Packet: 30
-    Received Packet: 30
-    Sending Packet: 31
-    Received Packet: 31
-    Sending Packet: 32
-    Received Packet: 32
-    Sending Packet: 33
-    Received Packet: 33
-    Sending Packet: 34
-    Received Packet: 34
-    Sending Packet: 35
-    Received Packet: 35
-    Sending Packet: 36
-    Received Packet: 36
-    Sending Packet: 37
-    Received Packet: 37
-    Sending Packet: 38
-    Received Packet: 38
-    Sending Packet: 39
-    Received Packet: 39
-    Sending Packet: 40
-    Received Packet: 40
-    Sending Packet: 41
-    Received Packet: 41
-    Sending Packet: 42
-    Received Packet: 42
-    Sending Packet: 43
-    Received Packet: 43
-    Sending Packet: 44
-    Received Packet: 44
-    Sending Packet: 45
-    Received Packet: 45
-    Sending Packet: 46
-    Received Packet: 46
-    Sending Packet: 47
-    Received Packet: 47
-    Sending Packet: 48
-    Received Packet: 48
-    Sending Packet: 49
-    Received Packet: 49
-    Sending Packet: 50
-    Received Packet: 50
-    Sending Packet: 51
-    Received Packet: 51
-    Sending Packet: 52
-    Received Packet: 52
-    Sending Packet: 53
-    Received Packet: 53
-    Sending Packet: 54
-    Received Packet: 54
-    Sending Packet: 55
-    Received Packet: 55
-    Sending Packet: 56
-    Received Packet: 56
-    Sending Packet: 57
-    Received Packet: 57
-    Sending Packet: 58
-    Received Packet: 58
-    Sending Packet: 59
-    Received Packet: 59
-    Sending Packet: 60
-    Received Packet: 60
-    Sending Packet: 61
-    Received Packet: 61
-    Sending Packet: 62
-    Received Packet: 62
-    Sending Packet: 63
-    Received Packet: 63
-    Sending Packet: 64
-    Received Packet: 64
-
-    ...
-    ...
-    ...
-
-    Sending Packet: 10200
-    Received Packet: 10200
-    Sending Packet: 10201
-    Received Packet: 10201
-    Sending Packet: 10202
-    Received Packet: 10202
-    Sending Packet: 10203
-    Received Packet: 10203
-    Sending Packet: 10204
-    Received Packet: 10204
-    Sending Packet: 10205
-    Received Packet: 10205
-    Sending Packet: 10206
-    Received Packet: 10206
-    Sending Packet: 10207
-    Received Packet: 10207
-    Sending Packet: 10208
-    Received Packet: 10208
-    Sending Packet: 10209
-    Received Packet: 10209
-    Sending Packet: 10210
-    Received Packet: 10210
-    Sending Packet: 10211
-    Received Packet: 10211
-    Sending Packet: 10212
-    Received Packet: 10212
-    Sending Packet: 10213
-    Received Packet: 10213
-    Sending Packet: 10214
-    Received Packet: 10214
-    Sending Packet: 10215
-    Received Packet: 10215
-    Sending Packet: 10216
-    Received Packet: 10216
-    Sending Packet: 10217
-    Received Packet: 10217
-    Sending Packet: 10218
-    Received Packet: 10218
-    Sending Packet: 10219
-    Received Packet: 10219
-    Sending Packet: 10220
-    Received Packet: 10220
-    Sending Packet: 10221
-    Received Packet: 10221
-    Sending Packet: 10222
-    Received Packet: 10222
-    Sending Packet: 10223
-    Received Packet: 10223
-    Sending Packet: 10224
-    Received Packet: 10224
-    Sending Packet: 10225
-    Received Packet: 10225
-    Sending Packet: 10226
-    Received Packet: 10226
-    Sending Packet: 10227
-    Received Packet: 10227
-    Sending Packet: 10228
-    Received Packet: 10228
-    Sending Packet: 10229
-    Received Packet: 10229
-    Sending Packet: 10230
-    Received Packet: 10230
-    Sending Packet: 10231
-    Received Packet: 10231
-    Sending Packet: 10232
-    Received Packet: 10232
-    Sending Packet: 10233
-    Received Packet: 10233
-    Sending Packet: 10234
-    Received Packet: 10234
-    Sending Packet: 10235
-    Received Packet: 10235
-    Sending Packet: 10236
-    Received Packet: 10236
-    Sending Packet: 10237
-    Received Packet: 10237
-    Sending Packet: 10238
-    Received Packet: 10238
-    Sending Packet: 10239
-    Received Packet: 10239
-    Sending Packet: 10240
-    Received Packet: 10240
-
-    Packets sent: 10240, Packets received: 10240
-
-    Ethernet Loopback test passed
-    All tests completed
-
-|
-
-eMMC Stress Test
-^^^^^^^^^^^^^^^^
-This test verifies eMMC memory interface on the HW platform under test.
-Whole memory of eMMC is written and read during the test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘emmcStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for eMMC stress test is shown below
-
-::
-
-    *********************************************
-    *                 eMMC Stress Test            *
-    ***********************************************
-
-    PASS: Read/Write Success for this block-0x300000
-
-    PASS: Read/Write Success for this block-0x301000
-
-    PASS: Read/Write Success for this block-0x302000
-
-    PASS: Read/Write Success for this block-0x303000
-
-    PASS: Read/Write Success for this block-0x304000
-
-    PASS: Read/Write Success for this block-0x305000
-
-    PASS: Read/Write Success for this block-0x306000
-
-    PASS: Read/Write Success for this block-0x307000
-
-    PASS: Read/Write Success for this block-0x308000
-
-    PASS: Read/Write Success for this block-0x309000
-
-    PASS: Read/Write Success for this block-0x30a000
-
-    PASS: Read/Write Success for this block-0x30b000
-
-    PASS: Read/Write Success for this block-0x30c000
-
-    PASS: Read/Write Success for this block-0x30d000
-
-    PASS: Read/Write Success for this block-0x30e000
-
-    PASS: Read/Write Success for this block-0x30f000
-
-    ...
-    ...
-    ...
-
-    PASS: Read/Write Success for this block-0x1d55000
-
-    PASS: Read/Write Success for this block-0x1d56000
-
-    PASS: Read/Write Success for this block-0x1d57000
-
-    PASS: Read/Write Success for this block-0x1d58000
-
-    PASS: Read/Write Success for this block-0x1d59000
-
-    PASS: Read/Write Success for this block-0x1d5a000
-
-    PASS: Read/Write Success for this block-0x1d5b000
-
-    PASS: Read/Write Success for this pattern
-|
-
-External RTC Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies setting the time, date and running the clock for on-board RTC interface.
-RTC configuration is done through I2C interface. Time and date are read for 100 times for every 5secs
-during the test to demonstrate operation of the RTC clock.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘extRtcStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for external RTC stress test is shown below
-
-::
-
-    *********************************************
-    *                 RTC Test                  *
-    *********************************************
-    Running RTC Test in Stress Mode for 100 Number of Times...
-    Enter 'b' in Serial Console to Terminate the Test
-
-
-    Running RTC Test...
-
-    Setting Time...
-
-    Setting Date...
-
-    Reading Time...
-
-    Reading Date...
-
-
-    Displaying time: 11:59:53 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 11:59:57 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 12:0:2 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:7 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:12 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:17 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-    If the time and date increment, press 'y' to indicate pass or any other character to indicate failure
-
-
-    Iteration : 1 RTC Test Passed
-
-    Running RTC Test...
-
-    Setting Time...
-
-    Setting Date...
-
-    Reading Time...
-
-    Reading Date...
-
-
-    Displaying time: 11:59:53 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 11:59:58 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 12:0:3 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:8 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:14 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:19 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-    If the time and date increment, press 'y' to indicate pass or any other character to indicate failure
-
-
-    Iteration : 2 RTC Test Passed
-
-    ...
-    ...
-    ...
-
-    Running RTC Test...
-
-    Setting Time...
-
-    Setting Date...
-
-    Reading Time...
-
-    Reading Date...
-
-
-    Displaying time: 11:59:53 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 11:59:58 PM
-    Displaying  Day: Sunday
-    Displaying Date: 31/12/18
-
-    Displaying time: 12:0:3 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:8 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:13 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-
-    Displaying time: 12:0:18 AM
-    Displaying  Day: Monday
-    Displaying Date: 1/1/19
-    If the time and date increment, press 'y' to indicate pass or any other character to indicate failure
-
-
-    Iteration : 100 RTC Test Passed
-    RTC Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-    RTC Test Passed
-
-|
-
-ICSSG EMAC Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^
-This port to port Ethernet test verifies the PRU-ICSS gigabit Ethernet interface on the board under test.
-During the test, Ethernet interface is configured for 1000mbps speed with one port of an ICSS instance
-is connected to another port. 10240 packets are sent from one port and received by another port.
-Both the ports are verified for transmit and receive. All the ICSSG EMAC ports available on the board
-verified during the test.
-
-Test Accessories
-""""""""""""""""""
-Ethernet cables
-
-Test Setup
-""""""""""""
-Refer `ICSSG EMAC Test Setup <index_board.html#id68>`_ section for more details
-
-Test Execution
-""""""""""""""""
- - Select the menu option to run ‘icssgEmacStress_TEST’
- - Verify the test log on serial console
-
-
-Test Log
-""""""""""
-
-Sample log for ICSGG Ethernet stress test is shown below
-
-::
-
-    **********************************************
-    *           ICSSG EMAC STRESS TEST           *
-    **********************************************
-
-
-    Performing UDMA driver init...
-
-
-    Reading Ethernet PHY Register Dump...
-
-
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x1b00
-    PHY Register 0x000a - 0x7c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Configuration Register(CFG4) 0x0031 - 0xbf02
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0003
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x1300
-    PHY Register 0x000a - 0x3c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Configuration Register(CFG4) 0x0031 - 0xbd02
-    PHY Register(STRAP1) 0x006e - 0x0003
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x1b00
-    PHY Register 0x000a - 0x3c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Configuration Register(CFG4) 0x0031 - 0xbd02
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0003
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x1300
-    PHY Register 0x000a - 0x3c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Configuration Register(CFG4) 0x0031 - 0xbe02
-    PHY Register(STRAP1) 0x006e - 0x0003
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0000
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x1b00
-    PHY Register 0x000a - 0x7c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Configuration Register(CFG4) 0x0031 - 0xbc02
-    PHY Register(STRAP1) 0x006e - 0x0000
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-
-
-    Register Dump for PHY Addr - 0x0003
-    PHY Register 0x0000 - 0x1140
-    PHY Register 0x0001 - 0x796d
-    PHY Register 0x0002 - 0x2000
-    PHY Register 0x0003 - 0xa231
-    PHY Register 0x0004 - 0x01e1
-    PHY Register 0x0005 - 0xc1e1
-    PHY Register 0x0006 - 0x006f
-    PHY Register 0x0007 - 0x2001
-    PHY Register 0x0008 - 0x4806
-    PHY Register 0x0009 - 0x1300
-    PHY Register 0x000a - 0x3c00
-    PHY Register 0x000b - 0x0000
-    PHY Register 0x000c - 0x0000
-    PHY Register 0x000d - 0x401f
-    PHY Register 0x000e - 0x0006
-    PHY Register 0x000f - 0x3000
-    PHY Configuration Register(CFG4) 0x0031 - 0xbc02
-    PHY Register(STRAP1) 0x006e - 0x0003
-    PHY Register(STRAP2) 0x006f - 0x0000
-    RGMII Control Register (RGMIICTL) Value - 0x00d3
-      --- RGMII_RX_CLK_DELAY - 0x0001
-      --- RGMII_TX_CLK_DELAY - 0x0001
-    RGMII Delay Control Register (RGMIIDCTL) Value - 0x0077
-    port 0:  FW is ready
-    Port 0:  Config FW Complete
-    port 1:  FW is ready
-    Port 1:  Config FW Complete
-    port 2:  FW is ready
-    Port 2:  Config FW Complete
-    port 3:  FW is ready
-    Port 3:  Config FW Complete
-    port 4:  FW is ready
-    Port 4:  Config FW Complete
-    port 5:  FW is ready
-    Port 5:  Config FW Complete
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 0 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 1 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 2 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 3 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 4 LINK IS UP!
-
-    EMAC loopback test application initialization
-    main: emac_open success
-
-
-    Waiting for LINK UP, Make sure to plugin loopback cable
-    PRU_ICSS port 5 LINK IS UP!
-
-
-    Sending Packets on Port - 0
-    Receiving Packets on Port - 1
-
-    Sending Packet: 1
-    Received Packet: 1
-    Sending Packet: 2
-    Received Packet: 2
-    Sending Packet: 3
-    Received Packet: 3
-    Sending Packet: 4
-    Received Packet: 4
-    Sending Packet: 5
-    Received Packet: 5
-    Sending Packet: 6
-    Received Packet: 6
-    Sending Packet: 7
-    Received Packet: 7
-    Sending Packet: 8
-    Received Packet: 8
-    Sending Packet: 9
-    Received Packet: 9
-    Sending Packet: 10
-    Received Packet: 10
-    Sending Packet: 11
-    Received Packet: 11
-    Sending Packet: 12
-    Received Packet: 12
-    Sending Packet: 13
-    Received Packet: 13
-    Sending Packet: 14
-    Received Packet: 14
-    Sending Packet: 15
-    Received Packet: 15
-    Sending Packet: 16
-    Received Packet: 16
-
-    ...
-    ...
-    ...
-
-    Sending Packet: 10236
-    Received Packet: 10236
-    Sending Packet: 10237
-    Received Packet: 10237
-    Sending Packet: 10238
-    Received Packet: 10238
-    Sending Packet: 10239
-    Received Packet: 10239
-    Sending Packet: 10240
-    Received Packet: 10240
-
-    Packets Sent: 10240, Packets Received: 10240
-    Port 0 Send to Port 1 Receive Test Passed!
-
-    Sending Packets on Port - 1
-    Receiving Packets on Port - 0
-    Sending Packet: 1
-    Received Packet: 1
-    Sending Packet: 2
-    Received Packet: 2
-    Sending Packet: 3
-    Received Packet: 3
-    Sending Packet: 4
-    Received Packet: 4
-    Sending Packet: 5
-    Received Packet: 5
-    Sending Packet: 6
-    Received Packet: 6
-    Sending Packet: 7
-    Received Packet: 7
-    Sending Packet: 8
-    Received Packet: 8
-    Sending Packet: 9
-    Received Packet: 9
-    Sending Packet: 10
-    Received Packet: 10
-    Sending Packet: 11
-    Received Packet: 11
-    Sending Packet: 12
-    Received Packet: 12
-    Sending Packet: 13
-    Received Packet: 13
-    Sending Packet: 14
-    Received Packet: 14
-    Sending Packet: 15
-    Received Packet: 15
-    Sending Packet: 16
-    Received Packet: 16
-
-    ...
-    ...
-    ...
-
-    Sending Packet: 10236
-    Received Packet: 10236
-    Sending Packet: 10237
-    Received Packet: 10237
-    Sending Packet: 10238
-    Received Packet: 10238
-    Sending Packet: 10239
-    Received Packet: 10239
-    Sending Packet: 10240
-    Received Packet: 10240
-
-    Packets Sent: 10240, Packets Received: 10240
-    Port 1 Send to Port 0 Receive Test Passed!
-
-    Sending Packets on Port - 2
-    Receiving Packets on Port - 3
-
-    Sending Packet: 1
-    Received Packet: 1
-    Sending Packet: 2
-    Received Packet: 2
-    Sending Packet: 3
-    Received Packet: 3
-    Sending Packet: 4
-    Received Packet: 4
-    Sending Packet: 5
-    Received Packet: 5
-    Sending Packet: 6
-    Received Packet: 6
-    Sending Packet: 7
-    Received Packet: 7
-    Sending Packet: 8
-    Received Packet: 8
-    Sending Packet: 9
-    Received Packet: 9
-    Sending Packet: 10
-    Received Packet: 10
-    Sending Packet: 11
-    Received Packet: 11
-    Sending Packet: 12
-    Received Packet: 12
-    Sending Packet: 13
-    Received Packet: 13
-    Sending Packet: 14
-    Received Packet: 14
-    Sending Packet: 15
-    Received Packet: 15
-    Sending Packet: 16
-    Received Packet: 16
-
-    ...
-    ...
-    ...
-
-    Sending Packet: 10236
-    Received Packet: 10236
-    Sending Packet: 10237
-    Received Packet: 10237
-    Sending Packet: 10238
-    Received Packet: 10238
-    Sending Packet: 10239
-    Received Packet: 10239
-    Sending Packet: 10240
-    Received Packet: 10240
-
-    Packets Sent: 10240, Packets Received: 10240
-    Port 2 Send to Port 3 Receive Test Passed!
-
-    Sending Packets on Port - 3
-    Receiving Packets on Port - 2
-    Sending Packet: 1
-    Received Packet: 1
-    Sending Packet: 2
-    Received Packet: 2
-    Sending Packet: 3
-    Received Packet: 3
-    Sending Packet: 4
-    Received Packet: 4
-    Sending Packet: 5
-    Received Packet: 5
-    Sending Packet: 6
-    Received Packet: 6
-    Sending Packet: 7
-    Received Packet: 7
-    Sending Packet: 8
-    Received Packet: 8
-    Sending Packet: 9
-    Received Packet: 9
-    Sending Packet: 10
-    Received Packet: 10
-    Sending Packet: 11
-    Received Packet: 11
-    Sending Packet: 12
-    Received Packet: 12
-    Sending Packet: 13
-    Received Packet: 13
-    Sending Packet: 14
-    Received Packet: 14
-    Sending Packet: 15
-    Received Packet: 15
-    Sending Packet: 16
-    Received Packet: 16
-
-    ...
-    ...
-    ...
-
-    Sending Packet: 10236
-    Received Packet: 10236
-    Sending Packet: 10237
-    Received Packet: 10237
-    Sending Packet: 10238
-    Received Packet: 10238
-    Sending Packet: 10239
-    Received Packet: 10239
-    Sending Packet: 10240
-    Received Packet: 10240
-
-    Packets Sent: 10240, Packets Received: 10240
-    Port 2 Send to Port 3 Receive Test Passed!
-
-    ...
-    ...
-    ...
-
-    Sending Packets on Port - 5
-    Receiving Packets on Port - 4
-    Sending Packet: 1
-    Received Packet: 1
-    Sending Packet: 2
-    Received Packet: 2
-    Sending Packet: 3
-    Received Packet: 3
-    Sending Packet: 4
-    Received Packet: 4
-    Sending Packet: 5
-    Received Packet: 5
-    Sending Packet: 6
-    Received Packet: 6
-    Sending Packet: 7
-    Received Packet: 7
-    Sending Packet: 8
-    Received Packet: 8
-    Sending Packet: 9
-    Received Packet: 9
-    Sending Packet: 10
-    Received Packet: 10
-    Sending Packet: 11
-    Received Packet: 11
-    Sending Packet: 12
-    Received Packet: 12
-    Sending Packet: 13
-    Received Packet: 13
-    Sending Packet: 14
-    Received Packet: 14
-    Sending Packet: 15
-    Received Packet: 15
-    Sending Packet: 16
-    Received Packet: 16
-
-    ...
-    ...
-    ...
-
-    Sending Packet: 10236
-    Received Packet: 10236
-    Sending Packet: 10237
-    Received Packet: 10237
-    Sending Packet: 10238
-    Received Packet: 10238
-    Sending Packet: 10239
-    Received Packet: 10239
-    Sending Packet: 10240
-    Received Packet: 10240
-
-    Packets Sent: 10240, Packets Received: 10240
-    Port 5 Send to Port 4 Receive Test Passed!
-
-
-    ICSSG Ethernet Port to Port Test Passed!
-    All Tests Completed
-
-|
-
-ICSS LED Stress Test
-^^^^^^^^^^^^^^^^^^^^^
-This test verifies LEDs connected to PRU-ICSS ports.
-All the LEDs are turned ON and OFF for 3 times during the test.
-Test is repeated for 100 iterations.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘icssgLedStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for ICSS LED stress test is shown below
-
-::
-
-    Running ICSSG LED Test in Stress Mode for 100 Number of Times...
-    Enter 'b' in Serial Console to Terminate the Test
-
-
-    ********************************************
-    *              ICSS LED Test               *
-    ********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 1 ICSSG LED Test Passed
-
-    ********************************************
-    *              ICSS LED Test               *
-    ********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 2 ICSSG LED Test Passed
-
-    ********************************************
-    *              ICSS LED Test               *
-    ********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 3 ICSSG LED Test Passed
-
-    ********************************************
-    *              ICSS LED Test               *
-    ********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 4 ICSSG LED Test Passed
-
-    ********************************************
-    *              ICSS LED Test               *
-    ********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 5 ICSSG LED Test Passed
-
-    ...
-    ...
-    ...
-
-    ********************************************
-    *              ICSS LED Test               *
-    ********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 99 ICSSG LED Test Passed
-
-    ********************************************
-    *              ICSS LED Test               *
-    ********************************************
-
-    Testing ICSSG PRG0 and PRG1 LED's
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 100 ICSSG LED Test Passed
-
-
-    ICSSG LED Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-|
-
-Industrial LED Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies industrial LEDs connected to I2C interface on the HW platform under test.
-All the LEDs are turned ON and OFF for 3 times during the test.
-Test is repeated for 100 iterations.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘ledIndustrialStress_TEST’
- - Confirm that all the industrial LEDs on the board are toggling during the test
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for industrial LED stress test is shown below
-
-::
-
-    *********************************************
-    *            Industrial LED Test            *
-    *********************************************
-
-
-    Running Industrial Test in Stress Mode for 100 Number of Times...
-    Enter 'b' in Serial Console to Terminate the Test
-
-
-    Running Industrial Test...
-    Verifying LED's connected to I2C IO Expander target device...
-
-    Testing Industrial LEDs
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-    Testing Industrial LEDs on AM65xx IDK Board
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 1 Industrial Test Passed
-
-    Running Industrial Test...
-    Verifying LED's connected to I2C IO Expander target device...
-
-    Testing Industrial LEDs
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-    Testing Industrial LEDs on AM65xx IDK Board
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 2 Industrial Test Passed
-
-    Running Industrial Test...
-    Verifying LED's connected to I2C IO Expander target device...
-
-    Testing Industrial LEDs
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-    Testing Industrial LEDs on AM65xx IDK Board
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 3 Industrial Test Passed
-
-    Running Industrial Test...
-    Verifying LED's connected to I2C IO Expander target device...
-
-    Testing Industrial LEDs
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-    Testing Industrial LEDs on AM65xx IDK Board
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 4 Industrial Test Passed
-
-    ...
-    ...
-    ...
-
-    Running Industrial Test...
-    Verifying LED's connected to I2C IO Expander target device...
-
-    Testing Industrial LEDs
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-    Testing Industrial LEDs on AM65xx IDK Board
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 99 Industrial Test Passed
-
-    Running Industrial Test...
-    Verifying LED's connected to I2C IO Expander target device...
-
-    Testing Industrial LEDs
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-    Testing Industrial LEDs on AM65xx IDK Board
-    Cycling LEDs 3 times
-    Press 'y' to verify pass, 'r' to cycle leds again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 100 Industrial Test Passed
-
-    Industrial Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-|
-
-LED Stress Test
-^^^^^^^^^^^^^^^^
-This test verifies general purpose user LEDs on the HW platform under test.
-All the LEDs are turned ON and OFF for 3 times during the test.
-Test is repeated for 100 iterations.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘ledStress_TEST’
- - Confirm that all the general purpose user LEDs on the board are toggling during the test
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for LED stress test is shown below
-
-::
-
-    Running LED Test in Stress Mode for 100 Number of Times...
-    Enter 'b' in Serial Console to Terminate the Test
-
-
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 1 LED Test Passed
-
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 2 LED Test Passed
-
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 3 LED Test Passed
-
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 4 LED Test Passed
-
-    ...
-    ...
-    ...
-
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 99 LED Test Passed
-
-    *********************************************
-    *                 LED Test                  *
-    *********************************************
-
-    Testing LED
-    Blinking LEDs...
-    Press 'y' to verify pass, 'r' to blink again,
-    or any other character to indicate failure: Received: y
-
-    Test PASSED!
-
-
-
-
-    Iteration : 100 LED Test Passed
-
-
-    LED Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-|
-
-Memory (DDR) Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies the DDR memory of the HW platform under test.
-Address bus test is performed with a test pattern and its compliment during the test.
-Walking 1s and walking 0s test is executed additionally as part of stress test.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘memStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-
-Sample DDR stress test log is shown below
-
-::
-
-    *********************************************
-    *              DDR Memory Test              *
-    *********************************************
-
-    Testing writing and reading memory
-    board_external_memory_test: Start address (0x80000000),            end address (0xffffffff)
-    First test started
-    Writing to test area...
-            Write up to 0x80000000 done
-            Write up to 0x90000000 done
-            Write up to 0xa0000000 done
-            Write up to 0xb0000000 done
-            Write up to 0xc0000000 done
-            Write up to 0xd0000000 done
-            Write up to 0xe0000000 done
-            Write up to 0xf0000000 done
-    Write finished!
-    Checking values...
-            Read up to 0x80000000 okay
-            Read up to 0x90000000 okay
-            Read up to 0xa0000000 okay
-            Read up to 0xb0000000 okay
-            Read up to 0xc0000000 okay
-            Read up to 0xd0000000 okay
-            Read up to 0xe0000000 okay
-            Read up to 0xf0000000 okay
-    Second test started
-    Writing complementary values to test area...
-            Write up to 0x80000000 done
-            Write up to 0x90000000 done
-            Write up to 0xa0000000 done
-            Write up to 0xb0000000 done
-            Write up to 0xc0000000 done
-            Write up to 0xd0000000 done
-            Write up to 0xe0000000 done
-            Write up to 0xf0000000 done
-    Write finished!
-    Checking values...
-            Read up to 0x80000000 okay
-            Read up to 0x90000000 okay
-            Read up to 0xa0000000 okay
-            Read up to 0xb0000000 okay
-            Read up to 0xc0000000 okay
-            Read up to 0xd0000000 okay
-            Read up to 0xe0000000 okay
-            Read up to 0xf0000000 okay
-    Board memory test passed!
-             walking1s test verified up to 0x80000000      done
-             walking1s test verified up to 0x90000000      done
-             walking1s test verified up to 0xa0000000      done
-             walking1s test verified up to 0xb0000000      done
-             walking1s test verified up to 0xc0000000      done
-             walking1s test verified up to 0xd0000000      done
-             walking1s test verified up to 0xe0000000      done
-             walking1s test verified up to 0xf0000000      done
-    walking1s test passed!
-             walking0s test verified up to 0x80000000      done
-             walking0s test verified up to 0x90000000      done
-             walking0s test verified up to 0xa0000000      done
-             walking0s test verified up to 0xb0000000      done
-             walking0s test verified up to 0xc0000000      done
-             walking0s test verified up to 0xd0000000      done
-             walking0s test verified up to 0xe0000000      done
-             walking0s test verified up to 0xf0000000      done
-    walking0s test passed!
-    Memory test passed!
-
-|
-
-MMCSD Stress Test
-^^^^^^^^^^^^^^^^^^
-This test verifies SD card interface on the platform under test.
-Whole memory of SD card starting from 1.5GB offset is written and read during the test.
-
-Test Accessories
-"""""""""""""""""
-SD card.
-
-Test Setup
-"""""""""""
-Insert the SD card into MMCSD slot of the board.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘mmcsdStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for SD card stress test is shown below
-
-::
-
-    *********************************************
-    *                 MMCSD Stress Test         *
-    *********************************************
-
-    PASS: Read/Write Success for this block-0x300000
-
-    PASS: Read/Write Success for this block-0x301000
-
-    PASS: Read/Write Success for this block-0x302000
-
-    PASS: Read/Write Success for this block-0x303000
-
-    PASS: Read/Write Success for this block-0x304000
-
-    PASS: Read/Write Success for this block-0x305000
-
-    PASS: Read/Write Success for this block-0x306000
-
-    PASS: Read/Write Success for this block-0x307000
-
-    PASS: Read/Write Success for this block-0x308000
-
-    PASS: Read/Write Success for this block-0x309000
-
-    PASS: Read/Write Success for this block-0x30a000
-
-    PASS: Read/Write Success for this block-0x30b000
-
-    PASS: Read/Write Success for this block-0x30c000
-
-    PASS: Read/Write Success for this block-0x30d000
-
-    PASS: Read/Write Success for this block-0x30e000
-
-    PASS: Read/Write Success for this block-0x30f000
-
-    PASS: Read/Write Success for this block-0x310000
-
-    ...
-    ...
-    ...
-
-    PASS: Read/Write Success for this block-0x5fa000
-
-    PASS: Read/Write Success for this block-0x5fb000
-
-    PASS: Read/Write Success for this block-0x5fc000
-
-    PASS: Read/Write Success for this block-0x5fd000
-
-    PASS: Read/Write Success for this block-0x5fe000
-
-    PASS: Read/Write Success for this block-0x5ff000
-
-    PASS: Read/Write Success for this pattern
-
-|
-
-NOR Flash Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies the NOR flash memory connected to SPI interface.
-Whole memory of flash is written and read back for data verification during the test.
-
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘norflashStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for NOR flash stress test is shown below
-
-::
-
-    ************************************************
-    *            SPI FlASH Stress Test             *
-    ************************************************
-    Reading Flash Device ID...
-    Device ID 0 - 0x20
-    Device ID 1 - 0xba
-    Device ID 2 - 0x18
-    Flash Device ID Match!
-
-    Flash Device ID Read Passed!
-
-    Verifying Sector - 0
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 1
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 2
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 3
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 4
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 5
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 6
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 7
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 8
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 9
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 10
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 11
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 12
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 13
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 14
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 15
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 16
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    ...
-    ...
-    ...
-
-    Verifying Sector - 250
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 251
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 252
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 253
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 254
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    Verifying Sector - 255
-    Data Read matches with Data written
-    SPI Flash Test Passed!
-
-    SPI NOR Flash Test Passed
-
-|
-
-OSPI Flash Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies the flash memory connected to OSPI interface.
-Whole memory of OSPI flash is written and read back for data verification during the test.
-
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘ospiStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for OSPI flash stress test is shown below
-
-::
-
-    ****************************************************
-    *            OSPI FLASH Stress Test                *
-    ****************************************************
-
-    OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x2c
-
-    Verifying the OSPI Flash ...
-
-    OSPI Flash Stress Test Iteration - 1
-
-    Verified upto Page - 0x0
-
-    Verified upto Page - 0x1000
-
-    Verified upto Page - 0x2000
-
-    Verified upto Page - 0x3000
-
-    Verified upto Page - 0x4000
-
-    Verified upto Page - 0x5000
-
-    Verified upto Page - 0x6000
-
-    Verified upto Page - 0x7000
-
-    Verified upto Page - 0x8000
-
-    Verified upto Page - 0x9000
-
-    Verified upto Page - 0xa000
-
-    Verified upto Page - 0xb000
-
-    Verified upto Page - 0xc000
-
-    Verified upto Page - 0xd000
-
-    Verified upto Page - 0xe000
-
-    Verified upto Page - 0xf000
-
-    ...
-    ...
-    ...
-
-    Verified upto Page - 0x3ffd000
-
-    Verified upto Page - 0x3ffe000
-
-    Verified upto Page - 0x3fff000
-
-    OSPI NOR Flash verification Successful
-
-|
-
-Temperature Sensor Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies reading the ambient temperature from temperature sensor interface.
-Test verifies all the temperature sensor devices on the board.
-Test is repeated for 100 iterations.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘temperatureStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for temperature sensor stress test is shown below
-
-::
-
-    *********************************************
-    *          Temperature Sensor Test          *
-    *********************************************
-
-
-    Running Temperature Sensor Test in Stress Mode for 100 Number of Times...
-    Enter 'b' in Serial Console to Terminate the Test
-
-
-    Running Temperature Sensor Test...
-    Running temperature sensor test...
-    Read temperature register value - 680
-
-    Temperature read from the temperature sensor
-     target address - 0x48 is 42 degree centigrade
-    Read temperature register value - 616
-
-    Temperature read from the temperature sensor
-     target address - 0x49 is 38 degree centigrade
-    Temperature sensor test Passed!
-
-
-
-
-    Iteration : 1 Temperature Sensor Test Passed
-
-    Running Temperature Sensor Test...
-    Running temperature sensor test...
-    Read temperature register value - 680
-
-    Temperature read from the temperature sensor
-     target address - 0x48 is 42 degree centigrade
-    Read temperature register value - 616
-
-    Temperature read from the temperature sensor
-     target address - 0x49 is 38 degree centigrade
-    Temperature sensor test Passed!
-
-
-
-
-    Iteration : 2 Temperature Sensor Test Passed
-
-    Running Temperature Sensor Test...
-    Running temperature sensor test...
-    Read temperature register value - 680
-
-    Temperature read from the temperature sensor
-     target address - 0x48 is 42 degree centigrade
-    Read temperature register value - 616
-
-    Temperature read from the temperature sensor
-     target address - 0x49 is 38 degree centigrade
-    Temperature sensor test Passed!
-
-
-
-
-    Iteration : 3 Temperature Sensor Test Passed
-
-    Running Temperature Sensor Test...
-    Running temperature sensor test...
-    Read temperature register value - 680
-
-    Temperature read from the temperature sensor
-     target address - 0x48 is 42 degree centigrade
-    Read temperature register value - 616
-
-    Temperature read from the temperature sensor
-     target address - 0x49 is 38 degree centigrade
-    Temperature sensor test Passed!
-
-
-
-
-    Iteration : 4 Temperature Sensor Test Passed
-
-    ...
-    ...
-    ...
-
-    Running Temperature Sensor Test...
-    Running temperature sensor test...
-    Read temperature register value - 680
-
-    Temperature read from the temperature sensor
-     target address - 0x48 is 42 degree centigrade
-    Read temperature register value - 616
-
-    Temperature read from the temperature sensor
-     target address - 0x49 is 38 degree centigrade
-    Temperature sensor test Passed!
-
-
-
-
-    Iteration : 99 Temperature Sensor Test Passed
-
-    Running Temperature Sensor Test...
-    Running temperature sensor test...
-    Read temperature register value - 680
-
-    Temperature read from the temperature sensor
-     target address - 0x48 is 42 degree centigrade
-    Read temperature register value - 616
-
-    Temperature read from the temperature sensor
-     target address - 0x49 is 38 degree centigrade
-    Temperature sensor test Passed!
-
-
-
-
-    Iteration : 100 Temperature Sensor Test Passed
-
-    Temperature Sensor Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-
-
-    Temperature Sensor Test Passed
-|
-
-USB Host Stress Test
-^^^^^^^^^^^^^^^^^^^^^
-This test verifies USB host mode operation of the HW platform under test.
-USB interface functions as USB mass storage host during the test.
-USB device connected to the board will be enumerated, a file will be created,
-written with test data and read back to verify the data.
-USB interface operates at high-speed (USB 2.0) during the test.
-Test is repeated for 100 iterations.
-
-Test Accessories
-"""""""""""""""""
-USB OTG pen drive or normal pen drive with OTG cable
-
-Test Setup
-"""""""""""
-Refer `USB Host Test Setup <index_board.html#id188>`_ section for more details
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘usbHostStress_TEST’
- - Test supports USB host port on CP board and SerDes board on AM65x IDK platform.
-   Choose the board under test in the serial console while running the test on am65xx_idk
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for USB host stress test on am65xx_evm is shown below
-
-::
-
-    *************************************************
-    *                  USB Host Test                *
-    *************************************************
-
-    USB Host MSC example!!
-
-
-
-    Running USB Host Test in Stress Mode for 100 Number of Times...
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 1 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 2 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 3 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 4 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 5 USB Host Test Passed
-
-    ...
-    ...
-    ...
-
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 99 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 100 USB Host Test Passed
-
-
-    USB Host Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-
-
-    USB Host test Passed
-
-|
-
-Sample log for USB host stress test on am65xx_idk board is shown below
-
-::
-
-    *************************************************
-    *                  USB Host Test                *
-    *************************************************
-
-    USB Host MSC example!!
-
-    Select the options below on which application has to be run
-
-    1.CP board
-    2.Serdes Board
-    1
-
-
-    Running USB Host Test in Stress Mode for 100 Number of Times...
-    Enter 'b' in Serial Console to Terminate the Test
-
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 1 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 2 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 3 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 4 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 5 USB Host Test Passed
-
-    ...
-    ...
-    ...
-
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 99 USB Host Test Passed
-    Creating a text file...
-    File already exist..!, deleting existing file and creating a new file
-
-    Successfully created text file!
-    Verifying data......
-    Data verified successfully
-
-
-
-
-    Iteration : 100 USB Host Test Passed
-
-
-    USB Host Stress Test Status
-    ===================================
-    Number of Times Executed - 100
-    Pass Count - 100
-    Fail Count - 0
-    Overall Status - PASS
-
-|
-
-MCAN Stress Test
-^^^^^^^^^^^^^^^^^
-Verifies MCAN ports on the HW platform with two MCAN ports connected with each other.
-10240 packets sent from one port and received on another port. Both the ports are verified for Tx and Rx.
-
-Test Accessories
-"""""""""""""""""
-MCAN port to port loopback cable
-
-Test Setup
-"""""""""""
-Refer `MCAN Test Setup <index_board.html#id96>`_ section for more details
-
-Test Execution
-"""""""""""""""
- - Select the menu option to run ‘mcanStress_TEST’
- - Verify the test log on serial console
-
-Test Log
-"""""""""""
-Sample log for MCAN stress test is shown below
-
-::
-
-    ***********************************************
-    *                MCAN Stress Test             *
-    ***********************************************
-    MCANSS Revision ID:
-    scheme:0x1
-    Business Unit:0x2
-    Module ID:0x8e0
-    RTL Revision:0x5
-    Major Revision:0x1
-    Custom Revision:0x0
-    Minor Revision:0x1
-    CAN-FD operation is enabled through E-Fuse.
-    Endianess Value:0x87654321
-    Successfully configured MCAN0
-    MCANSS Revision ID:
-    scheme:0x1
-    Business Unit:0x2
-    Module ID:0x8e0
-    RTL Revision:0x5
-    Major Revision:0x1
-    Custom Revision:0x0
-    Minor Revision:0x1
-    CAN-FD operation is enabled through E-Fuse.
-    Endianess Value:0x87654321
-    Successfully configured MCAN1
-
-
-    Transmitting Data on MCAN Port0 and Receiving on MCAN port 1
-
-    Sending Packet - 1
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x30
-
-    Message DataByte2:0xb9
-
-    Message DataByte3:0xd6
-
-    Message DataByte4:0xfb
-
-    Message DataByte5:0x4b
-
-    Message DataByte6:0x87
-
-    Message DataByte7:0x27
-
-    Message DataByte8:0x97
-
-    Message DataByte9:0x58
-
-    Message DataByte10:0x0
-
-    Message DataByte11:0xc0
-
-    Message DataByte12:0xd4
-
-    Message DataByte13:0xe
-
-    Message DataByte14:0x3
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x100008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x30
-
-    Message DataByte2:0xb9
-
-    Message DataByte3:0xd6
-
-    Message DataByte4:0xfb
-
-    Message DataByte5:0x4b
-
-    Message DataByte6:0x87
-
-    Message DataByte7:0x27
-
-    Message DataByte8:0x97
-
-    Message DataByte9:0x58
-
-    Message DataByte10:0x0
-
-    Message DataByte11:0xc0
-
-    Message DataByte12:0xd4
-
-    Message DataByte13:0xe
-
-    Message DataByte14:0x3
-
-    Received Packet - 1
-
-    ...
-    ...
-    ...
-
-    Sending Packet - 10240
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x59
-
-    Message DataByte2:0x2a
-
-    Message DataByte3:0x5b
-
-    Message DataByte4:0x4b
-
-    Message DataByte5:0x9e
-
-    Message DataByte6:0xd1
-
-    Message DataByte7:0x77
-
-    Message DataByte8:0x9d
-
-    Message DataByte9:0x46
-
-    Message DataByte10:0x6d
-
-    Message DataByte11:0x74
-
-    Message DataByte12:0xd7
-
-    Message DataByte13:0xc2
-
-    Message DataByte14:0x8d
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x59
-
-    Message DataByte2:0x2a
-
-    Message DataByte3:0x5b
-
-    Message DataByte4:0x4b
-
-    Message DataByte5:0x9e
-
-    Message DataByte6:0xd1
-
-    Message DataByte7:0x77
-
-    Message DataByte8:0x9d
-
-    Message DataByte9:0x46
-
-    Message DataByte10:0x6d
-
-    Message DataByte11:0x74
-
-    Message DataByte12:0xd7
-
-    Message DataByte13:0xc2
-
-    Message DataByte14:0x8d
-
-    Received Packet - 10240
-
-
-
-    Transmitting Data on MCAN Port1 and Receiving on MCAN port 0
-
-    Sending Packet - 1
-
-    Message successfully transferred with payload Bytes:0xf
-    Receiving data on port0
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0x1f
-
-    Message DataByte2:0x44
-
-    Message DataByte3:0x40
-
-    Message DataByte4:0x68
-
-    Message DataByte5:0x7a
-
-    Message DataByte6:0x5d
-
-    Message DataByte7:0xf5
-
-    Message DataByte8:0x3e
-
-    Message DataByte9:0xa5
-
-    Message DataByte10:0xb7
-
-    Message DataByte11:0xe3
-
-    Message DataByte12:0x36
-
-    Message DataByte13:0x3a
-
-    Message DataByte14:0x76
-
-    Received Packet - 1
-
-    ...
-    ...
-    ...
-
-    Sending Packet - 10240
-
-    Message successfully transferred with payload Bytes:0xf
-
-    Message ID:0x100000
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Store Tx Events:0x1
-
-    Message Marker:0xaa
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xbd
-
-    Message DataByte2:0x97
-
-    Message DataByte3:0xca
-
-    Message DataByte4:0x10
-
-    Message DataByte5:0xd5
-
-    Message DataByte6:0x2c
-
-    Message DataByte7:0x14
-
-    Message DataByte8:0x6e
-
-    Message DataByte9:0xcc
-
-    Message DataByte10:0x69
-
-    Message DataByte11:0x21
-
-    Message DataByte12:0xb8
-
-    Message DataByte13:0x94
-
-    Message DataByte14:0xf6
-    Receiving data on port0
-
-    Message successfully received with payload Bytes:0xf
-
-    Received last message with following details:
-    Message ID:0x110008
-
-    Message Remote Transmission Request:0x0
-
-    Message Extended Frame ID(0:11Bit ID/1:29bit ID):0x0
-
-    Message Error State Indicator(0:Error Active/1:Error Passive):0x0
-
-    Message TimeStamp:0x0
-
-    Message Data Length Code:0xf
-
-    Message BRS:0x1
-
-    Message CAN FD format:0x1
-
-    Message Filter Index:0x0
-
-    Message Accept Non-matching Frame:0x0
-
-    Message DataByte0:0xaa
-
-    Message DataByte1:0xbd
-
-    Message DataByte2:0x97
-
-    Message DataByte3:0xca
-
-    Message DataByte4:0x10
-
-    Message DataByte5:0xd5
-
-    Message DataByte6:0x2c
-
-    Message DataByte7:0x14
-
-    Message DataByte8:0x6e
-
-    Message DataByte9:0xcc
-
-    Message DataByte10:0x69
-
-    Message DataByte11:0x21
-
-    Message DataByte12:0xb8
-
-    Message DataByte13:0x94
-
-    Message DataByte14:0xf6
-
-    Received Packet - 10240
-
-
-     MCAN diagnostic test completed.
-    Finished running mcanStress_TEST, result passed!
-
-|
-
-UART Stress Test
-^^^^^^^^^^^^^^^^^
-This test verifies the UART serial port by sending 10MB of data to the serial console.
-Data is received by the teraterm script on host PC and looped back to the board. Data is
-recieved by the test running on the board and verified to confirm data match.
-
-.. note::
-   This test does not support SD boot execution and need to run from CCS over JTAG.
-   Automation script is provided for teraterm application but the test should
-   be functional with any utility that can receive the data over COM port and
-   send it back on the same COM port.
-
-Test Accessories
-"""""""""""""""""
- - UART serial cable.
- - JTAG connection (on board or external as supported)
-Different platforms may need different cable for accessing the serial port. Refer to HW manual
-for more details.
-
-Test Setup
-"""""""""""
- - Connect the UART serial cable between the board UART port and host PC
- - Connect the JTAG port of the board to host PC
- - Setup serial console application on host PC with below configurations
- ::
-
-    Baud rate    -    115200
-    Data length  -    8 bit
-    Parity       -    None
-    Stop bits    -    1
-    Flow control -    None
-
- - Four UART ports are verified on am65xx_evm platform and three UART ports are verified on am65xx_idk platform.
-   Need to make above setup on all serial consoles connected to multiple ports on these platforms.
-
-Test Execution
-"""""""""""""""
- - Power ON the board and clear any data on the serial consoles
- - Run the TTL script from all the Teraterm consoles by selecting menu 'Control->Macro' and select the script file "am65xx_uart_stress_test_script.ttl"
- - Open CCS, launch the target config file for the platform under test and connect to the target
- - Load and run the UART diagnostic stress test binary (uartStress_diagExample_<BOARD>_<TARGET>.x<CORE>fg) on the <CORE> being used for the test.
- - Test script shall start displaying the messages on Teraterm consoles.
- - Test shall take few hours to complete and displays final result on the console.
-
-Test Log
-"""""""""""
-Sample UART stress test log is shown below
-
-::
-
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-
-    ....
-    ....
-    ....
-
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:
-
-    UART Stress Test Passed
-|
-
-RS485 UART Stress Test
-^^^^^^^^^^^^^^^^^^^^^^^
-This test verifies the RS485 UART serial port by sending 10MB of data to the serial console.
-Data is received by the teraterm script on host PC and looped back to the board. Data is
-recieved by the test running on the board and verified to confirm data match.
-
-.. note::
-   This test does not support SD boot execution and need to run from CCS over JTAG.
-   Automation script is provided for teraterm application but the test should
-   be functional with any utility that can receive the data over COM port and
-   send it back on the same COM port.
-
-Test Accessories
-"""""""""""""""""
- - UART serial cable.
-   RS485 to RS232 USB cable is used on AM65x IDK platform to run the test.
- - JTAG connection (on board or external as supported)
-Different platforms may need different cable for accessing the serial port. Refer to HW manual
-for more details.
-
-Test Setup
-"""""""""""
- - Connect the UART serial cable between the board RS485 UART port and host PC
- - Connect the JTAG port of the board to host PC
- - Setup serial console application on host PC with below configurations
- ::
-
-    Baud rate    -    115200
-    Data length  -    8 bit
-    Parity       -    None
-    Stop bits    -    1
-    Flow control -    None
-
-Test Execution
-"""""""""""""""
- - Power ON the board and clear any data on the serial console
- - Run the TTL script from the Teraterm console by selecting menu 'Control->Macro' and select the script file "am65xx_uart_stress_test_script.ttl"
- - Open CCS, launch the target config file for the platform under test and connect to the target
- - Load and run the UART diagnostic stress test binary (rs485_uartStress_diagExample_<BOARD>_<TARGET>.x<CORE>fg) on the <CORE> being used for the test.
- - Test script shall start displaying the messages on Teraterm console.
- - Test shall take few hours to complete and displays final result on the console.
-
-Test Log
-"""""""""""
-Sample RS485 UART stress test log is shown below
-
-::
-
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-
-    ....
-    ....
-    ....
-
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
-    0123456789:
-
-    PRU-ICSS UART Stress Test Passed
-|
-
-Power On Self Test (POST)
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-This test runs automatically when diagnostic tests are booted.
-Verifies the basic memories on the board and displays the test results.
-It also displays the board ID content programmed onto the Board ID EEPROM.
-After the diag boot, POST waits for 5 secs during which entering character 'b'
-in the serial console skips the POST execution.
-After the POST is executed, default diagnostic menu shall be displayed.
-
-Test Accessories
-"""""""""""""""""
-No additional accessories are required for running this test.
-
-Test Setup
-"""""""""""
-No specific test setup is needed. Use the default HW setup recommended in HW user manual.
-
-Test Execution
-"""""""""""""""
-Test runs automatically. No execution steps needed.
-
-Test Log
-"""""""""""
-Sample log for LED stress test is shown below
-
-::
-
-	DIAGNOSTIC TEST FRAMEWORK
-	Version - 01.00.00.01
-	Build Date - Apr  6 2019, Time - 03:47:24
-
-
-	Command options:
-		help - displays this help menu again
-		run - run a diagnostic application
-		status - prints the test status
-
-
-	Running Power On Self Tests...
-	Press 'b' to Skip the Test
-	Parsing bootEepromCompliance_TEST
-	Running bootEepromCompliance_TEST
-
-	*********************************************
-	*              Boot EEPROM Test                  *
-	*********************************************
-
-	Running Boot EEPROM test
-
-	Detecting the Boot EEPROM device...
-
-	Boot EEPROM device detection successful
-
-	Boot EEPROM boundary verification test...
-
-	Verifying the Boot EEPROM first page...
-
-	Verifying the Boot EEPROM last page...
-
-	Boot EEPROM boundary verification test successful
-
-	Boot EEPROM test Passed
-
-	Finished running bootEepromCompliance_TEST, result passed!
-	Parsing memCompliance_TEST
-	Running memCompliance_TEST
-
-	*********************************************
-	*              DDR Memory Test              *
-	*********************************************
-
-	Testing writing and reading memory
-	board_external_memory_test: Start address (0x80000000),            end address (0xffffffff)
-	Address Bus Test Started
-	Writing to test area...
-		Writing Memory 0x80000000
-		Writing Memory 0x80000004
-		Writing Memory 0x80000008
-		Writing Memory 0x80000010
-		Writing Memory 0x80000020
-		Writing Memory 0x80000040
-		Writing Memory 0x80000080
-		Writing Memory 0x80000100
-		Writing Memory 0x80000200
-		Writing Memory 0x80000400
-		Writing Memory 0x80000800
-		Writing Memory 0x80001000
-		Writing Memory 0x80002000
-		Writing Memory 0x80004000
-		Writing Memory 0x80008000
-		Writing Memory 0x80010000
-		Writing Memory 0x80020000
-		Writing Memory 0x80040000
-		Writing Memory 0x80080000
-		Writing Memory 0x80100000
-		Writing Memory 0x80200000
-		Writing Memory 0x80400000
-		Writing Memory 0x80800000
-		Writing Memory 0x81000000
-		Writing Memory 0x82000000
-		Writing Memory 0x84000000
-		Writing Memory 0x88000000
-		Writing Memory 0x90000000
-		Writing Memory 0xa0000000
-		Writing Memory 0xc0000000
-	Write finished!
-	Checking values...
-		Reading Memory 0x80000000
-		Reading Memory 0x80000004
-		Reading Memory 0x80000008
-		Reading Memory 0x80000010
-		Reading Memory 0x80000020
-		Reading Memory 0x80000040
-		Reading Memory 0x80000080
-		Reading Memory 0x80000100
-		Reading Memory 0x80000200
-		Reading Memory 0x80000400
-		Reading Memory 0x80000800
-		Reading Memory 0x80001000
-		Reading Memory 0x80002000
-		Reading Memory 0x80004000
-		Reading Memory 0x80008000
-		Reading Memory 0x80010000
-		Reading Memory 0x80020000
-		Reading Memory 0x80040000
-		Reading Memory 0x80080000
-		Reading Memory 0x80100000
-		Reading Memory 0x80200000
-		Reading Memory 0x80400000
-		Reading Memory 0x80800000
-		Reading Memory 0x81000000
-		Reading Memory 0x82000000
-		Reading Memory 0x84000000
-		Reading Memory 0x88000000
-		Reading Memory 0x90000000
-		Reading Memory 0xa0000000
-		Reading Memory 0xc0000000
-	Board memory test passed!
-	Memory test passed!
-
-	Finished running memCompliance_TEST, result passed!
-	Parsing emmcCompliance_TEST
-	Running emmcCompliance_TEST
-
-	*********************************************
-	*                 eMMC Test                 *
-	*********************************************
-
-	PASS: Read/Write Success for this block-0x300000
-
-	PASS: Read/Write Success for this pattern
-
-	Finished running emmcCompliance_TEST, result passed!
-	Parsing norflashCompliance_TEST
-	Running norflashCompliance_TEST
-
-	***************************************
-	*            SPI FlASH Test           *
-	***************************************
-	Reading Flash Device ID...
-	Device ID 0 - 0x20
-	Device ID 1 - 0xba
-	Device ID 2 - 0x18
-	Flash Device ID Match!
-
-	Flash Device ID Read Passed!
-
-	Verifying Sector - 0
-	Data Read matches with Data written
-	SPI Flash Test Passed!
-
-	SPI NOR Flash Test Passed
-
-	Finished running norflashCompliance_TEST, result passed!
-	Parsing ospiCompliance_TEST
-	Running ospiCompliance_TEST
-
-	*********************************************
-	*            OSPI FLASH Test                *
-	*********************************************
-
-	OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x2c
-
-	 Verifying the OSPI Flash first page...
-	OSPI NOR Flash first page verification Successful
-
-	OSPI NOR Flash verification Successful
-
-	OSPI Flash Test Passed!
-
-	Finished running ospiCompliance_TEST, result passed!
-	Parsing ledCompliance_TEST
-	Running ledCompliance_TEST
-
-	*********************************************
-	*                 LED Test                  *
-	*********************************************
-
-	Testing LED
-	Blinking LEDs...
-	Received: y
-
-	Test PASSED!
-
-	LED Test Passed
-
-	Finished running ledCompliance_TEST, result passed!
-	Parsing bootSwitchCompliance_TEST
-	Running bootSwitchCompliance_TEST
-
-	*********************************************
-	*             Boot Switch Test              *
-	*********************************************
-	Boot Switch SW3 Value - OFF ON ON OFF OFF OFF OFF OFF OFF OFF
-	Boot Switch SW2 Value - OFF OFF ON OFF OFF OFF OFF OFF OFF
-	Boot Switch SW4 Value - OFF OFF
-
-	Test Passed
-
-	Finished running bootSwitchCompliance_TEST, result passed!
-	Parsing eepromCompliance_TEST
-	Running eepromCompliance_TEST
-
-	*********************************************
-	*              EEPROM Test                  *
-	*********************************************
-
-	CP Board:
-	Displaying Header Fields
-	========================
-		Header ID: 0xee3355aa
-
-	Displaying Board Info Fields
-	============================
-		Board Name: AM6-COMPROCEVM
-		Design Revision: E3
-		PROC Number: 0062
-		Variant: 03
-	PCB Revision: E3
-	Schematic and BOM Revision: E3
-	Software Revision: 01
-	Vendor ID: 01
-	Build Week: 30
-	Build Year: 18
-	Board ID: 4P0081
-	Serial Number: 0017
-	Displaying DDR Fields
-	=====================	DDR Control Word: 5850
-
-	Displaying MAC Info Fields
-	==========================
-		MAC Control Word: 08
-		MAC ADDR0: 70-ff-76-1d-4c-40
-		MAC ADDR1: 70-ff-76-1d-4c-41
-	Test Passed
-	Finished running eepromCompliance_TEST, result passed!
-
-
-	Power On Self Test Result
-	All Tests Passed
-
-|
-
-Compliance Tests
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-Diagnostic tests include support for CE compliance verication for some of the
-platforms. Compliance tests can be executed by selecting the menu option '0'
-from the diagnostic test menu. These tests are intended for use by board vendor.
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_POST.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_POST.rst
deleted file mode 100644
index 15e2ff7c8..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_POST.rst
+++ /dev/null
@@ -1,100 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_POST
-
-.. rubric:: Overview
-   :name: overview-1
-
-The Power-On Self Test (POST) boot is designed to execute a series of
-platform/EVM factory tests on reset and indicate a PASS/FAIL condition
-using the LEDs and write test result to UART. A PASS result indicates
-that the EVM can be booted. POST is supported on K2H/K2E/K2L/C66x
-devices, this functionality is provided on other devices (e.g., AM57x)
-by `Diagnostics <index_board.html#diagnostics>`__.
-
-POST will perform the following functional tests:
-
--  External memory read/write test
--  NAND read test
--  NOR read test
--  EEPROM read test
--  UART write test
--  LED test
-
-Additionally, POST provides the following useful information:
-
--  FPGA version
--  Board serial number
--  EFUSE MAC ID
--  Indication of whether SA is available on SOC
--  PLL Reset Type status register
-
-|
-
-.. rubric:: Compilation
-   :name: compilation
-
-The recommended rule-of-thumb to compiling projects in the Processor SDK
-RTOS package is to use the makefiles provided. The makefiles are usable
-after setting up your shell/terminal/command prompt environment with the
-setupenv.bat or setupenv.sh script located in
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_<platform>_<version>
-
-Refer to `Processor SDK RTOS Building the SDK <index_overview.html#building-the-sdk>`__
-guide on how to setup your environment for building within any of the
-Processor SDK RTOS packages.
-
-To compile the POST application:
-
-::
-
-     cd [SDK Install Path]/pdk_<platform>_<version>/packages/ti/boot/post/<platform>/build
-     make all
-
-This will create the .out executable that can be loaded via CCS
-
-|
-
-.. rubric:: Flashing POST Image
-   :name: flashing-post-image
-
-To flash a bootable image of POST, please refer to the `SDK RTOS
-Flashing Bootable Images <index_how_to_guides.html#flash-bootable-images-c66x-k2h-k2e-k2l-only>`__ guide.
-
-|
-
-.. rubric:: C66x LED Code
-   :name: c66x-led-code
-
-For C66x, the on-board LEDs can also provide diagnostic information on
-POST routines. Refer to the following table:
-
-+-----------------------------+-------+-------+-------+-------+
-| Test Result                 | LED1  | LED2  | LED3  | LED4  |
-+=============================+=======+=======+=======+=======+
-| Test in progress            | on    | on    | on    | on    |
-+-----------------------------+-------+-------+-------+-------+
-| All tests passed            | off   | off   | off   | off   |
-+-----------------------------+-------+-------+-------+-------+
-| External memory test failed | blink | off   | off   | off   |
-+-----------------------------+-------+-------+-------+-------+
-| I2C EEPROM read failed      | off   | blink | off   | off   |
-+-----------------------------+-------+-------+-------+-------+
-| EMIF16 NAND read failed     | off   | off   | blink | off   |
-+-----------------------------+-------+-------+-------+-------+
-| SPI NOR read failed         | off   | off   | off   | blink |
-+-----------------------------+-------+-------+-------+-------+
-| UART write failed           | blink | blink | off   | off   |
-+-----------------------------+-------+-------+-------+-------+
-| PLL initialization failed   | off   | off   | blink | blink |
-+-----------------------------+-------+-------+-------+-------+
-| NAND initialization failed  | blink | blink | blink | off   |
-+-----------------------------+-------+-------+-------+-------+
-| NOR initialization failed   | off   | blink | blink | blink |
-+-----------------------------+-------+-------+-------+-------+
-| EMAC loopback failed        | on    | blink | blink | blink |
-+-----------------------------+-------+-------+-------+-------+
-| Other failures              | blink | blink | blink | blink |
-+-----------------------------+-------+-------+-------+-------+
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_UART_Apploader.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_UART_Apploader.rst
deleted file mode 100644
index 1b55c38d8..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_UART_Apploader.rst
+++ /dev/null
@@ -1,186 +0,0 @@
-
-Overview
---------
-
-UART AppLoader is a standalone application used to download application image over UART
-from the host PC. Host PC uses the serial console utility to transfer application image to apploader.
-
-The Apploader application loads and executes the application binary to be tested,
-over UART on the target platform.
-
-Supported Platforms
--------------------
-
-+----------------+------------------+-----------------------+
-|      SOC       |      PLATFORM    |   Verified Boot Modes |
-+================+==================+=======================+
-| AM335x         | AM335x GP EVM    |       MMCSD           |
-|                +------------------+-----------------------+
-|                | AM335x ICEv2     |       MMCSD           |
-|                +------------------+-----------------------+
-|                | AMIC110 ICE      |       SPI             |
-+----------------+------------------+-----------------------+
-| AM437x         | AM437x EVM       |       MMCSD           |
-|                +------------------+-----------------------+
-|                | AM437x IDK       |       MMCSD           |
-+----------------+------------------+-----------------------+
-| AM571x         | AM571x IDK       |       MMCSD           |
-+----------------+------------------+-----------------------+
-| AM572x         | AM572x EVM       |       MMCSD           |
-+                +------------------+-----------------------+
-|                | AM572x IDK       |       MMCSD           |
-+----------------+------------------+-----------------------+
-| AM574x         | AM574x IDK       |       MMCSD           |
-+----------------+------------------+-----------------------+
-| K2G            | K2G GP EVM       |       MMCSD           |
-|                +------------------+-----------------------+
-|                | K2G ICE          |       MMCSD           |
-+----------------+------------------+-----------------------+
-| OMAPL137       | OMAPL137 EVM     |       SPI             |
-+----------------+------------------+-----------------------+
-| OMAPL138       | OMAPL138 LCDK    |       MMCSD           |
-+----------------+------------------+-----------------------+
-
-Apploader Load Address
-----------------------
-
-+----------------+------------------+------------------+-----------------------+--------------------------+
-|      SOC       |     PLATFORM     |      DDR Size    |   DDR Start Address   |  Apploader Load Address  |
-+================+==================+==================+=======================+==========================+
-| AM335x         | AM335x GP EVM    |       1GB        |       0x80010000      |         0xBFE00000       |
-|                +------------------+------------------+-----------------------+--------------------------+
-|                | AM335x ICEv2     |      256MB       |       0x80010000      |         0x8FD00000       |
-|                +------------------+------------------+-----------------------+--------------------------+
-|                | AMIC110 ICE      |      512MB       |       0x80010000      |         0x9FE00000       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-| AM437x         | AM437x EVM       |       2GB        |       0x80000000      |         0xFFE00000       |
-|                +------------------+------------------+-----------------------+--------------------------+
-|                | AM437x IDK       |       1GB        |       0x80000000      |         0xBFE00000       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-| AM571x         | AM571x IDK       |       1GB        |       0x80000000      |         0xBFDFFFFF       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-| AM572x         | AM572x EVM       |       2GB        |       0x80000000      |         0xFFDFFFFF       |
-+                +------------------+------------------+-----------------------+--------------------------+
-|                | AM572x IDK       |       2GB        |       0x80000000      |         0xFFDFFFFF       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-| AM574x         | AM574x IDK       |       2GB        |       0x80000000      |         0xFFDFFFFF       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-| K2G            | K2G GP EVM       |       2GB        |       0x80000000      |         0xFFD00000       |
-|                +------------------+------------------+-----------------------+--------------------------+
-|                | K2G ICE          |      512MB       |       0x80000000      |         0x9FE00000       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-| OMAPL137       | OMAPL137 EVM     |      64MB        |       0xC3000000      |         0xC6E00000       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-| OMAPL138       | OMAPL138 LCDK    |      128MB       |       0xC0000000      |         0xC7E00000       |
-+----------------+------------------+------------------+-----------------------+--------------------------+
-
-Pre-Requisites
---------------
-1. Download and install the Processor-SDK RTOS package. See the software product page for your device to get the latest version of this software:
-
--  `Processor SDK for
-   AM335x <http://www.ti.com/tool/processor-sdk-am335x>`__
--  `Processor SDK for
-   AM437x <http://www.ti.com/tool/processor-sdk-am437x>`__
--  `Processor SDK for
-   AM57xx <http://www.ti.com/tool/processor-sdk-am57x>`__
--  `Processor SDK for
-   AMIC110 <http://www.ti.com/tool/PROCESSOR-SDK-AMIC110>`__
--  `Processor SDK RTOS for
-   C6747/OMAP-L17 <http://www.ti.com/tool/processor-sdk-omapl137>`__
--  `Processor SDK RTOS for
-   C6748/OMAP-L138 <http://www.ti.com/tool/processor-sdk-omapl138>`__
--  `Processor SDK RTOS for
-   K2G <http://www.ti.com/tool/PROCESSOR-SDK-K2G>`__
-
-   From the appropriate software product page, go to the download page by
-   clicking "Get Software" for the RTOS package.
-
-2. The Uart Apploader binaries are found under <pdk_install_path>/packages/ti/board/utils/uartAppLoader/bin/<board_name>/sd/apploader_Test
-
-**Serial Connection**
-
-Launch the serial console utility with the following configurations:
-
-
-* Baud Rate: 115200
-
-* Data : 8 bits
-
-* Parity : None
-
-* Stop : 1 bit
-
-* Flow Control : None
-
-.. note::   Any Serial Console utility that supports xmodem protocol can be used.
-            Verified utility is Teraterm
-
-.. note::	TI Binaries does not work with Apploader on AM335x/AM437x platforms.
-            Make sure to use non TI binaries for testing on these platforms.
-
-AppLoader Usage
----------------
-1. Set the sysboot pins to the relevant boot mode(SPI / MMCSD).
-2. Make sure UART connection is established between Target platform and Host PC.
-3. Power cycle the board.
-4. Check the below output on the serial console. The application starts sending character 'C'
-
-::
-
-        **** PDK SBL ****
-        SBL Revision: 01.00.09.00 (May 10 2018 - 15:48:57)
-        Begin parsing user application
-
-        SD Boot - file open completed successfully
-        Jumping to user application...
-        ********* PDK UART Apploader ********
-        version 0.1 (May 14 2018 - 21:40:11)
-
-        Please transfer file with XMODEM protocol...
-        CCCC
-
-.. note::  The above log is for reference purpose and content might change based on latest software available in processor SDK release
-
-5. Now transfer the application binary to be tested over UART using serial console utility.
-
-.. note::	For example in Teraterm, use the following option to transfer the application binary.
-			File -> Transfer -> XMODEM -> Send
-
-6. Upon success, the apploader loads and executes the application.
-7. Following is the sample output (using UART Diagnostic application), on the serial console.
-
-::
-
-        Xmodem received 46848 bytes
-
-        Copying application image from UART to RAM is done
-        Begin parsing user application
-        Jumping to user application...
-
-        *********************************************
-        *                 UART Test                 *
-        *********************************************
-
-        Testing UART print to console at 115.2k baud rate
-        Press 'y' to verify pass: y
-        Received: y
-
-        Test PASSED!
-
-.. note::	For SPI Boot Mode:
-			1. Program Apploader to SPI flash using `Uniflash <index_board.html#programming-binaries-to-flash-device>`__ and boot the device from SPI flash.
-			2. Set the sysboot pins to SPI Boot mode
-
-.. note::	For MMCSD Boot Mode:
-			1. Copy MLO to SD card.
-			2. Rename apploader_Test to app and copy to SD card.
-			3. Set the sysboot pins to MMCSD Boot mode
-
-Rebuilding AppLoader
----------------------
-Apploader pre-built binaries are currently not available for OMAPL137/L138 platforms.
-Binaries needs to be manually built for these platforms.
-
-Refer `Rebuilding Board Utils <index_board.html#rebuilding-board-utils>`__ section to build Apploader.
-
diff --git a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Uniflash.rst b/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Uniflash.rst
deleted file mode 100644
index 20b56e1f9..000000000
--- a/source/rtos/PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Uniflash.rst
+++ /dev/null
@@ -1,608 +0,0 @@
-
-Introduction
-^^^^^^^^^^^^^^
-Uniflash is an Unified Flashing tool which provides utilities for flashing the application software
-images to non-removable flash devices on TI hardware platforms.
-
-Uniflash for TI processors platform includes two components
-
- - Flash Programmer
- - Host utility
-
-Flash porgrammer runs on target platform which takes care of receiving the images from Uniflash host
-utility and programming them onto flash devices. Flash programmer communicates with Uniflash host utility
-over the UART interface.
-
-Flash programmer which is part of the Uniflash release can be found at - "<Uniflash Root>/processors/FlashWriter/<Board Name>"
-
-Host utility runs on host machine which provides Command-line Interface (CLI) to communicate with flash programmer.
-Windows and Linux are the supported OS platforms for running Uniflash host utility. Host utility uses UART or JTAG
-interface to download the flash programmer to the target platform. All data transfers between
-Uniflash host utility and Flash programmer happens over UART interface.
-
-Refer to `Uniflash Documentation <http://processors.wiki.ti.com/index.php/Category:CCS_UniFlash>`__
-for more details on Uniflash tool.
-
-
-Supported Platforms
-^^^^^^^^^^^^^^^^^^^^
-Below table shows the platforms supported by Uniflash and flash devices supported on each platform.
-Download mode indicates the mode of communication for downloading flash programmer to target platform.
-
-+----------------+----------------+------------------+---------------+------+------+---------------------------+
-|      SOC       |    SOC Core    |    PLATFORM      |    FLASH DEVICE             |       DOWNLOAD MODE       |
-|                |                |                  +-------+-------+------+------+------+--------------------+
-|                |                |                  | SPI   | QSPI  | OSPI | EMMC | UART |       JTAG         |
-|                |                |                  |       |       |      |      |      +------------+-------+
-|                |                |                  |       |       |      |      |      |Uniflash CLI| Manual|
-+================+================+==================+=======+=======+======+======+======+============+=======+
-| AM335x         | Cortex-A8      | AM335x GP EVM    |   X   |       |      |      |   X  |     X      |       |
-|                |                +------------------+-------+-------+------+------+------+------------+-------+
-|                |                | AM335x ICEv2     |   X   |       |      |      |      |     X      |       |
-|                |                +------------------+-------+-------+------+------+------+------------+-------+
-|                |                | AMIC110 ICE      |   X   |       |      |      |   X  |     X      |       |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-| AM437x         | Cortex-A9      | AM437x IDK       |       |   X   |      |      |      |     X      |       |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-| AM571x         | Cortex-A15     | AM571x IDK       |       |   X   |      |      |      |     X      |       |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-| AM572x         | Cortex-A15     | AM572x IDK       |       |   X   |      |      |      |     X      |       |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-| AM574x         | Cortex-A15     | AM574x IDK       |       |   X   |      |      |      |     X      |       |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-| K2G            | Cortex-A15     | K2G GP EVM       |       |   X   |      |      |      |     X      |       |
-|                |                +------------------+-------+-------+------+------+------+------------+-------+
-|                |                | K2G ICE          |       |   X   |      |      |      |     X      |       |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-| AM65XX         | Cortex-R5      | AM65xx EVM       |       |       |   X  |   X  |   X  |            |   X   |
-|                |                +------------------+-------+-------+------+------+------+------------+-------+
-|                |                | AM65xx IDK       |       |       |   X  |   X  |   X  |            |   X   |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-| J721E          | Cortex-R5      | J721E EVM        |       |   X   |   X  |   X  |   X  |            |   X   |
-+----------------+----------------+------------------+-------+-------+------+------+------+------------+-------+
-
-
-where,
-
- - X  : Supported
-
-.. note:: For the platforms which support both UART and JTAG mode, UART is the recommended mode for
-          downloading flash programmer. JTAG mode is supported along with UART for debug purpose.
-
-
-Getting Started with Uniflash
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Downloads
-"""""""""""
-Latest version of Uniflash can be downloaded `here <http://www.ti.com/tool/download/UNIFLASH>`__
-
-
-Command Options
-""""""""""""""""
-Uniflash CLI supports set of commands and configuration flags which are provided through dslite script.
-Run the help command as described below to see all the options supported by Uniflash.
-
-For Windows
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # dslite.bat --mode processors -h
-
-
-
-For Linux
-
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # sudo ./dslite.sh --mode processors -h
-
-
-
-This will display help menu.
-Following is the sample output for help command.
-::
-
-    For more details and examples, please refer to the UniFlash Quick Start guide.
-
-
-        ----------------------------------------------------------------------------
-        ProcessorSDKSerialFlash CLI Tool
-        Copyright (C) 2017-2019 Texas Instruments Incorporated - http://www.ti.com/
-        Version 1.2.0.0
-        ----------------------------------------------------------------------------
-
-        Displaying Help..
-
-        Usage:
-        dslite.bat --mode processors -c <COM_Port> -f <Path_to_the_file_to_be_transfered> -d <Device_Type> -i <Image_Type> -e <erase_length> -o <Offset>
-
-        Device_Type:
-        0 - NAND
-        1 - SPI
-        2 - QSPI
-        3 - OSPI
-        4 - eMMC
-        5 - HyperFlash
-        6 - UFS
-
-        Image_Type:
-        0 - Flash
-        1 - MLO
-        2 - Uboot
-        3 - UImage
-        4 - Firmware
-        5 - Custom Image
-
-        erase_length:Length in Bytes
-
-        Note: File Path should not be specified for Flash Erase command
-
-
-.. note::
-
-           Offset option(-o) expects hexadecimal value by default.
-           The offset value can be provided with or without "0x"
-
-
-Uniflash Execution Steps
-"""""""""""""""""""""""""
-Uniflash provides two modes of communication for downloading the flash programmer - UART and JTAG.
-In JTAG mode Uniflash commnad-line interface is supported for most of the platforms.
-Manual loading of the flash programmer through CCS is required for few cases.
-Below diagram shows the execution steps for flashing the application images based on the Uniflash
-supported mode for downloading the flash programmer.
-
-.. Image:: /images/Uniflash_Execution_Steps.png
-    :width: 650px
-    :align: center
-    :height: 1000px
-
-Check the `Supported Platforms <index_board.html#supported-platforms>`__ for details of the mode of communication supported for
-downloading the flash programmer on each platform.
-
-
-Downloading Flash Programmer
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-UART Load
-"""""""""""
-Follow below steps for downloading the flash programer over UART
-
- - Confgure boot mode of the target platform to UART boot.
- - Connect UART serial port of the target platform to host PC
- - Power cycle the target platform
- - Open a serial console application (Minicom, TeraTerm etc) on host PC and configure it for 115200 baud 8n1.
- - Make a note of the COM port number on which character 'C' is getting printed. This COM port number shall be used
-   in all the command inputs to Uniflash host utility.
- - Close all the serial console applications on host PC.
- - If the host PC is running Windows OS, disconnect the serial console cable from the board and reconnet before proceeding to next steps.
- - Run below commands on the Host PC from Uniflash root folder
-
-For Windows
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # dslite.bat --mode processors -c <COM Port> -f <Flash Programmer Binary with Full Path> -i 0
-        Example:
-        # dslite.bat --mode processors -c COM10 -f <Uniflash Root>\processors\FlashWriter\am65xx_evm\uart_am65xx_evm_flash_programmer.tiimage -i 0
-
-
-For Linux
-
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # sudo ./dslite.sh --mode processors -c <COM Port> -f <Flash Programmer Binary with Full Path> -i 0
-        Example:
-        # sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f <Uniflash Root>/processors/FlashWriter/am65xx_evm/uart_am65xx_evm_flash_programmer.tiimage -i 0
-
-.. note:: Specifying the image type with -i option is mandatory while downloading the flash programmer.
-
-Uniflash CLI shows the progress of file transfer on the command console.
-Following is the sample output for downloading Flash programmer over UART.
-
-::
-
-        C:\ti\uniflash_5.2.0>dslite.bat --mode processors -c COM10 -f C:\ti\uniflash_5.2.0\processors\FlashWriter\am65xx_evm\uart_am65xx_evm_flash_programmer.tiimage -i 0
-        Executing the following command:
-        > C:\ti\uniflash_5.2.0\processors\ProcessorSDKSerialFlash.exe -c COM10 -f C:\ti\uniflash_5.2.0\processors\FlashWriter\am65xx_evm\uart_am65xx_evm_flash_programmer.tiimage -i 0
-
-        For more details and examples, please refer to the UniFlash Quick Start guide.
-
-
-        ----------------------------------------------------------------------------
-        ProcessorSDKSerialFlash CLI Tool
-        Copyright (C) 2017-2019 Texas Instruments Incorporated - http://www.ti.com/
-        Version 1.2.0.0
-        ----------------------------------------------------------------------------
-        Downloading Flash Programmer..
-
-        Enabling SysFw transfer!!!
-
-        Transferring File of size 182621 bytes
-        File Transfer complete!
-        Header Transfer complete
-        Transferring System Firmware..
-        Transferring File of size 263083 bytes
-        File Transfer complete!
-
-|
- - After successful download of the flash programmer, `Program the flash device <index_board.html#programming-the-flash-device>`__
-   or `Erase the flash device <index_board.html#erasing-the-flash-device>`__
-   by following the steps described in the corresponding secions.
-|
-
-JTAG Load
-"""""""""""""
-
-Uniflash CLI JTAG Load
-'''''''''''''''''''''''''
-Follow below steps for downloading the flash programer over JTAG using Uniflash CLI
-
- - Confgure boot mode of the target platform to 'No Boot' or 'JTAG mode'
- - Connect UART serial port of the target platform to host PC
- - Power cycle the target platform
- - Prepare the CCS target configuration file for the platform under test and JTAG emulator being used.
- - Connect the JTAG port of the board to host PC running CCS.
- - Run below commands on the Host PC from Uniflash root folder
-
-
-For Windows
-
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # dslite.bat --mode load --config=<CCS Target Config file (ccxml) with Full Path>
-        -f <Flash Programmer Binary with Full Path> -n <Core ID to be Connected to JTAG on the Target Platform>
-        Example:
-        # dslite.bat --mode load --config=C:\Users\username\ti\CCSTargetConfigurations\idkAM574x.ccxml -f C:\ti\uniflash_5.2.0\processors\FlashWriter\idkAM574x\uart_idkAM574x_flash_programmer.out -n 8
-
-
-
-For Linux
-
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # sudo ./dslite.sh --mode load --config=<CCS Target Config file (ccxml) with Full Path>
-        -f <Flash Programmer Binary with Full Path> -n <Core ID to be Connected to JTAG on the Target Platform>
-        Example:
-        # sudo ./dslite.sh --mode load --config=/home/ti/CCSTargetConfigurations/idkAM574x.ccxml -f /home/user/ti/uniflash_5.2.0/processors/FlashWriter/idkAM574x/uart_idkAM574x_flash_programmer.out -n 8
-
-
-
-Uniflash CLI shows the progress of file transfer on the command console.
-Following is the sample output on Windows.
-
-::
-
-        C:\ti\uniflash_5.2.0>dslite.bat --mode load --config=C:\Users\username\ti\CCSTargetConfigurations\idkAM574x.ccxml -f C:\ti\uniflash_5.2.0\processors\FlashWriter\idkAM574x\uart_idkAM574x_flash_programmer.out -n 8
-        Executing the following command:
-        > "C:\ti\uniflash_5.2.0\deskdb\content\TICloudAgent\win\ccs_base\DebugServer\bin\DSLite" load --config=C:\Users\username\ti\CCSTargetConfigurations\idkAM574x.ccxml -f .\processors\FlashWriter\idkAM574x\uart_idkAM574x_flash_programmer.out -n 8
-
-        For more details and examples, please refer to the UniFlash Quick Start guide.
-
-        DSLite version 9.2.0.1723
-        Configuring Debugger (may take a few minutes on first launch)...
-                Initializing Register Database...
-                Initializing: IcePick_D
-                Executing Startup Scripts: IcePick_D
-                Initializing: ARM9_ICONT1
-                Executing Startup Scripts: ARM9_ICONT1
-                Initializing: ARM9_ICONT2
-                Executing Startup Scripts: ARM9_ICONT2
-                Initializing: CS_DAP_IPU_1_C0
-                Executing Startup Scripts: CS_DAP_IPU_1_C0
-                Initializing: Cortex_M4_IPU1_C0
-                Executing Startup Scripts: Cortex_M4_IPU1_C0
-        GEL: Cortex_M4_IPU1_C0: GEL Output: --->>> AM574x Cortex M4 Startup Sequence In Progress... <<<---
-        GEL: Cortex_M4_IPU1_C0: GEL Output: --->>> AM574x Cortex M4 Startup Sequence DONE! <<<---
-        . . .
-        . . .
-        . . .
-        GEL: CortexA15_0: GEL Output: --->>> IVAHD Initialization is DONE! ... <<<---
-        GEL: CortexA15_0: GEL Output: --->>> PRUSS 1 and 2 Initialization is in progress ... <<<---
-        GEL: CortexA15_0: GEL Output: --->>> PRUSS 1 and 2 Initialization is in complete ... <<<---
-        Loading Program: .\processors\FlashWriter\idkAM574x\uart_idkAM574x_flash_programmer.out
-                Preparing ...
-                .text: 0 of 72000 at 0x40330074
-                .text: 32752 of 72000 at 0x40330074: 15%
-                .text: 65504 of 72000 at 0x40330074: 30%
-                Finished: 30%
-                Setting PC to entry point.: 30%
-        Running...
-        Success
-|
-
- - Open serial console application (Ex: Minicom, TeraTerm) on host PC and configure it for 115200 baud 8n1.
- - Make a note of the COM port number on which character 'C' is getting printed. This COM port number shall be used
-   in all the command inputs to Uniflash host utility.
- - Close all the serial console applications on host PC.
- - If the host PC is running Windows OS, disconnect the serial console cable from the board and reconnet before proceeding to next steps.
- - After successful download of the flash programmer, `Program the flash device <index_board.html#programming-the-flash-device>`__
-   or `Erase the flash device <index_board.html#erasing-the-flash-device>`__
-   by following the steps described in the corresponding secions.
-|
-
-Manual JTAG Load
-''''''''''''''''''
-Follow below steps for downloading the flash programer over JTAG manually
-
- - Confgure boot mode of the target platform to 'No Boot' or 'JTAG mode'
- - Connect UART serial port of the target platform to host PC
- - Setup the CCS target configuration file for the platform under test and JTAG emulator being used.
-
-.. note:: Refer the `Platform Specific Information <index_board.html#platform-specific-information>`__ for more details on
-          additional setup needed for CCS target configuration.
-
-
- - Connect the JTAG port of the board to host PC running CCS.
- - Power ON the board
- - Launch the target configuration file from CCS
- - Connect to the target SoC core on which flash programmer is supported.
- - Load and run the flash programmer binary
- - Open a serial console application (Minicom, TeraTerm etc) on host PC and configure it for 115200 baud 8n1.
- - Make a note of the COM port number on which character 'C' is getting printed. This COM port number shall be used
-   in all the command inputs to Uniflash host utility.
- - Close all the serial console applications on host PC.
- - If the host PC is running Windows OS, disconnect the serial console cable from the board and reconnet before proceeding to next steps.
- - After successful download of the flash programmer, `Program the flash device <index_board.html#programming-the-flash-device>`__
-   or `Erase the flash device <index_board.html#erasing-the-flash-device>`__
-   by following the steps described in the corresponding secions.
-
-
-
-Programming the Flash Device
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Download the flash programmer using the steps described in section `Downloading Flash Programmer <index_board.html#downloading-flash-programmer>`__
-before start programming application binaries to flash device.
-
-Once the Flash Programmer is loaded and executed, use the following commands to program binaries onto the Flash Device.
-
-For Windows
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # dslite.bat --mode processors -c <COM Port> -f <Path to the binary to be flashed> -d  <Flash Device Type> -o <offset>
-        Example:
-        # dslite.bat --mode processors -c COM10 -f C:\ti\pdk_am65xx_<ver>\packages\ti\boot\sbl\binary\am65xx_evm\ospi\bin\sbl_ospi_img_mcu1_0_release.tiimage -d 3 -o 0
-
-
-
-For Linux
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # sudo ./dslite.sh --mode processors -c <COM Port> -f <Path to the binary to be flashed> -d  <Flash Device Type> -o <offset>
-        Example:
-        # sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f /home/user/ti/pdk_am65xx_<ver>/packages/ti/boot/sbl/binary/am65xx_evm/ospi/bin/sbl_ospi_img_mcu1_0_release.tiimage -d 3 -o 0
-
-
-
-Refer to `Uniflash Command Options <index_board.html#command-options>`__ for more details on command parameters.
-
-Uniflash CLI shows the progress of file transfer on the command console.
-
-.. note::
-   Multiple images like bootloader, system firmware and application etc should be flashed to get the application
-   booting from the boot device. Refer to the `FAQ section <index_board.html#uniflash-faq>`__ for additional references.
-
-Following is the sample output for flashing RTOS application images on AM65xx platform.
-
-::
-
-        C:\ti\uniflash_5.2.0>dslite.bat --mode processors -c COM10 -f C:\ti\pdk_am65xx_1_0_6\packages\ti\boot\sbl\binary\am65xx_evm\ospi\bin\sbl_ospi_img_mcu1_0_release.tiimage -d 3 -o 0
-        Executing the following command:
-        > C:\ti\uniflash_5.2.0\processors\ProcessorSDKSerialFlash.exe -c COM10 -f C:\ti\pdk_am65xx_1_0_6\packages\ti\boot\sbl\binary\am65xx_evm\ospi\bin\sbl_ospi_img_mcu1_0_release.tiimage -d 3 -o 0
-
-        For more details and examples, please refer to the UniFlash Quick Start guide.
-
-
-        ----------------------------------------------------------------------------
-        ProcessorSDKSerialFlash CLI Tool
-        Copyright (C) 2017-2019 Texas Instruments Incorporated - http://www.ti.com/
-        Version 1.2.0.0
-        ----------------------------------------------------------------------------
-        Transferring the Image to Flash Programmer..
-
-        Transferring Header Information..
-        Header Transfer Complete!
-
-        Flashing Image of size 155614 bytes
-        Flash Programming Success!
-
-
-        C:\ti\uniflash_5.2.0\dslite --mode processors -c COM10 -f C:\ti\pdk_am65xx_1_0_6\packages\ti\drv\sciclient\soc\V0\sysfw.bin -d 3 -o 40000
-        Executing the following command:
-        > C:\ti\uniflash_5.2.0\processors\ProcessorSDKSerialFlash.exe -c COM10 -f C:\ti\pdk_am65xx_1_0_6\packages\ti\drv\sciclient\soc\V0\sysfw.bin -d 3 -o 40000
-
-        For more details and examples, please refer to the UniFlash Quick Start guide.
-
-
-        ----------------------------------------------------------------------------
-        ProcessorSDKSerialFlash CLI Tool
-        Copyright (C) 2017-2019 Texas Instruments Incorporated - http://www.ti.com/
-        Version 1.2.0.0
-        ----------------------------------------------------------------------------
-        Transferring the Image to Flash Programmer..
-
-        Transferring Header Information..
-        Header Transfer Complete!
-
-        Flashing Image of size 263083 bytes
-        Flash Programming Success!
-
-
-        C:\ti\uniflash_5.2.0\dslite --mode processors -c COM10 -f C:\ti\pdk_am65xx_1_0_6\packages\ti\board\bin\am65xx_evm\sd\armv8\led_TEST -d 3 -o A0000
-        > C:\ti\uniflash_5.2.0\processors\ProcessorSDKSerialFlash.exe -c COM10 -f C:\ti\pdk_am65xx_1_0_6\packages\ti\board\bin\am65xx_evm\sd\armv8\led_TEST -d 3 -o A0000
-
-        For more details and examples, please refer to the UniFlash Quick Start guide.
-
-
-        ----------------------------------------------------------------------------
-        ProcessorSDKSerialFlash CLI Tool
-        Copyright (C) 2017-2019 Texas Instruments Incorporated - http://www.ti.com/
-        Version 1.2.0.0
-        ----------------------------------------------------------------------------
-        Transferring the Image to Flash Programmer..
-
-        Transferring Header Information..
-        Header Transfer Complete!
-
-        Flashing Image of size 72360 bytes
-        Flash Programming Success!
-
-
-
-Erasing the Flash Device
-^^^^^^^^^^^^^^^^^^^^^^^^^
-Download the flash programmer using the steps described in section `Downloading Flash Programmer <index_board.html#downloading-flash-programmer>`__
-before start executing erase command.
-
-Once the Flash programmer is loaded and executed, use the following commands to erase the Flash Device on the target platform
-
-For Windows
-
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # dslite.bat --mode processors -c <COM Port> -e <Erase Length in Bytes> -d <Flash Device Type> -o <Erase Offset>
-        Example:
-        # dslite.bat --mode processors -c COM10 -e 10000 -d 3 -o 20000
-
-
-For Linux
-
-::
-
-        # cd <Path to Uniflash Root Folder>
-        # sudo ./dslite.sh --mode processors -c <COM Port> -e <Erase Length in Bytes> -d <Device Type> -o <Erase Offset>
-        Example:
-        # sudo ./dslite.sh  --mode processors -c /dev/ttyUSB1 -e 10000 -d 3 -o 20000
-
-
-The application will output the status to the console on the Host PC.
-Following is the sample output on Windows.
-
-::
-
-        C:\ti\uniflash_5.2.0>dslite.bat --mode processors -c COM10 -e 10000 -d 3 -o 0
-        Executing the following command:
-        > C:\ti\uniflash_5.2.0\processors\ProcessorSDKSerialFlash.exe -c COM10 -e 10000 -d 3 -o 0
-
-        For more details and examples, please refer to the UniFlash Quick Start guide.
-
-
-        ----------------------------------------------------------------------------
-        ProcessorSDKSerialFlash CLI Tool
-        Copyright (C) 2017-2019 Texas Instruments Incorporated - http://www.ti.com/
-        Version 1.2.0.0
-        ----------------------------------------------------------------------------
-        Erasing Flash....
-
-        Transferring Header information..
-        Header Transfer Complete!!
-        Flash Erase Success!
-
-
-Platform Specific Information
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-AM335x
-""""""""
- - Make sure the Profile Selection switch on AM335x GP EVM is set to Profile#2 while programming SPI flash
-
-AM65xx/J721E
-"""""""""""""
-
-- Flash programmer requires system firmware while downloading the flash
-  programmer through UART on AM65xx and J721E platforms. Uniflash host CLI loads
-  the system firmware automatically while loading the flash programmer on these
-  platforms. Flash programmer and system firmware binary (sysfw.bin) should be
-  kept in the same folder for succesful downloading of flash programmer and
-  system firmware.
-
-- System firmware should be loaded through CCS script while loading the flash
-  programmer through JTAG. Refer the EVM CCS Setup Documentation section below
-  for details of setting up the CCS target configuration with system firmware
-  download.
-
-   - `AM65xx
-     <index_how_to_guides.html#advanced-am65x-debug-setup-with-dmsc-firmware-load>`__
-
-   - `J721E
-     <http://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/psdk_rtos_auto/docs/user_guide/ccs_setup_j721e.html>`__
-
-J721E
-""""""
-
-- Set the dip switch SW3.1 on CP board to OFF while running the flash programmer
-  for OSPI flashing on J721E EVM
-
-Uniflash FAQ
-^^^^^^^^^^^^^
-
-- How do I confirm my HW setup is proper for image download over UART? Board
-  should be configured for UART boot mode for downloading the images over UART.
-  RoM bootloader sends a character 'C' at regular intervals on serial port in
-  UART boot mode. Connect a serial console application on host PC to the UART
-  port used for booting and veirfy the character 'C' is getting displayed, which
-  confirms the HW setup needed for image download over UART is proper.
-
-- How do I verify which COM number to be used for Uniflash image download? There
-  may be multiple UART ports supported on the board but Uniflash image download
-  happens on one specific UART port which is meant for UART boot. RoM bootloader
-  and Uniflash flash programmer sends a character 'C' at regular intervals on
-  the UART port used for image download. COM port number to be used for image
-  download can be identified by checking for the character 'C' displayed on host
-  PC.
-
-- I am running Uniflash on Windows host and Uniflash CLI is not able to open COM
-  port. What could be the reason? Some of the serial console application like
-  TeraTerm on Windows changes the COM port settings which causes the COM port
-  open failure from Uniflash. Disconnect the UART cable and reconnet before
-  running the Uniflash commands everytime a serial console application is used
-  to access the COM port on Windows.
-
-- Should the flash device be erased using Uniflash erase command before flashing
-  the images? No, Uniflash Erase command is provided to explicity erase the
-  images on the flash device. Uniflash flash programmer erases the flash by
-  default before flashing the images.
-
-- What all the images that need to be flashed to get my application boot? It
-  depends on the SoC flamily and OS being used by the application. In general, a
-  secondary bootloader, any configuration files needed for system configuration
-  and an application image are the minimum images that need to be flashed for
-  booting to happen. Refer below documentation for more details
-
-   * `RTOS <index_Foundational_Components.html#boot>`__
-
-   * `Linux
-     <http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_U-Boot.html#u-boot>`__
-
-Rebuilding Board-utils
-^^^^^^^^^^^^^^^^^^^^^^
-- Use the following commands to rebuild Uniflash and Apploader supported as part of board utils
-
-- For Windows
-
-::
-
-        # cd <pdk_install_path>/packages
-        # pdksetupenv.bat
-        # cd ti\board\utils
-        # gmake clean
-        # gmake
-
-- For Linux
-
-::
-
-        # cd <pdk_install_path>/packages
-        # ./pdksetupenv.sh
-        # cd ti/board/utils
-        # make clean
-        # make
-
-- Uniflash binaries will be created under the folder <pdk_install_path>/packages/ti/board/utils/uniflash/bin/<board_name>/
-- Apploader binaries will be created under the folder <pdk_install_path>/packages/ti/board/utils/uartAppLoader/bin/<board_name>/
diff --git a/source/rtos/PDK_Platform_Software/Device_Driver_Utilities/_OSAL.rst b/source/rtos/PDK_Platform_Software/Device_Driver_Utilities/_OSAL.rst
deleted file mode 100644
index e2a82ed2a..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Driver_Utilities/_OSAL.rst
+++ /dev/null
@@ -1,271 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_OSAL
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The OSAL library provides operating system abstraction layer API sample
-implementations that are required for processor SDK drivers. Scope of
-APIs supported in the module is limited to support OS services required
-for RTOS or bare metal drivers
-
--  Supported Operating Systems
-
-   -  TIRTOS
-   -  NONOS
-
--  Supported SOCs
-
-   -  Please refer to component release notes
-
-Operating System Extension
---------------------------
-
-APIs
-^^^^
-
-Porting of OSAL component will enable extending PDK components to
-additional OS environment. Reference top level API header file 
-includes:
-
-::
-
-    #include <ti/osal/osal.h>
-
-Application Integration Details
--------------------------------
-
-**Baremetal or No-OS Use case**
-
-Reference library path to be included in application build environment:
-
-::
-
-     <ti/osal/lib/nonos/[soc]/[[cpu]/>
-
-
-**SysBIOS based application**
-
-Any RTSC application that needs to use osal library, should have below
-RTSC configuration lines before any other processor sdk components
-(e.g., board, gpio, uart etc).
-
-::
-
-
-     /* set the operating system type,
-      * supported types are "tirtos" and "nonos"
-      */
-     var osType           = "tirtos";
-
-     /* set the soc type
-      * (applicable only when osTYpe
-      *  is "nonos" only)
-     */
-     var socType           = "am572x";
-
-     /* Setup the OSAL Library */
-     var Osal = xdc.loadPackage('ti.osal');
-     Osal.Settings.osType  = osType;
-     Osal.Settings.socType = socType;
-
-
-
-|
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-.. rubric:: Sysbios Example
-   :name: sysbios-example
-
-This sysbios example OSAL_BasicExample_<board>_<coretype>TestProject
-tests Hwi, Timer, Delay, Semaphores etc and prints output on UART
-console.
-
-.. rubric:: Introduction
-   :name: introduction
-
-This sysbios based example tests Hwi, Timer, Semaphores etc.
-
-.. rubric:: Supported platforms
-   :name: supported-platforms
-
-::
-
-    evmAM335x
-    evmAM437x
-    idkAM571x
-    idkAM574x
-    evmAM572x
-    evmK2G
-    evmK2H
-    evmOMAPL137
-    lcdkOMAPL138
-    am65xx_evm
-    am65xx_idk
-    j721e_evm
-
-.. rubric:: Build instructions
-   :name: build-instructions
-
-::
-
-    Run pdkProjectCreate to create the OSAL_BasicExample_<evm>_<device>TestProject
-    Load the project on to CCS and build the same.
-    Build the example
-    Load the OSAL_BasicExample_<evm>_<device>TestProject
-    Run the example
-
-.. rubric:: Testing the example
-   :name: testing-the-example
-
-The output for each of the tests (Hwi, Timer, Delay, Semaphores etc) can
-be seen on the UART console. After a successful run, "All tests have
-PASSED" will be displayed on the screen.
-
-.. rubric:: Baremetal Example
-   :name: baremetal-example
-
-.. rubric:: Introduction
-   :name: introduction-1
-
-This baremetal example 'osal_baremetal_test' tests Hwi, Timer,
-Semaphores etc and prints output on UART console.
-
-.. rubric:: Supported platforms
-   :name: supported-platforms-1
-
-::
-
-    evmAM572x
-    evmAM335x
-    evmAM437x
-    evmDRA72x
-    evmDRA75x
-    evmDRA78x
-    iceK2G
-    idkAM574x
-    idkAM572x
-    idkAM571x
-    idkAM437x
-    am65xx_evm
-    am65xx_idk
-    j721e_evm
-
-.. rubric:: Build instructions
-   :name: build-instructions-1
-
-OSAL tests are built using makefiles. The below steps are used to build
-the baremetal test binaries.
-
-::
-
-    cd pdk_<ver>/packages/
-    Run pdksetupenv.bat
-    Run "make osal"
-    Find the executable at ti/<pdk>/packages/ti/binary/osal_baremetal_test/bin
-    Load the executable on the board
-    Before running the executable, please make sure you have the UART connected and notice the test output on the UART console. Osal prints out the results there.
-
-.. rubric:: Testing the example
-   :name: testing-the-example-1
-
-The output for each of the tests (Hwi, Timer, Delay, Semaphores, etc)
-can be seen on the UART console. After a successful run, "All tests have
-passed" will be displayed on the screen.
-
-.. rubric:: Output
-   :name: output
-
-The output of osal example looks like below. The below sample output is
-from idkAM571x on the UART console.
-
-::
-
-    HWI tests have passed.
-    TimerTestLog: got 100 ticks from timer id = 1
-    TimerTestLog: got 100 ticks from timer id = 2
-
-::
-
-    Timer tests have passed.
-
-::
-
-    Running Osal_Delay test:..........
-
-::
-
-    Osal_Delay tests have passed.
-
-::
-
-    Clock tests have passed.
-
-::
-
-    Semaphore tests have passed.
-
-::
-
-    Semaphore Statistics:
-    PeakSemObjs = 5,
-    numMaxSemObjs = 100,
-    numFreeSemObjs = 97
-
-::
-
-    Hwi Statistics:
-    PeakHwiObjs = 3,
-    numMaxHwiObjs = 100,
-    numFreeHwiObjs = 98
-
-::
-
-    Timer Statistics:
-    PeakTimerObjs = 2,
-    numMaxTimerObjs = 100,
-    numFreeTimerObjs = 99
-
-::
-
-    All tests have passed.
-
-
-Additional References
----------------------
-
-+---------------------------------------------------------------------------------------------------+
-|                    **Operating System Abstraction Layer Library Summary**                         |
-+---------------------+-----------------------------------------------------------------------------+
-| **Component Type**  |                               **Library**                                   |
-+---------------------+-----------------------------------------------------------------------------+
-| Install Package     | PDK                                                                         |
-+---------------------+-----------------------------------------------------------------------------+
-| Install Directory   | pdk_AMX_<version>\\packages\\ti\\osal                                       |
-+---------------------+-----------------------------------------------------------------------------+
-| Project Type        | `Eclipse RTSC`_                                                             |
-+---------------------+-----------------------------------------------------------------------------+
-| Endian Support      | Little                                                                      |
-+---------------------+-----------------------------------------------------------------------------+
-| Linker Path         | $(TI_PDK_INSTALL_DIR)\\packages\\ti\\osal                                   |
-+---------------------+-----------------------------------------------------------------------------+
-| Linker Sections     | .vecs , .switch, .args, .cio                                                |
-+---------------------+-----------------------------------------------------------------------------+
-| Include Paths       | $(TI_PDK_INSTALL_DIR)\\packages\\ti\\osal                                   |
-+---------------------+-----------------------------------------------------------------------------+
-| Reference Guides    | $(TI_PDK_INSTALL_DIR)\\packages\\ti\\osal\\docs\\doxygen\\html\\index.html  |
-+---------------------+-----------------------------------------------------------------------------+
-| Release Notes       | $(TI_PDK_INSTALL_DIR)\\packages\\ti\\osal\\docs\\ReleaseNotes_OSAL.pdf      |
-+---------------------+-----------------------------------------------------------------------------+
-
-.. _Eclipse RTSC: http://www.eclipse.org/rtsc/
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Driver_Utilities/_Profiling.rst b/source/rtos/PDK_Platform_Software/Device_Driver_Utilities/_Profiling.rst
deleted file mode 100644
index d75c30779..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Driver_Utilities/_Profiling.rst
+++ /dev/null
@@ -1,220 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_PROFILING
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The profiling library can be used to profile any of the Platform
-Development Kit components at the runtime. Feature enables reporting of
-cpu cycles measurement for PDK driver components in order to analyze and
-meet constraint requirement for a real time application. Profiling
-module uses hardware clock of PMU to measure length of each task in
-processor cycles with minimal overhead. It use standard C programming
-hooks that may be adapted for any platform and/or processor
-architecture.
-
-Integration
------------
-
-**Baremetal or No-OS Use case**
-
-Reference Utils library path to be included in application build
-environment.
-
-::
-
-    -l <ti/utils/profiling/lib/[cpu]/>
-
-Reference lld library path to be included.(Replace profile suffix
-library with original one)
-
-::
-
-    -l <ti/drv/uart/lib/[soc]/[cpu]/lld.profiling>
-
-Example:
-
-::
-
-    -l "ti/utils/profiling/lib/armv7/ti.utils.profiling.aa15fg" -l "ti/drv/uart/lib/armv7/ti.drv.uart.profiling.aa15fg>
-
-**SysBIOS based application**
-
-Refer \*.cfg of Uart test application for sample implementation
-
-
-1. Load utils package.
-
-::
-
-    var Utils = xdc.loadPackage('ti.utils.profiling');
-
-2. Set the ‘enableProfiling’ attribute to ‘true’ into the .cfg file.
-This will load library with profiling enabled
-
-::
-
-    var Uart = xdc.loadPackage('ti.drv.uart’);
-    Uart.Settings.enableProfiling = true;
-
-3. Enable DDR3 memory, if not already enabled in test/example
-application
-
-::
-
-    Program.sectMap[".fardata:benchmarking"] = "DDR3";
-
-4. Add following line in .cfg if it does not exist already. Enable the
-Task hooks for Task switches.
-
-::
-
-    var Task = xdc.useModule('ti.sysbios.knl.Task');
-
-    Task.addHookSet({
-    registerFxn: '&TaskRegisterId',
-    switchFxn: '&mySwitch',
-    });
-
-**Additional compiler flags**
-
-1. For gcc compiler add
-
-::
-
-    -gdwarf-3 -finstrument-functions
-
-2. For TI compiler add
-
-::
-
-    --entry_parm=address --exit_hook=ti_utils_exit --exit_parm=address --entry_hook=ti_utils_entry
-
-Reference: \*project.txt inside UART test application
-
-Rebuild the project
--------------------
-
-.. rubric:: Profiling Processing
-   :name: profiling-processing
-
-All LLD Test/DMATest projects located under "LLD/test/" has profiling
-configuration enabled by default.
-
-Load compiled program onto desired target and platform. Run program to a
-desired logical point where profiling data needs to be collected
-
-1. While program is at the break, open the Memory Browser (View > Memory
-Browser).
-
-2. Save a memory snapshot by clicking "Save", setting the start address
-to "elemlog" and length to "log_idx*4". (It is preferred to save it into
-ti .dat format.)
-
-|
-
-.. rubric:: Profiling Post-processing
-   :name: profiling-post-processing
-
-**Host Environment:Windows or Ubuntu** **Tools dependencies:**
-
-+------------+---------------------------------------------------+
-| Tools      | Download                                          |
-+============+===================================================+
-| python 2.7 | https://www.python.org/downloads/                 |
-+------------+---------------------------------------------------+
-| pyelftools | https://github.com/eliben/pyelftools              |
-+------------+---------------------------------------------------+
-| tabulate   | https://pypi.python.org/pypi/tabulate             |
-+------------+---------------------------------------------------+
-| XlsxWriter | https://pypi.python.org/pypi/XlsxWriter#downloads |
-+------------+---------------------------------------------------+
-
-(Follow the standard instruction for installing the tools from their
-websites.)
-
-**Running the script**
-
-Open a cmd/terminal & set to the directory of the "decodeProfileDump.py"
-Python script (typically under utils/profiling/scripts)
-
-::
-
-    python decodeProfileDump.py -flags [log 1] [executable 1]
-
-Example:
-
-::
-
-    python decodeProfileDump.py -v uart.dat UART_BasicExample_k2h_armTestproject.out
-
-**Optional flags**
-
-+-----------------------------------+-----------------------------------+
-| Flags                             | Response                          |
-+===================================+===================================+
-| -v                                | Display verbose output            |
-+-----------------------------------+-----------------------------------+
-| –t                                | Breakdown function totals by      |
-|                                   | their reference sites             |
-+-----------------------------------+-----------------------------------+
-| –x                                | Print the tabulated results into  |
-|                                   | a report.xlsx Excel file          |
-+-----------------------------------+-----------------------------------+
-| -csv                              | Print the tabulated results into  |
-|                                   | a report.csv file                 |
-+-----------------------------------+-----------------------------------+
-| -off N                            | Manual instrumentation offset of  |
-|                                   | N cycles, subtracted from each    |
-|                                   | function.                         |
-+-----------------------------------+-----------------------------------+
-
-(The instrumentation program already generates an offset from itself
-that is subtracted from the function times. Use this flag only if there
-is an additional offset you would like to subtract.)
-
-**Report Fields**
-
-+-----------------------------------+-----------------------------------+
-| Term                              | Meaning                           |
-+===================================+===================================+
-| Function                          | Name of instrumented function     |
-+-----------------------------------+-----------------------------------+
-| Referenced_By                     | Call site of instrumented         |
-|                                   | function                          |
-+-----------------------------------+-----------------------------------+
-| Total_Cycles                      | Inclusive/Exclusive processor     |
-|                                   | cycles elapsed for instrumented   |
-|                                   | function                          |
-+-----------------------------------+-----------------------------------+
-| Average_Cycles                    | Processor cycles elapsed for      |
-|                                   | instrumented function per         |
-|                                   | reference                         |
-+-----------------------------------+-----------------------------------+
-| Total_Calls                       | Number of times instrumented      |
-|                                   | function is called                |
-+-----------------------------------+-----------------------------------+
-| Average_Calls                     | Number of times instrumented      |
-|                                   | function is called per reference  |
-+-----------------------------------+-----------------------------------+
-| Iterations                        | Number of times instrumented      |
-|                                   | function was referenced           |
-+-----------------------------------+-----------------------------------+
-
-(inclusive(inc): including the cycles of its child functions within,
-exclusive(exc): excluding the cycles of its child functions.)
-
-.. note::
-
-   Remaining functions on the stack at last timestamp will be considered
-   closed.
-
-   BIOS functions are not accounted by instrumentation and will not appear
-   in the report.
-
-   Functions which are optimized out will not appear in the report eg.
-   empty/single-line functions, ``ti_sysbios_*`` functions etc.
-
-|
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_CAL.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_CAL.rst
deleted file mode 100644
index c81395bf8..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_CAL.rst
+++ /dev/null
@@ -1,133 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_DSS
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-Camera Adapter Layer (CAL) is a very flexible subsystem that enables connection
-to multiple cameras supporting MIPI CSI-2 over D-PHY serial interface,
-a LVDS serial interface, and a traditional parallel interface.
-It also includes an internal write DMA engine connected to VBUSM interface.
-This document has detailed API description that user can use
-to make use of the CAL driver.
-
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **CAL Configuration Structure**
-   :name: cal-configuration-structure
-
-For details about individual fields of CAL library structure, see the
-Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\cal\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-The CAL driver API can be broadly divided into the following categories
-
-- Complex IO configuration APIs
-- Capture DMA configuration APIs.
-
-In addition to above the CAL package also includes many sample
-examples which show how to use the drivers in different ways. Many of
-these sample examples use a common set of APIs which a user may find
-useful to refer to for use in their final application.
-
-API reference for application:
-
-::
-
-    #include <ti/drv/cal/include/cal_drv.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-------------------------+
-| Name                  | | Description         | | Expected Results      |
-+=======================+=======================+=========================+
-| Capture Color Bar     | | Example             | | Example captures      |
-| from UB954            |   demonstrating       |   required frames from  |
-|                       |   Capture from UB954  |   UB954 and runs till   |
-|                       |   This captures a     |   completion.           |
-|                       |   Fixed pattern.      |   The Captured buffers  |
-|                       |                       |   can be saved on PC    |
-|                       |                       |   using the load raw    |
-|                       |                       |   commands.             |
-+-----------------------+-----------------------+-------------------------+
-| Capture image from    | | Example demonstrates| | Example captures      |
-| UB964 + SAT88 &       |   capturing the image |   required frames from  |
-| OV10635 sensors.      |   from the sensor.    |   the 4 Ov10635 sensors |
-|                       |                       |   and runs till         |
-|                       |                       |   completion.           |
-|                       |                       |   The captured buffers  |
-|                       |                       |   can be saved on PC    |
-|                       |                       |   using the load raw    |
-|                       |                       |   commands.             |
-+-----------------------+-----------------------+-------------------------+
-
-Additional References
----------------------
-
-+-----------------------------------+----------------------------------------+
-| **Document**                      | **Location**                           |
-+-----------------------------------+----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\cal\\docs\\doxygen\\html\\index.|
-|                                   | html                                   |
-+-----------------------------------+----------------------------------------+
-
-Building CAL examples
----------------------
-
--  CAL examples and dependent libraries are built from the top level cal
-   makefile
--  cd <pdk>/packages/ti/drv/cal
--  To build: make -s PDK_INSTALL_PATH=<pdk>/packages
--  To clean: make -s clean PDK_INSTALL_PATH=<pdk>/packages
-
-CAL examples
-------------
-
-.. rubric::  *Description*
-   :name: description
-
-CAL examples uses the CSI2 Capture port present on the EVM which is
-connected to CAL. The sensors are connected to the CSI2 capture port.
-The examples supports capturing from either UB954 or
-UB964 + SAT88 + 4 OV10635 sensors connected over the FPD link.
-The Example captures the input frame data coming from CSI2 port and
-writes back to the memory.
-
-|
-
-.. rubric::  **Running the Cal examples**
-   :name: running-the-cal-examples
-
-**Configuring Sensor**:
-
--  Make sure the UB954 Evm is connected to the CSI2 capture port and it is
-   powered on before running the example for option 0.
--  Make sure the UB964 Evm is connected to the CSI2 capture port along with
-   4 OV10635x cameras over the FPD link to the RIN0 to RIN3 ports and
-   the EVM is powered on before running the example for option 1.
-
-**CCS connection**:
-
--  Load the System firmware as specified in SCICLIENT documentation
--  Load the generated executable file in CCS
--  Run the application.
--  select the input based on the sensor connected.
--  Example will run till completion after capturing the frames.
--  Dump the buffers scripting console using the loadraw command specified.
--  Verify the output by viewing the captured image on PC.
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_CPPI.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_CPPI.rst
deleted file mode 100644
index d7f585aab..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_CPPI.rst
+++ /dev/null
@@ -1,333 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_CPPI
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-CPPI offers developers a common way of handling different protocol
-interfaces that may require multiple priorities and multiple channels on
-a single port. CPPI defines the register set, data structures,
-interrupts and buffer handling for all peripherals, regardless of
-protocol.
-
-CPPI is based on a buffer scatter/gather scheme, in which individual
-packets are broken up and then stored into small buffers, from which
-they are retrieved and reassembled (as opposed to using buffers that are
-located contiguously in memory). When protocol translation is required,
-a packet header can be appended in a small buffer, saving the CPU from
-having to rewrite the entire packet and header by performing a copy from
-one large buffer to another. The considerable savings in CPU cycles that
-result make buffer scatter/gathering the most efficient scheme for
-bridging and routing.
-
-The LLD provides resource management for descriptors, receive/transmit
-channels and receive flows.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The driver configures the CPPI subsystem using cppiGblCfgParams(system
-configuration) structure. The default global configuration per device is
-present under cppi_device.c file provided per device.
-
-For details about individual fields of this structure, see the Doxygen
-help by opening
-PDK_INSTALL_DIR\CPPIckages\ti\drv\CPPI\docs\doxygen\html\index.html.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/CPPI/CPPI_drv.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  || Description          | Expected Results      |
-+=======================+=======================+=======================+
-| CPPI_Example          | | Example             | | User observes the   |
-| application           |   demonstrating       |   output printed over |
-|                       |   *sample test* use   |   the CCS console     |
-|                       |   case. Reference     |                       |
-|                       |   example for         |                       |
-|                       |   developers          |                       |
-+-----------------------+-----------------------+-----------------------+
-| CPPI_UnitTestApplicat | | Unit Test           | | User observes the   |
-| ion                   |   application to test |   output printed over |
-|                       |   all APIs            |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-
-.. rubric:: Sample Example output
-   :name: sample-example-output
-
-This came from k2k example:
-
-::
-
-    **************************************************
-    *************** CPPI LLD usage example ***********
-    **************************************************
-    **************************************************
-    *************** CPPI LLD usage example ***********
-    **************************************************
-    **************************************************
-    **************************************************
-    *************** CPPI LLD usage example ***********
-    *************** CPPI LLD usage example ***********
-    **************************************************
-    **************************************************
-    *******Test running on Core 1 *******************
-    *******Test running on Core 0 *******************
-    *******Test running on Core 2 *******************
-    *******Test running on Core 3 *******************
-    Core 0 : L1D cache size 4. L2 cache size 0.
-    Core 2 : Starting BIOS...
-    Core 3 : Starting BIOS...
-    Core 0 : Starting BIOS...
-    Core 1 : Starting BIOS...
-    Core 0 : Created RM packet heap
-    Core 0 : Created IPC MessageQ heap
-    Core 0 : Created receive Q for Client1
-    Core 1 : Opened RM packet heap
-    Core 2 : Opened RM packet heap
-    Core 3 : Opened RM packet heap
-    Core 1 : Opened IPC MessageQ heap
-    Core 2 : Opened IPC MessageQ heap
-    Core 3 : Opened IPC MessageQ heap
-    Core 1 : Created receive Q for Server
-    Core 2 : Created receive Q for Server
-    Core 3 : Created receive Q for Server
-    Core 1 : Opened Server's receive Q
-    Core 1 : Waiting for QMSS to be initialized...
-
-    Core 0 : Opened Client1's receive Q for Server
-    Core 0 : Created receive Q for Client2
-    Core 0 : Opened Client2's receive Q for Server
-    Core 0 : Created receive Q for Client3
-    Core 2 : Opened Server's receive Q
-    Core 2 : Waiting for QMSS to be initialized...
-
-    Core 0 : Opened Client3's receive Q for Server
-
-    Core 0 : QMSS initialization done
-
-
-    Core 3 : Opened Server's receive Q
-    Core 1 : QMSS initialization done
-    Core 2 : QMSS initialization done
-    Core 3 : Waiting for QMSS to be initialized...
-
-
-    Core 3 : QMSS initialization done
-
-
-    Core 0 : QMSS CPDMA Opened
-    Core 1 : QMSS CPDMA Opened
-
-
-    Core 0 : Memory region 0 inserted
-    Core 0 : Number of descriptors requested : 8. Number of descriptors allocated : 8
-    Core 0 : Opened Rx channel : 0
-    Core 0 : Opened Tx channel : 0
-    Core 0 : Queue Number : 8192 opened
-    Core 0 : Queue Number : 8193 opened
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853b20
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853b20
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853b50
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853b50
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853b80
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853b80
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853bb0
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853bb0
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853be0
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853be0
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853c10
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853c10
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853c40
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853c40
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@10853c70
-    Receive Queue 8193 Entry Count : 1 Rx descriptor 0x@10853c70
-    Core 0 : Received host descriptor from Queue 897 Sucessfully
-    Core 0 : Tx Channel closed successfully. Ref count :0
-    Core 0 : Rx Channel closed successfully. Ref count :0
-    Core 0 : Rx queue closed successfully. Ref count :0
-    Core 0 : Tx queue closed successfully. Ref count :0
-    Core 0 : Free queue closed successfully. Ref count :0
-    Core 0 : Closing CPPI CPDMA Ref count : 3
-    Core 0 : CPPI CPDMA closed successfully
-    Core 1 : Memory region 1 inserted
-
-
-    Core 1 : Number of descriptors requested : 8. Number of descriptors allocated : 8
-    Core 2 : QMSS CPDMA Opened
-    Core 3 : QMSS CPDMA Opened
-    Core 1 : Opened Rx channel : 0
-
-
-    Core 1 : Opened Tx channel : 0
-    Core 2 : Memory region 2 inserted
-    Core 3 : Memory region 3 inserted
-    Core 1 : Queue Number : 0 opened
-    Core 2 : Number of descriptors requested : 8. Number of descriptors allocated : 8
-    Core 3 : Number of descriptors requested : 8. Number of descriptors allocated : 8
-    Core 1 : Queue Number : 1 opened
-    Core 2 : Opened Rx channel : 1
-    Core 3 : Opened Rx channel : 2
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853b20
-    Core 2 : Opened Tx channel : 1
-    Core 3 : Opened Tx channel : 2
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853b20
-    Core 2 : Queue Number : 8192 opened
-    Core 3 : Queue Number : 8193 opened
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853b50
-    Core 2 : Queue Number : 8194 opened
-    Core 3 : Queue Number : 8195 opened
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853b50
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853b20
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853b20
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853b80
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853b20
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853b20
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853b80
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853b50
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853b50
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853bb0
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853b50
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853b50
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853bb0
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853b80
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853b80
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853be0
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853b80
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853b80
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853be0
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853bb0
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853bb0
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853c10
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853bb0
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853bb0
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853c10
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853be0
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853be0
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853c40
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853be0
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853be0
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853c40
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853c10
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853c10
-    Transmit Queue 0 Entry Count : 1 Tx descriptor 0x@11853c70
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853c10
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853c10
-    Receive Queue 1 Entry Count : 1 Rx descriptor 0x@11853c70
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853c40
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853c40
-    Core 1 : Received host descriptor from Queue 896 Sucessfully
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853c40
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853c40
-    Core 1 : Tx Channel closed successfully. Ref count :0
-    Transmit Queue 8192 Entry Count : 1 Tx descriptor 0x@12853c70
-    Transmit Queue 8193 Entry Count : 1 Tx descriptor 0x@13853c70
-    Core 1 : Rx Channel closed successfully. Ref count :0
-    Receive Queue 8194 Entry Count : 1 Rx descriptor 0x@12853c70
-    Receive Queue 8195 Entry Count : 1 Rx descriptor 0x@13853c70
-    Core 1 : Rx queue closed successfully. Ref count :0
-    Core 2 : Received host descriptor from Queue 9026 Sucessfully
-    Core 3 : Received host descriptor from Queue 898 Sucessfully
-    Core 1 : Tx queue closed successfully. Ref count :0
-    Core 2 : Tx Channel closed successfully. Ref count :0
-    Core 3 : Tx Channel closed successfully. Ref count :0
-    Core 1 : Free queue closed successfully. Ref count :0
-    Core 2 : Rx Channel closed successfully. Ref count :0
-    Core 3 : Rx Channel closed successfully. Ref count :0
-    Core 1 : Closing CPPI CPDMA Ref count : 2
-    Core 2 : Rx queue closed successfully. Ref count :0
-    Core 3 : Rx queue closed successfully. Ref count :0
-    Core 1 : CPPI CPDMA closed successfully
-    Core 2 : Tx queue closed successfully. Ref count :0
-    Core 3 : Tx queue closed successfully. Ref count :0
-    Core 2 : Free queue closed successfully. Ref count :0
-    Core 3 : Free queue closed successfully. Ref count :0
-    Core 2 : Closing CPPI CPDMA Ref count : 1
-    Core 3 : CPPI CPDMA closed successfully
-    Core 2 : CPPI CPDMA closed successfully
-    Core 2 : CPPI exit successful
-    *******************************************************
-    *************** CPPI LLD usage example Done ***********
-    *******************************************************
-    Core 1 : CPPI exit successful
-    Core 3 : CPPI exit successful
-    *******************************************************
-    *******************************************************
-    *************** CPPI LLD usage example Done ***********
-    *************** CPPI LLD usage example Done ***********
-    *******************************************************
-    *******************************************************
-    Core 0 : CPPI exit successful
-    Core 0: exit QMSS
-    Instance name: RM_Server
-    Handle: 0x00849ee8
-    Type:   Server
-
-    Resource Status:
-
-    Core 0 : All resources freed successfully
-    *******************************************************
-    *************** CPPI LLD usage example Done ***********
-    *******************************************************
-
-.. rubric:: Debug FAQ
-   :name: debug-faq
-
-#. CPPI Lockup
-
-   #. CPPI can lock up if any pointer or length, including hint bits,
-      are wrong. Use the User Guide (TRM) referenced below to verify
-      every pointer and length in the descriptor. Also verify the hint
-      bits (low 4 bits of each descriptor) which represents size of
-      descriptor (not data) in 16-byte units. When using CPPI it should
-      be at least 1 (32 bytes) if no extensions are used, or 2 (48
-      bytes) if some extensions are used. 0 (16 bytes) is likely to
-      cause lock up!!
-
-#. See `QMSS Debug FAQ <index_device_drv.html#qmss>`__ for more.
-
-Additional References
----------------------
-
-.. list-table::
-   :header-rows: 1
-
-   * - **Document**
-
-     - **Location**
-
-   * - API Reference Manual
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/CPPI/docs/doxygen/html/index.html``
-
-   * - Release Notes
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/CPPI/docs/ReleaseNotes_CPPI_LLD.pdf``
-
-   * - Hardware Userguide/TRM
-
-     - `UG TRM PDF <http://www.ti.com/lit/sprugr9>`__
-
-   * - QMSS LLD (Navigator/Queueing HW component)
-
-     - `QMSS LLD`_
-
-.. _QMSS LLD:  index_device_drv.html#qmss
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_CSL.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_CSL.rst
deleted file mode 100644
index 63a8df977..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_CSL.rst
+++ /dev/null
@@ -1,179 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_CSL
-
-|
-
-.. rubric:: Overview
-   :name: overview-1
-
-The Chip Support Library constitutes a set of well-defined APIs that
-abstract low-level details of the underlying SoC device so that a user
-can configure, control (start/stop, etc.) and have read/write access to
-peripherals without having to worry about register bit-field details.
-The CSL services are implemented as distinct modules that correspond
-with the underlying SoC device modules themselves. By design, CSL APIs
-follow a consistent style, uniformly across Processor Instruction Set
-Architecture and are independent of the OS. This helps in improving
-portability of code written using the CSL.
-
-CSL is realized as twin-layer – a basic register-layer and a more
-abstracted functional-layer. The lower register layer comprises of a
-very basic set of macros and type definitions. The upper functional
-layer comprises of “C” functions that provide an increased degree of
-abstraction, but intended to provide “directed” control of underlying
-hardware.
-
-It is important to note that CSL does not manage data-movement over
-underlying h/w devices. Such functionality is considered a prerogative
-of a device-driver and serious effort is made to not blur the boundary
-between device-driver and CSL services in this regard.
-
-CSL does not model the device state machine. However, should there exist
-a mandatory (hardware dictated) sequence (possibly atomically executed)
-of register reads/writes to setup the device in chosen “operating modes”
-as per the device data sheet, then CSL does indeed support services for
-such operations.
-
-The CSL services are decomposed into modules, each following the
-twin-layer of abstraction described above. The APIs of each such module
-are completely orthogonal (one module’s API does not internally call API
-of another module) and do not allocate memory dynamically from within.
-This is key to keeping CSL scalable to fit the specific usage scenarios
-and ease the effort to ROM a CSL based application.
-
-In general for application recommended interfaces to be used will be
-driver API. CSL Functional layer APIs could be used for low-level access
-when required. CSL Register layer memory map is available for being used
-under rare cases in application when required.
-
-The source code of the CSL is located under $(TI_PDK_INSTALL_DIR)\\packages\\ti\\csl directory.
-
-
-.. rubric:: AM335x/AM437x
-   :name: am335xam437x
-
-The CSL component of AM335x/AM437x Processor SDK is referred as
-StarterWare in the legacy baseline releases.To maintain backward
-compatibility for existing applications on AM335x/AM437x SOCs,
-StarterWare low level package is retained. Customers are recommended
-to use driver interfaces for ease of migration of application software
-across SOCs.
-
-
-+-----------------------+------------------------------------------------------+
-|                       Chip Support Library/DAL Summary                       |
-+=======================+======================================================+
-|   **Component Type**  |   **Library**                                        |
-|                       |                                                      |
-+-----------------------+------------------------------------------------------+
-|   Install Package     |   PDK                                                |
-|                       |                                                      |
-+-----------------------+------------------------------------------------------+
-|   Install Directory   |   pdk_AMX_<version>\\packages\\ti\\starterware       |
-|                       |                                                      |
-+-----------------------+------------------------------------------------------+
-|   Endian Support      |   Little                                             |
-|                       |                                                      |
-+-----------------------+------------------------------------------------------+
-|   Linker Path         |   PDK_INSTALL_DIR\\packages\\ti\\starterware\\binary |
-|                       |                                                      |
-+-----------------------+------------------------------------------------------+
-|   Include Paths       |   PDK_INSTALL_DIR\\packages\\ti\\starterware\\include|
-|                       |                                                      |
-+-----------------------+------------------------------------------------------+
-
-
-AM57x/K2x/C66x/C674x
----------------------
-
-Application Integration
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-CSL is common package supporting multiple devices.Software layer using
-CSL source would need to pass compile time define -DSOC_XXX. Refer
-ti\csl\soc.h for list of devices/SOC's
-
-Refer list of APIs/interfaces available under <PDK_INSTALL_DIR\\packages\\ti\\csl> directory.
-
-
-+--------------------------+----------------------------------------+
-|                   Chip Support Library Summary                    |
-+==========================+========================================+
-|   Component Type         |   Library                              |
-|                          |                                        |
-+--------------------------+----------------------------------------+
-|   Install Package        |   PDK                                  |
-|                          |                                        |
-+--------------------------+----------------------------------------+
-|   Install Directory      |   PDK_INSTALL_DIR\\packages\\ti\\csl   |
-|                          |                                        |
-+--------------------------+----------------------------------------+
-|   Endian Support         |   Little                               |
-|                          |                                        |
-+--------------------------+----------------------------------------+
-|   Linker Path            |   PDK_INSTALL_DIR\\packages\\ti\\csl   |
-|                          |                                        |
-+--------------------------+----------------------------------------+
-|   Include Paths          |   $(TI_PDK_INSTALL_DIR)\\packages\\    |
-|                          |                                        |
-+--------------------------+----------------------------------------+
-|   Reference Guides       |   See docs under Install Directory     |
-|                          |                                        |
-+--------------------------+----------------------------------------+
-
-
-CSL-FL EXAMPLES
------------------
-
-These are example projects to test the functionality of API in CSL-FL
-layers. The following is the list of CSL-FL test examples which are
-supported with the CSL library:
-
--  DCAN
--  EDMA
--  GPIO
--  MAILBOX
--  I2C
--  QSPI
--  WDTIMER (WWDT)
--  MMCSD
--  MMU
--  SPINLOCK
--  UART
--  ECC : Limited to applicable SOC's/Boards:idkAM574x
--  GPMC : Limited to a15 core on idkAM572 and evmAM572x
--  ePWM : Duty Cycle example application - Limited to applicable SoC's/Boards: am65xx_evm, j721e_evm
-
-In order build the projects:
-
--  Navigate to pdk_[soc]_[version]\\packages
--  Run pdksetupenv.bat (windows) OR pdksetupenv.sh (linux).
--  Navigate to pdk_[soc]_[version]\\packages\\ti\\csl
-
-All CSL-FL examples can be cleaned and rebuilt with the following
-commands on windows:
-
-::
-
-    C:\ti\pdk_[soc]_[version]\packages\ti\csl>gmake app_clean
-    C:\ti\pdk_[soc]_[version]\packages\ti\csl>gmake apps
-
-All CSL-FL examples can be cleaned and rebuilt with the following
-commands on linux:
-
-::
-
-    ~/ti/pdk_[soc]_[version]/packages/ti/csl$ make app_clean
-    ~/ti/pdk_[soc]_[version]/packages/ti/csl$ make apps
-
--  All the output binary files will be generated in common location i.e.
-   pdk_[soc]_[version]\\packages\\ti\\binary\\[EXAMPLE]\\bin\\[BOARD]\\
-
--  DCAN RTOS example
-
-TI RTOS support is available for CSL DCAN example on AM572x platform.
-Refer to the readme document at below path for more details.
-
-<PDK Root>/packages/ti/csl/example/dcan/dcanLoopback
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_DSS.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_DSS.rst
deleted file mode 100644
index 41b0eec23..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_DSS.rst
+++ /dev/null
@@ -1,138 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_DSS
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The Display Subsystem (DSS) is a flexible, multi-pipeline subsystem that
-supports high-resolution display outputs. DSS includes input pipelines
-providing multi-layer blending with transparency to enable on-the-fly
-composition. Various pixel processing capabilities are supported,
-such as color space conversion and scaling, among others. DSS
-includes a DMA engine, which allows direct access to the frame buffer
-(device system memory). Display outputs can connect seamlessly to an
-Open LVDS Display Interface transmitter (OLDITX), or can directly drive
-device pads as a parallel video output interface.
-This document has detailed API description that user can use
-to make use of the DSS driver.
-
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **DSS Configuration Structure**
-   :name: dss-configuration-structure
-
-For details about individual fields of DSS library structure, see the
-Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\dss\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-The DSS driver API can be broadly divided into the following categories
-
--  DSS Display API - API for video display drivers
--  DSS Display Controller API - API for controlling and configuring
-   Video Ports in the display subsystem
-
-In addition to above drivers the DSS package also includes many sample
-examples which show how to use the drivers in different ways. Many of
-these sample examples use a common set of APIs which a user may find
-useful to refer to for use in their final application.
-
-API reference for application:
-
-::
-
-    #include <ti/drv/dss/include/dss_<func>.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | | Description         | | Expected Results    |
-+=======================+=======================+=======================+
-| Display Dss           | | Example             | | Application shows   |
-| application           |   demonstrating       |   two different       |
-|                       |   *simple* display    |   buffer on OLDI panel|
-|                       |   bgra frames         |   and success messages|
-|                       |   to the OLDI use     |   on CCS console.     |
-|                       |   case. Reference     |                       |
-|                       |   example for         |                       |
-|                       |   developers          |                       |
-+-----------------------+-----------------------+-----------------------+
-| Display Dss           | | Example             | | Application shows   |
-| application (Bare     |   demonstrating       |   two different       |
-| metal)                |   *simple* display    |   buffer on OLDI panel|
-|                       |   bgra frames         |   and success messages|
-|                       |   to the OLDI use     |   on CCS console.     |
-|                       |   case. Reference     |                       |
-|                       |   example for         |                       |
-|                       |   developers          |                       |
-+-----------------------+-----------------------+-----------------------+
-| Display Dss Colorbar  | | Example             | | Application shows   |
-| application           |   demonstrating       |   internal colorbar   |
-|                       |   internal colorbar   |   on OLDI panel       |
-|                       |   to the OLDI panel.  |   and success messages|
-|                       |   Reference example   |   on CCS console.     |
-|                       |   for developers.     |                       |
-+-----------------------+-----------------------+-----------------------+
-
-Additional References
----------------------
-
-+-----------------------------------+----------------------------------------+
-| **Document**                      | **Location**                           |
-+-----------------------------------+----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\dss\\docs\\doxygen\\html\\index.|
-|                                   | html                                   |
-+-----------------------------------+----------------------------------------+
-
-Building DSS examples
----------------------
-
--  DSS examples and dependent libraries are built from the top level dss
-   makefile
--  cd <pdk>/packages/ti/drv/dss
--  To build: make -s PDK_INSTALL_PATH=<pdk>/packages
--  To clean: make -s clean PDK_INSTALL_PATH=<pdk>/packages
-
-DSS examples
-------------
-
-.. rubric::  *Description*
-   :name: description
-
-DSS examples exploits the DISPC (Display Controller) and OLDI output
-available in the SoC. The example works on outputing pre-loaded
-video frames of BGRA8888 formats to OLDI interface. The example also
-demonstrates displaying videos combined from VID1 and VIDL1 pipelines
-to OLDI panel. The example is also enhanced to show the display controller
-scaling features.
-
-|
-
-.. rubric::  **Running the Display examples**
-   :name: running-the-display-examples
-
-**Configuring Display**:
-
--  Make sure the OLDI panel is connected to the base EVM before running
-   the example binary.
-
-**CCS connection**:
-
--  Load the System firmware as specified in SCICLIENT documentation
--  Load the generated executable file in CCS
--  Run the application.
--  Content will be displayed on the OLDI panel connected to EVM
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_EDMA3.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_EDMA3.rst
deleted file mode 100644
index 0ee4fdff0..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_EDMA3.rst
+++ /dev/null
@@ -1,163 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_EDMA3
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-EDMA3 Low Level Driver is targeted to device drivers and applications
-for submitting and synchronizing EDMA3-based DMA transfers.
-
-EDMA3 is a peripheral that supports data transfers between two memory
-mapped devices. It supports EDMA as well as QDMA channels for data
-transfer.
-
-The EDMA3 LLD consists of an EDMA3 Driver and EDMA3 Resource Manager.
-The **EDMA3 Driver** provides functionality that allows device drivers
-and applications for submitting and synchronizing with EDMA3 based DMA
-transfers. In order to simplify the usage, this component internally
-uses the services of the **EDMA3 Resource Manager** and provides one
-consistent interface for applications or device drivers.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-EDMA3 peripheral IP is re-used in different SoCs with only a few
-configuration changes:
-
--  Number of DMA and QDMA channels supported
--  Number of PARAM sets available
--  Number of event queues and transfer controllers etc.
-
-The EDMA3 peripheral is used by other peripherals for their DMA needs
-thus the EDMA3 Driver needs to cater to the requirements of device
-drivers of these peripherals as well as other application software that
-may need to use DMA services. Resources for EDMA driver is managed
-through RM sub module within driver.
-
-APIs
-^^^^^
-
-API reference for EDMA3 driver
-
-::
-
-    #include <ti/sdo/edma3/drv/edma3_drv.h>
-
-API reference for EDMA3 Resource Management layer
-
-::
-
-    #include <ti/sdo/edma3/rm/edma3_rm.h>
-
-FAQ
----
-**How to debug common EDMA issues?**
-
-Please refer to `EDMA3
-FAQ <http://www.ti.com/lit/an/sprac52/sprac52.pdf>`__ for Keystone devices.
-
-
-
-Additional References
----------------------
-
-+--------------------+-----------------------------------------------+
-|                       EDMA3 Driver Summary                         |
-+====================+===============================================+
-| Component Type     |    Library                                    |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Install Package    |    EDMA3 Low level drivers                    |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Install Directory  |    <root_install_dir>/edma3_lld_xx_xx_xx_xx   |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Project Type       |    N/A                                        |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Endian Support     |    Little and Big                             |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Library Name       |    edma3_lld_drv.ae66 (little endian),        |
-|                    |    edma3_lld_drv.ae66e (big endian),          |
-|                    |    edma3_lld_drv.aa15fg (A15),                |
-|                    |    edma3_lld_drv.aem4 (M4)                    |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Linker Path        |    <ti/sdo/edma3/drv/lib/[cpu]>               |
-|                    |    <ti/sdo/edma3/rm/lib/[soc-evm]>            |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Include Paths      |    <ti/sdo/edma3/drv>                         |
-|                    |    <ti/sdo/edma3/rm>                          |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Reference Guides   |    See docs under install directory           |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Additional         |    Programming the EDMA3 using the            |
-| Resources          |    Low-Level Driver (LLD)                     |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| License            |    BSD                                        |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-
-.. rubric:: EDMA3 sample libs
-   :name: edma3_sample_libs
-
-+--------------------+-----------------------------------------------+
-|                    EDMA3 Driver Sample Summary                     |
-+====================+===============================================+
-| Component Type     |    Library                                    |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Install Package    |    EDMA3 Low level drivers                    |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Install Directory  |    <root_install_dir>/edma3_lld_xx_xx_xx_xx   |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Project Type       |    N/A                                        |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Endian Support     |    Little and Big                             |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Library Name       |    edma3_lld_drv_sample.ae66 (little endian), |
-|                    |    edma3_lld_drv_sample.ae66e (big endian),   |
-|                    |    edma3_lld_drv_sample.aa15fg (A15),         |
-|                    |    edma3_lld_drv_sample.aem4 (M4)             |
-|                    |                                               |
-|                    |    edma3_lld_rm_sample.ae66 (little endian),  |
-|                    |    edma3_lld_rm_sample.ae66e (big endian),    |
-|                    |    edma3_lld_rm_sample.aa15fg (A15),          |
-|                    |    edma3_lld_rm_sample.aem4 (M4)              |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Linker Path        |  <ti/sdo/edma3/drv/sample/lib/[soc-evm]/[cpu]>|
-|                    |  <ti/sdo/edma3/rm/sample/lib/[soc-evm]/[cpu]> |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Include Paths      |    <ti/sdo/edma3/drv>                         |
-|                    |    <ti/sdo/edma3/rm>                          |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Reference Guides   |    See docs under install directory           |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| Additional         |    Programming the EDMA3 using the            |
-| Resources          |    Low-Level Driver (LLD)                     |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-| License            |    BSD                                        |
-|                    |                                               |
-+--------------------+-----------------------------------------------+
-
-|
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_EMAC.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_EMAC.rst
deleted file mode 100644
index 8a23ef598..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_EMAC.rst
+++ /dev/null
@@ -1,552 +0,0 @@
-.. http://http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_EMAC
-
-Introduction
--------------
-
-EMAC driver provides a well defined API layer which allows
-applications to use the EMAC peripheral to control the flow of packet
-data from the processor to the PHY and the MDIO module to control PHY
-configuration and status monitoring. EMAC driver is a common driver for
-supporting all 1 Gigabit Network interfaces including CPSW and ICSSG
-for applicable SOC's.
-
-Driver Configuration
----------------------
-
-Board Specific Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All the board specific configurations eg:enabling and pin-mux of
-RGMII/MDIO pins should be performed before calling any driver APIs. By
-default Board_Init() API supports all initialization sequence for TI
-supported EVMs.Refer `Processor SDK RTOS Board
-Support <index_board.html#board-support>`__ for additional
-details.
-
-Once the board specific configuration is complete driver API emac_open()
-can be called to initialize driver
-
-.. rubric:: **EMAC Configuration Structure**
-   :name: EMAC-configuration-structure
-
-The emac_soc.c file binds driver with hardware attributes on the board
-through EMAC_Cfg structure. This structure must be provided to EMAC
-driver. It must be initialized before the emac_open() function is
-called.
-
-For details about individual fields of this structure, see the Doxygen
-help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\emac\\docs\\doxygen\\html\\index.html.
-
-APIs
------
-
-API reference for application:
-
-::
-
-    #include <ti/drv/emac/emac_drv.h>
-
-.. rubric:: API Call Flow
-   :name: api-call-flow
-
-The below sequence indicates the calling sequence of EMAC driver
-APIs for a use case of an EMAC example which implements a single
-Ethernet MAC port. This example call flow is illustrated using port
-number 0.
-
-.. code-block:: c
-
-    port_num = 0;
-
-    Board_initCfg cfg = BOARD_INIT_UART_STDIO | BOARD_INIT_PINMUX_CONFIG | BOARD_INIT_MODULE_CLOCK  | BOARD_INIT_ETH_PHY;
-
-    Board_init(boardCfg);
-
-    /* Update emac_cfg with SOC specific config required by the driver */
-    /* Do a socGet, update emac_cfg as required and followed by socSet */
-    EMAC_socGetInitCfg(port_num, &emac_cfg);
-    ...
-    EMAC_socSetInitCfg(port_num, &emac_cfg);
-    ...
-    /* For UDMA based DMA interface, init the UDMA driver */
-    retVal = Udma_init(&gUdmaDrvObj, &initPrms);
-    ....
-    /* Populate open_cfg structure with application specific configuration */
-    retVal = emac_open(port_num, &open_cfg)
-    ....
-    /* Provide RX filter configuration (currently
-       only applicable for C6657 & OMAPL13x SOCs */
-    retVal = emac_config(port_num, &cfg_info);
-    ....
-    /* For SOCs with CPSW ports, query driver for CPSW statistics */
-    retVal = emac_get_statistics(port_num, &stats);
-    ....
-    /* For SOCs with ICSSG ports, query driver for ICSSG hardware statistics */
-    retVal = emac_get_statistics_icssg(port_num, &stats, clear);
-
-At this point EMAC driver is ready to send and receive packets.
-
-.. code-block:: c
-
-    /* Provide a context to poll the driver for received packets, showing RTOS use case */
-    Task_create(app_test_task_poll_pkt, &taskParams, NULL);
-    /* Sample implementation of task context */
-    app_test_task_pol_pkt(UArg arg0, UArg arg1)
-    {
-        while (1)
-        {
-            /* AM65xx supports optional mode of direct polling of RX queue for packets which can be
-	       configured at time of emac_open.  This mode of operation does not use
-	       interrupts. Note that default mode is via use of interrupts*/
-            emac_poll_pkt(port_num);
-        }
-    }
-
-    /* Provide a context to poll the driver for link status, showing RTOS use case */
-    Task_create(app_test_task_poll_link, &taskParams, NULL);
-    /* Sample implementation of task context */
-    app_test_task_pol_link(UArg arg0, UArg arg1)
-    {
-        EMAC_LINK_INFO_T linkInfo;
-        do
-        {
-            emac_poll(port_num, &linkInfo);
-            Osal_delay(1000);
-            UART_printf("Link for port %d is DOWN\n", port_num);
-        } while(linkInfo.link_status == EMAC_LINKSTATUS_NOLINK);
-
-	UART_printf("Link for port %d is UP\n", port_num);
-    }
-
-    /* Close port and release all resources allocated at time of emac_open */
-    retVal = emac_close(port_num);
-
-|
-
-
-Interposer Card Support
-------------------------
-Interposer card is an ethernet wiring adapter to let 2 ICSSG subsystems drive 2 ethernet ports with DUAL MAC or SWITCH firmware.
-So that each direction (TX/RX) can be handled by one pair of PRU cores.
-The interposer card permits the power of two ICSSG instances to be used on a two port switch or dual EMAC as opposed to the two-port, single ICSSG configuration.
-The following diagrams show the PRU-ICSSG RGMII TX/RX mapping to the physical ports for Maxwell and then for Maxwell with interposer card configured.
-Interposer card functionality can be verified by running the icssg-emac DIAG test( Refer `Processor SDK RTOS Board
-Support <index_board.html#board-support>`__ for additional details ) or the emac LLD test
-application (Emac_Icssg_TestApp described below).
-Note that prior to running these tests on Maxwell with interposer card, please hook up an ethernet cable between PHY0 and PHY1.
-
-
-.. rubric:: Interposer Layout
-   :name: Interposer Layout
-
-.. Image:: /images/Interposer.png
-
-Example and Test Applications
-------------------------------
-
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| Name                         | Description           | Expected Results      | SOC Suppported        | Build Type            |
-+==============================+=======================+=======================+=======================+=======================+
-| EMAC_BasicExample            | EMAC Loopback test    | Unit Test will        |    AM335x,            |  CCS project          |
-|                              | at CPSW switch        | print "All tests      |    AM437x,            |                       |
-|                              | interface.            | have passed" via      |    AM572x,            |                       |
-|                              | Reference example     | UART console.         |    AM571x,            |                       |
-|                              | for developers        |                       |    AM574x,            |                       |
-|                              |                       |                       |    K2G                |                       |
-|                              | Example demonstrates  |                       |                       |                       |
-|                              | loopback capability   |                       |                       |                       |
-|                              | by sending dummy      |                       |                       |                       |
-|                              | broadcast packet to   |                       |                       |                       |
-|                              | CPSW switch. Unit     |                       |                       |                       |
-|                              | test registers        |                       |                       |                       |
-|                              | receive packet        |                       |                       |                       |
-|                              | callback routine with |                       |                       |                       |
-|                              | LLD to be called for  |                       |                       |                       |
-|                              | RX packet. Call back  |                       |                       |                       |
-|                              | routine will extract  |                       |                       |                       |
-|                              | packet received,      |                       |                       |                       |
-|                              | perform simple memory |                       |                       |                       |
-|                              | comparison against    |                       |                       |                       |
-|                              | packet sent for       |                       |                       |                       |
-|                              | integrity check. Unit |                       |                       |                       |
-|                              | test will iterate     |                       |                       |                       |
-|                              | over configured       |                       |                       |                       |
-|                              | packet count for      |                       |                       |                       |
-|                              | packet transmission   |                       |                       |                       |
-|                              | and reception check.  |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| EMAC_SMP_BasicExample        | EMAC Loopback test    | Unit Test will        |     AM572x-EVM        |  CCS project          |
-|                              | at CPSW switch        | print "All tests      |                       |                       |
-|                              | interface with SMP    | have passed" via      |                       |                       |
-|                              | enabled.              | UART console.         |                       |                       |
-|                              | (A15 core only)       |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| EMACLoopback_testProj        | EMAC Loopback test    | Unit Test will        |  C6657,               | CCS project           |
-| ect                          | at CPSW switch        | print "Loopback       |  DRA7xx,              |                       |
-|                              | interface.            | Test completed        |  OMAPL137,            |                       |
-|                              | Reference example     | successfully on       |  OMAPL138             |                       |
-|                              | for developers        | core 0" via CCS       |                       |                       |
-|                              |                       | console for C6657     |                       |                       |
-|                              | Example demonstrates  | and on UART serial    |                       |                       |
-|                              | loopback capability   | console for           |                       |                       |
-|                              | by sending dummy      | OMAPL13x.             |                       |                       |
-|                              | broadcast packet to   |                       |                       |                       |
-|                              | CPSW switch. Unit     |                       |                       |                       |
-|                              | test registers        |                       |                       |                       |
-|                              | receive packet        |                       |                       |                       |
-|                              | callback routine with |                       |                       |                       |
-|                              | LLD to be called for  |                       |                       |                       |
-|                              | RX packet. Call back  |                       |                       |                       |
-|                              | routine will extract  |                       |                       |                       |
-|                              | packet received,      |                       |                       |                       |
-|                              | perform simple memory |                       |                       |                       |
-|                              | comparison against    |                       |                       |                       |
-|                              | packet sent for       |                       |                       |                       |
-|                              | integrity check. Unit |                       |                       |                       |
-|                              | test will iterate     |                       |                       |                       |
-|                              | over configured       |                       |                       |                       |
-|                              | packet count for      |                       |                       |                       |
-|                              | packet transmission   |                       |                       |                       |
-|                              | and reception check.  |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | This example needs to |                       |                       |                       |
-|                              | be run on the         |                       |                       |                       |
-|                              | OMAPL137 and OMAPL138 |                       |                       |                       |
-|                              | platforms using       |                       |                       |                       |
-|                              | external loopback     |                       |                       |                       |
-|                              | cable. OMAPL137 EVM   |                       |                       |                       |
-|                              | is having two         |                       |                       |                       |
-|                              | Ethernet ports.       |                       |                       |                       |
-|                              | Connect the loopback  |                       |                       |                       |
-|                              | cable to the port 1   |                       |                       |                       |
-|                              | (ENET-P1) while       |                       |                       |                       |
-|                              | running the loopback  |                       |                       |                       |
-|                              | example.              |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| EMAC_PktInspectionExa        | This demonstrates how | Pass criteria:        |  DRA7xx               | CCS project           |
-| mple                         | to write an           |                       |                       |                       |
-|                              | application to filter | -  The total packet   |                       |                       |
-|                              | Ethernet packets      |    sent for each      |                       |                       |
-|                              | based on IP address   |    stream is shown at |                       |                       |
-|                              |                       |    the bottom of the  |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | Prerequisites:        |    packETH widow. The |                       |                       |
-|                              |                       |    packet stream      |                       |                       |
-|                              | -  Install the        |    statistics must    |                       |                       |
-|                              |    packETH utility (v |    match the packet   |                       |                       |
-|                              |    1.8.1) on a Linux  |    statistics printed |                       |                       |
-|                              |    PC. The packETH    |    by the DUT via     |                       |                       |
-|                              |    tool is available  |    serial port        |                       |                       |
-|                              |    for Windows as     | -  The packet         |                       |                       |
-|                              |    well, but not all  |    inspection utility |                       |                       |
-|                              |    features are       |    periodically       |                       |                       |
-|                              |    supported          |    prints the EMAC    |                       |                       |
-|                              | -  Download the test  |    statistics, which  |                       |                       |
-|                              |    PCAP `files`_      |    include DMA        |                       |                       |
-|                              |                       |    overruns,          |                       |                       |
-|                              |                       |    underruns and      |                       |                       |
-|                              |    and update the     |    other error. No    |                       |                       |
-|                              |    source and dest    |    errors should be   |                       |                       |
-|                              |    MAC address of the |    seen during the    |                       |                       |
-|                              |    PC and EVM to be   |    transfer.          |                       |                       |
-|                              |    used in the test.  |                       |                       |                       |
-|                              |    The tcprewrite     | Fail criteria:        |                       |                       |
-|                              |    utility can be     |                       |                       |                       |
-|                              |    used to set the    | -  Packet count       |                       |                       |
-|                              |    new MAC addresses  |    mismatch between   |                       |                       |
-|                              |    (i.e. tcprewrite   |    packETH utility    |                       |                       |
-|                              |    --enet-smac=<PC-MA |    and counters from  |                       |                       |
-|                              | C-address>            |    the IPU1           |                       |                       |
-|                              |    --enet-dmac=<EVM-M |    application        |                       |                       |
-|                              | AC-address>           | -  Any EMAC errors    |                       |                       |
-|                              |    -i ./ip1_test.pcap |    reported by the    |                       |                       |
-|                              |    -o                 |    IPU1 application   |                       |                       |
-|                              |    ./ip1_test.pcap)   |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | Steps:                |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | -  Launch the packETH |                       |                       |                       |
-|                              |    utility on the     |                       |                       |                       |
-|                              |    Linux PC with root |                       |                       |                       |
-|                              |    permissions        |                       |                       |                       |
-|                              | -  Go to the "Gen-S"  |                       |                       |                       |
-|                              |    tab of the packETH |                       |                       |                       |
-|                              |    utility and select |                       |                       |                       |
-|                              |    the PCAP files to  |                       |                       |                       |
-|                              |    be used            |                       |                       |                       |
-|                              | -  Set the transfer   |                       |                       |                       |
-|                              |    rate for each PCAP |                       |                       |                       |
-|                              |    file (i.e. 200     |                       |                       |                       |
-|                              |    Mbit/s and 150     |                       |                       |                       |
-|                              |    Mbit/s)            |                       |                       |                       |
-|                              | -  Set the total      |                       |                       |                       |
-|                              |    packets to         |                       |                       |                       |
-|                              |    transfer to 500000 |                       |                       |                       |
-|                              | -  Load and run the   |                       |                       |                       |
-|                              |    EMAC packet        |                       |                       |                       |
-|                              |    inspection         |                       |                       |                       |
-|                              |    application to the |                       |                       |                       |
-|                              |    IPU1 core          |                       |                       |                       |
-|                              | -  Hit the "Send"     |                       |                       |                       |
-|                              |    button on the      |                       |                       |                       |
-|                              |    packETH utility to |                       |                       |                       |
-|                              |    start streaming    |                       |                       |                       |
-|                              | -  The packet         |                       |                       |                       |
-|                              |    streaming should   |                       |                       |                       |
-|                              |    last for few       |                       |                       |                       |
-|                              |    seconds            |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| Emac_Cpsw_TestApp            | EMAC Loopback test    | Unit Test will        | AM65xx,               | makefile              |
-|                              | at CPSW switch        | print "All tests      | J721E                 |                       |
-|                              | interface.            | have passed" via      |                       |                       |
-|                              | Reference application | UART console.         |                       |                       |
-|                              | for developers        |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | TestApp demonstrates  |                       |                       |                       |
-|                              | loopback capability   |                       |                       |                       |
-|                              | by sending packets to |                       |                       |                       |
-|                              | CPSW switch. Unit     |                       |                       |                       |
-|                              | test registers        |                       |                       |                       |
-|                              | receive packet        |                       |                       |                       |
-|                              | callback routine with |                       |                       |                       |
-|                              | LLD to be called for  |                       |                       |                       |
-|                              | RX packet. Call back  |                       |                       |                       |
-|                              | routine will extract  |                       |                       |                       |
-|                              | packet received,      |                       |                       |                       |
-|                              | perform simple memory |                       |                       |                       |
-|                              | comparison against    |                       |                       |                       |
-|                              | packet sent for       |                       |                       |                       |
-|                              | integrity check. Unit |                       |                       |                       |
-|                              | test will iterate     |                       |                       |                       |
-|                              | over configured       |                       |                       |                       |
-|                              | packet count for      |                       |                       |                       |
-|                              | packet transmission   |                       |                       |                       |
-|                              | and reception check.  |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| Emac_Cpsw_SMP_TestApp        | EMAC Loopback test    | Unit Test will        | AM65xx                | makefile              |
-|                              | at CPSW switch        | print "All tests      |                       |                       |
-|                              | interface with SMP    | have passed" via      |                       |                       |
-|                              | enabled               | UART console.         |                       |                       |
-|                              | (A53 core only)       |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| Emac_Icssg_TestApp           | EMAC port 2 port test | Unit Test will        | AM65xx                | makefile              |
-|                              | between ICSSG ports.  | print "All tests      |                       |                       |
-|                              | Reference application | have passed" via      |                       |                       |
-|                              | for developers        | UART console          |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | Prior to running this |                       |                       |                       |
-|                              | test, please connect  |                       |                       |                       |
-|                              | the ICSSG ports as    |                       |                       |                       |
-|                              | follows with          |                       |                       |                       |
-|                              | ethernet cables:      |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | PHY0 to PHY1          |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | PHY2 to PHY3          |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | PHY4 to PHY5          |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | Test app demonstrates |                       |                       |                       |
-|                              | packet TX/RX between  |                       |                       |                       |
-|                              | 2 ICSSG ports. All 6  |                       |                       |                       |
-|                              | ICSSG ports will be   |                       |                       |                       |
-|                              | tested for am65xx-idk.|                       |                       |                       |
-|                              | PRU2 ports will be    |                       |                       |                       |
-|                              | tested for am65xx-evm.|                       |                       |                       |
-|                              | Unit test registers   |                       |                       |                       |
-|                              | receive packet        |                       |                       |                       |
-|                              | callback routine with |                       |                       |                       |
-|                              | LLD to be called for  |                       |                       |                       |
-|                              | RX packet. Call back  |                       |                       |                       |
-|                              | routine will extract  |                       |                       |                       |
-|                              | packet received,      |                       |                       |                       |
-|                              | perform simple memory |                       |                       |                       |
-|                              | comparison against    |                       |                       |                       |
-|                              | packet sent for       |                       |                       |                       |
-|                              | integrity check. Unit |                       |                       |                       |
-|                              | test will iterate     |                       |                       |                       |
-|                              | over configured       |                       |                       |                       |
-|                              | packet count for      |                       |                       |                       |
-|                              | packet transmission   |                       |                       |                       |
-|                              | and reception check.  |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| Emac_Icssg_Switch_TestApp    | Switch port 2 port    | Unit Test will        | AM65xx                | makefile              |
-|                              | test between ICSSG    | print "All tests      |                       |                       |
-|                              | ports.                |                       |                       |                       |
-|                              | Reference application | have passed" via      |                       |                       |
-|                              | for developers        | UART console          |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | Prior to running this |                       |                       |                       |
-|                              | test, please connect  |                       |                       |                       |
-|                              | the ICSSG ports as    |                       |                       |                       |
-|                              | follows with          |                       |                       |                       |
-|                              | ethernet cables:      |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | PHY0 to PHY1          |                       |                       |                       |
-|                              |                       |                       |                       |                       |
-|                              | Test app demonstrates |                       |                       |                       |
-|                              | packet TX/RX between  |                       |                       |                       |
-|                              | 2 ICSSG Switch ports. |                       |                       |                       |
-|                              | Unit test registers   |                       |                       |                       |
-|                              | receive packet        |                       |                       |                       |
-|                              | callback routine with |                       |                       |                       |
-|                              | LLD to be called for  |                       |                       |                       |
-|                              | RX packet. Call back  |                       |                       |                       |
-|                              | routine will extract  |                       |                       |                       |
-|                              | packet received,      |                       |                       |                       |
-|                              | perform simple memory |                       |                       |                       |
-|                              | comparison against    |                       |                       |                       |
-|                              | packet sent for       |                       |                       |                       |
-|                              | integrity check. Unit |                       |                       |                       |
-|                              | test will iterate     |                       |                       |                       |
-|                              | over configured       |                       |                       |                       |
-|                              | packet count for      |                       |                       |                       |
-|                              | packet transmission   |                       |                       |                       |
-|                              | and reception check.  |                       |                       |                       |
-+------------------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-
-
-Support for Benchmark Testing
-------------------------------
-
-+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results      | SOC Suppported        | Build Type            |
-+=======================+=======================+=======================+=======================+=======================+
-| Emac_Icssg_TestApp    | Test application with | Test applicaiton      |  am65xx               | make                  |
-|                       | modifications can     | will print "polling   |                       |                       |
-|                       | used for performance  | rx packets on port 4" |                       |                       |
-|                       | benchmarking          | via the UART console  |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       |                       | Every 60 seconds,     |                       |                       |
-|                       | In order to run the   | a sub-set of hardware |                       |                       |
-|                       | test application in   | statistics will be    |                       |                       |
-|                       | benchamrk mode you    | displayed via UART    |                       |                       |
-|                       | need to update        | console               |                       |                       |
-|                       | ti/drv/emac/test/     |                       |                       |                       |
-|                       | EmacLoopbackTest/     |                       |                       |                       |
-|                       | test_loc.h to enable  |                       |                       |                       |
-|                       | EMAC_BENCHMARK macro  |                       |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       | Connect external      |                       |                       |                       |
-|                       | packet generator to   |                       |                       |                       |
-|			| PHY4.                 |                       |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       | The unit test will    |                       |                       |                       |
-|                       | poll the RX packet    |                       |                       |                       |
-|                       | channel/ring for the  |                       |                       |                       |
-|                       | port being testing and|                       |                       |                       |
-|                       | will loop the packet  |                       |                       |                       |
-|                       | back to the external  |                       |                       |                       |
-|                       | traffic generator with|                       |                       |                       |
-|                       | "no touch" to the     |                       |                       |                       |
-|                       | packet                |                       |                       |                       |
-|                       |			|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-| Emac_Cpsw_TestApp     | Test application with | Test application      |  am65xx               | make                  |
-|                       | modifications can     | will print "polling   |                       |                       |
-|                       | used for performance  | rx packets on port 6" |                       |                       |
-|                       | benchmarking          | via the UART console  |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       |                       | Every 60 seconds,     |                       |                       |
-|                       | In order to run the   | a sub-set of hardware |                       |                       |
-|                       | test application in   | statistics will be    |                       |                       |
-|                       | benchamrk mode you    | displayed via UART    |                       |                       |
-|                       | need to update        | console               |                       |                       |
-|                       | ti/drv/emac/test/     |                       |                       |                       |
-|                       | EmacLoopbackTest/     |                       |                       |                       |
-|                       | test_loc.h to enable  |                       |                       |                       |
-|                       | EMAC_BENCHMARK macro  |                       |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       | To benchmark ICSSG    |                       |                       |                       |
-|                       | connect external      |                       |                       |                       |
-|                       | packet generator to   |                       |                       |                       |
-|			| PHY4.                 |                       |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       | To benchmark CPSW     |                       |                       |                       |
-|                       | connect external      |                       |                       |                       |
-|                       | packet generator to   |                       |                       |                       |
-|                       | CPSW port             |                       |                       |                       |
-|                       |                       |                       |                       |                       |
-|                       | The unit test will    |                       |                       |                       |
-|                       | poll the RX packet    |                       |                       |                       |
-|                       | channel/ring for the  |                       |                       |                       |
-|                       | port being testing and|                       |                       |                       |
-|                       | will loop the packet  |                       |                       |                       |
-|                       | back to the external  |                       |                       |                       |
-|                       | traffic generator with|                       |                       |                       |
-|                       | "no touch" to the     |                       |                       |                       |
-|                       | packet                |                       |                       |                       |
-|                       |			|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
-
-
-Building EMAC Test applications via makefiles
-----------------------------------------------
-
--  EMAC Test applications and dependent libraries are built from the top level emac
-   makefile
--  Refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__  for details
-   of how to setup the build environment. Once you have setup the build environment, issue the following commands:
-
-    -  cd <pdk>/packages/
-    -  To build: make emac
-    -  To clean: make emac_clean
-
-- Similarly, to build at the module level, issue the following commands for rebuilding :
-
-    - cd <pdk>/packages/ti/drv/emac
-    - To build: make all
-    - To clean: make clean
-
-
-Running EMAC Examples and Test applications
---------------------------------------------
-
-.. rubric::  *Description*
-   :name: description
-
-EMAC Test applications demonstrates the key features of the driver.
-
-|
-
-.. rubric::  **Running the EMAC Test applications**
-   :name: running-the-emac-Test applications
-
-**Via CCS connection**:
-
--  Load the System firmware as specified in SCICLIENT documentation for AM65xx SOC
--  Load the generated executable file in CCS
--  Run the application.
--  The application print will be displayed on the CCS and UART console. The UART console used depends on the core in which the application is run.
-
-
-**Via Secondary Bootloader (SBL)**:
-
-EMAC Test applications can also be run via SBL. To run via SBL, please following the instructions as specified in the following link:
-`SBL User Guide <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#am655x-compiling-apps-for-sbl>`__
-
-.. _files: :download:`</images/Pcap.zip>`
-
-Additional References
-----------------------
-
-+-----------------------------------+-----------------------------------------+
-|           **Document**            |           **Location**                  |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\emac\\docs\\doxygen\\html\\index |
-|                                   | .html                                   |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\emac\\docs\\ReleaseNotes_EMAC_   |
-|                                   | LLD.pdf                                 |
-+-----------------------------------+-----------------------------------------+
-| Software Design                   | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\emac\\docs\\EMAC_LLD_SD.pdf      |
-+-----------------------------------+-----------------------------------------+
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_FATFS.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_FATFS.rst
deleted file mode 100644
index e32592715..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_FATFS.rst
+++ /dev/null
@@ -1,192 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_FATFS
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-FATFS module provides an interface to configure a driver for FAT file
-system compatible device that connects via MMCSD, USB, etc. It
-configures FATFS for disk operations driver disk Initialize, disk
-read, disk write
-
-Driver Overview
----------------
-
-PDK FATFS driver provides support for both single and multiple partition on a given
-SD/MMC card. The driver uses a volume to partition mapping technique to handle multiple
-storage device with multiple partition. The driver supports file operations such as
-open, read and wirte on to the SD/MMC card. The FATFS driver access the SD/MMC card
-through the PDK MMCSD driver which needs to be configured from the application as part
-of the FATFS_config structure. The FATFS driver is used in other PDK module application
-such as MMCSD, USB and SBL.
-
-FATFS file operation API's can be accessed from the application only after FATFS_open
-function is invoked.
-
-.. code-block:: c
-
-   FATFS_init();
-   FATFS_open(0U, NULL, &fatfsHandle);
-
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All board specific configurations eg:enabling clock and pin-mux for UART
-pins are required before calling any driver APIs.By default Board_Init()
-API supports all initialization sequence for TI supported EVMs. In
-addition it initializes UART instance for Console/STDIO.Refer `Processor
-SDK RTOS Board Support <index_board.html#board-support>`__
-for additional details.Once board specific configuration is complete 
-FATFS_init() API can be called to initialize FATFS for the driver.
-
-
-.. rubric:: **FATFS Configuration Structure**
-   :name: fatfs-configuration-structure
-
-Application is expected to perform driver specific configuration for
-FATFS_config structure. The structure supports initialization of
-multiple drivers for FATFS, i.e. both MMCSD and USB can be configured
-to use FATFS file system by configuring each driver to different drive
-instance. This structure must be provided to the FATFS driver. It must
-be initialized before the FATFS_init() function is called and cannot
-be changed subsequently. For details about individual fields of this
-structure, see the Doxygen
-help:PDK_INSTALL_DIR\\packages\\ti\\fs\\fatfs\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-In order to use the FATFS module APIs, the FATFS.h and ff.h header file
-should be included in an application as follows:
-
-.. code-block:: c
-
-    #include <ti/fs/fatfs/FATFS.h>
-    #include <ti/fs/fatfs/ff.h>
-
-.. rubric:: API Call Flow
-   :name: api-call-flow
-
-Below sequence indicates the calling sequence of FATFS driver APIs:
-
-.. code-block:: c
-
-     FATFS_Handle FATFS;
-     FATFS_Params FATFSParams;
-     FATFS_Params_init(&FATFSParams);
-     FATFS = FATFS_open(peripheralNum, &FATFSParams);
-
-
-
-At this point application can invoke additional FAT File system API
-eg: f_open(), f_write(), f_read() etc to perform file operations on
-device
-
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+------------------------------+-----------------------+-----------------------+----------------+--------------+
-| Name                         | | Description         | Expected Results      | Supported SOCs | Build Type   |
-+==============================+=======================+=======================+================+==============+
-| FATFS_Console_ExampleProject | | Example will        | When a card is        |                |              |
-|                              |   initialize card and | detected with valid   |  AM335x        | CCS  Project |
-|                              |   checks for valid    | FAT partition console |  AM437x        |              |
-|                              |   FAT partition. When | interface output will |  AM571x        |              |
-|                              |   a valid FAT         | indicate "0:> "       |  AM572x        |              |
-|                              |   partition is        |                       |  AM574x        |              |
-|                              |   detected console    |                       |                |              |
-|                              |   interface for       |                       |                |              |
-|                              |   command execution   |                       |                |              |
-|                              |   is provided.        |                       |                |              |
-|                              |   Supported console   |                       |                |              |
-|                              |   commands include ls |                       |                |              |
-|                              |   (to list files of   |                       |                |              |
-|                              |   directory), cd      |                       |                |              |
-|                              |   (change directory), |                       |                |              |
-|                              |   pwd (present        |                       |                |              |
-|                              |   working directory)  |                       |                |              |
-|                              |   and cat (text file  |                       |                |              |
-|                              |   read operation).    |                       |                |              |
-+------------------------------+-----------------------+-----------------------+----------------+--------------+
-| FATFS_Console_TestApp        | | Same as above       | Same as above         | AM65x          | Makefile     |
-+------------------------------+-----------------------+-----------------------+----------------+--------------+
-| FATFS_Console_SMP_Example    | | Example will        | When a card is        |                |              |
-| Project                      |   initialize card and | detected with valid   |   AM572x-EVM   | CCS  Project |
-|                              |   checks for valid    | FAT partition console |   (A15 core)   |              |
-|                              |   FAT partition. When | interface output will |                |              |
-|                              |   a valid FAT         | indicate "0:> "       |                |              |
-|                              |   partition is        |                       |                |              |
-|                              |   detected console    |                       |                |              |
-|                              |   interface for       |                       |                |              |
-|                              |   command execution   |                       |                |              |
-|                              |   is provided.        |                       |                |              |
-|                              |   Supported console   |                       |                |              |
-|                              |   commands include ls |                       |                |              |
-|                              |   (to list files of   |                       |                |              |
-|                              |   directory), cd      |                       |                |              |
-|                              |   (change directory), |                       |                |              |
-|                              |   pwd (present        |                       |                |              |
-|                              |   working directory)  |                       |                |              |
-|                              |   and cat (text file  |                       |                |              |
-|                              |   read operation)     |                       |                |              |
-|                              |   with SMP enabled.   |                       |                |              |
-+------------------------------+-----------------------+-----------------------+----------------+--------------+
-| FATFS_Console_SMP_TestApp    | | Same as above       | Same as above         | AM65x(A53 core)| Makefile     |
-+------------------------------+-----------------------+-----------------------+----------------+--------------+
-
-
-Building CCS projects based examples
-------------------------------------
-
-CCS Projects mentioned in the above table are built using pdkProjectCreate.bat/sh as explained in
-`PDK Example and Test Project Creation <index_overview.html#pdk-example-and-test-project-creation>`__
-
-
-Building FATFS Test applications via makefiles
-----------------------------------------------
-
-- FATFSD Test applications and dependent libraries are built from the top level fatfs makefile
-- Refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__  for details
-  of how to setup the build environment. Once you have setup the build environment, issue the following commands:
-
-    -  cd <pdk>/packages/
-    -  To build: make fatfs
-    -  To clean: make fatfs_clean
-
-- Similarly, to build at the module level, issue the following commands for rebuilding :
-
-    - cd <pdk>/packages/ti/fs/fatfs
-    - To build: make all
-    - To clean: make clean
-
-
-
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\fs\\fatfs\\docs\\doxygen\\html\\index |
-|                                   | .html                                   |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\fs\\fatfs\\docs\\ReleaseNotes_FATFS   |
-|                                   | _LLD.pdf                                |
-+-----------------------------------+-----------------------------------------+
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_GPIO.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_GPIO.rst
deleted file mode 100644
index 1f4155577..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_GPIO.rst
+++ /dev/null
@@ -1,182 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_GPIO
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-GPIO module allows application to manage General Purpose I/O  instances
-and pins via simple portable APIs. Because of its simplicity, APIs are
-pin based and does not follow model of other drivers inside PDK which
-requires handle abstraction.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-Following modes of operations are supported
-**Input or Output**
-Each gpio pin can be configured as either input: GPIO_CFG_INPUT or
-output: GPIO_CFG_OUTPUT. If it is configured as an output then pin
-level can be additionally configured
-
-**Interrupt support**
-Each gpio pin can be configured to generate interrupts based on event
-type GPIO_CFG_IN_INT_XXX configuration. To generate interrupt, gpio
-pin has to be configured as input pin.
-
-.. rubric:: Driver Configuration
-   :name: driver-configuration-gpio
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All board specific configurations like enabling clock and pin-mux are
-required before calling any driver APIs. By default Board_Init() API
-available under board module supports all initialization sequence for TI
-supported EVMs. In addition it initializes UART instance for
-Console/STDIO. Refer `Processor SDK RTOS Board
-Support <index_board.html#board-support>`__ for additional
-details.
-
-.. rubric:: **GPIO Configuration Structure**
-   :name: gpio-configuration-structure
-
-GPIO_soc.c binds driver with hardware attributes on the board.
-Hardware attributes includes base address, interrupt number etc. GPIO
-pin behavior can be configured statically, or alternatively
-dynamically during runtime.
-
-GPIO_init () API triggers all static configuration information available
-through hardware attributes. Once initialization is complete additional
-APIs can be used to configure and access pins.
-
-APIs
-^^^^^
-
-API reference for Application:
-
-.. code-block:: c
-
-    #include <ti/drv/gpio/GPIO.h>
-
-Below sequence indicates API calling sequence for a simple use case of
-LED toggling
-
-.. code-block:: c
-
-    ...
-    Board_init(boardCfg);
-    GPIO_init();
-    While(1)
-    {
-    GPIO_write(Board_LED1, GPIO_PIN_VAL_HIGH);
-    Delay();
-    GPIO_write(Board_LED1, GPIO_PIN_VAL_LOW);
-    Delay();
-    }
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-Refer SDK Release Note for GPIO support across different EVMs.
-
-+-------------------+-----------------------+-----------------------+---------------------+---------------------+
-|       Name        |      Description      || Expected Results     | SoC Supported       | Build Type          |
-+===================+=======================+=======================+=====================+=====================+
-| GPIO_LedBlink     | Simple example        || Following LED        |    AM335x,          | CCS project         |
-|                   | demonstrating LED     | blinks based on EVM   |    AM437x,          |                     |
-|                   | Toggling              | being used.           |    AM571x,          |                     |
-|                   |                       |                       |    AM572x,          |                     |
-|                   |                       || **AM335x             |    AM574x,          |                     |
-|                   |                       | ICEv2**:              |    k2g,             |                     |
-|                   |                       | USER  LED 1           |    k2hk,            |                     |
-|                   |                       |                       |    k2l,             |                     |
-|                   |                       || **AM437x             |    k2e,             |                     |
-|                   |                       | EVM**:                |    c6657,           |                     |
-|                   |                       | USER  LED 1           |    c6678,           |                     |
-|                   |                       |                       |    omapl137,        |                     |
-|                   |                       || **AM572x IDK** :     |                     |                     |
-|                   |                       | STATUS LED 1 Yellow   +---------------------+---------------------+
-|                   |                       | **AM572x GP           |    am65xx           | makefile            |
-|                   |                       | EVM** : USER LED1     |    j721e            |                     |
-|                   |                       | **AM574x IDK** :      |                     |                     |
-|                   |                       | STATUS LED 1 Yellow   |                     |                     |
-|                   |                       | **AM572x GP           |                     |                     |
-|                   |                       | EVM** : USER LED1     |                     |                     |
-|                   |                       | **AM571x IDK** :      |                     |                     |
-|                   |                       | Industrial LED 3      |                     |                     |
-|                   |                       | Red                   |                     |                     |
-|                   |                       |                       |                     |                     |
-|                   |                       || **K2H EVM:**         |                     |                     |
-|                   |                       | USER LED 2 Blue       |                     |                     |
-|                   |                       |                       |                     |                     |
-|                   |                       || **K2E EVM:**         |                     |                     |
-|                   |                       | USER LED 1 Blue       |                     |                     |
-|                   |                       |                       |                     |                     |
-|                   |                       || **K2G EVM:**         |                     |                     |
-|                   |                       | USER LED 1 Yellow     |                     |                     |
-|                   |                       |                       |                     |                     |
-|                   |                       || **AM65xx EVM:**      |                     |                     |
-|                   |                       | USER LD16, LD17       |                     |                     |
-|                   |                       |                       |                     |                     |
-|                   |                       || **J721E EVM:**       |                     |                     |
-|                   |                       | USER LED 1            |                     |                     |
-|                   |                       |                       |                     |                     |
-+-------------------+-----------------------+-----------------------+---------------------+---------------------+
-
-.. note::
-
-   There are no user mode LEDs directly connected to GPIO pins on K2L, C6678 and C6657 EVMs.
-
-Building GPIO examples
-----------------------
-
--  Makefile based examples and dependent libraries can be built from the top level or module level GPIO makefile, refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__  for details of how to setup the build environment. Once you have setup the build environment, issue the following commands:
-::
-
-   To build and clean libs/apps from top-level makefile:
-   cd <pdk>/packages
-   make gpio
-   make gpio_clean
-
-   To build and clean libs/apps from module-level makefile:
-   cd <pdk>/packages/ti/drv/gpio
-   make all
-   make clean
-
-
--  RTSC CCS project based examples are built from CCS
-::
-
-   cd <pdk>/packages
-   ./pdkProjectCreate.sh [soc] [board] [endian] gpio [project type] [processor] [SECUREMODE=<yes/no>]
-   Import and build CCS Project from  <pdk>/packages/MyExampleProjects/
-
-FAQ
-----------------------
-
-**Is there any example using GPIO as input**
-
-Please refer to `RTOS Customization: using an external input to trigger an interrupt
-on AM57x <index_how_to_guides.html#rtos-customization-using-an-external-input-to-trigger-an-interrupt-on-am57x>`_ for details.
-
-Additional References
----------------------
-
-+----------------------------+-----------------------------------+
-| **Document**               | **Location**                      |
-+----------------------------+-----------------------------------+
-| API Reference Manual       | $(TI_PDK_INSTALL_DIR)/packages/ti |
-|                            | /drv/gpio/docs/doxygen/html/index |
-|                            | .html                             |
-+----------------------------+-----------------------------------+
-| Release Notes              | $(TI_PDK_INSTALL_DIR)/packages/ti |
-|                            | /drv/gpio/docs/ReleaseNotes_GPIO  |
-|                            | _LLD.pdf                          |
-+----------------------------+-----------------------------------+
-
-|
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_GPMC.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_GPMC.rst
deleted file mode 100644
index b4c29c6fc..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_GPMC.rst
+++ /dev/null
@@ -1,180 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_GPMC
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The general-purpose memory controller (GPMC) is an unified memory
-controller dedicated to interfacing external memory devices:
-
--  Asynchronous SRAM-like memories and application-specific integrated
-   circuit (ASIC) devices
--  Asynchronous, synchronous, and page mode (only available in
-   non-multiplexed mode) burst NOR flash devices
--  NAND Flash
-
-Driver supports two types of transfers with data path to external memory
-device configured to be 16- or 8-bit:
-
--  Read
--  Write
-
-| In addition driver supports following modes of operation:
-
--  **GPMC_MODE_BLOCKING:** By default, driver operates in blocking mode.
-   In blocking mode, a Task’s code execution is blocked until
-   transaction is complete. This ensures only one transaction operates
-   at a given time. Driver supports both interrupt or non-interrupt
-   based blocking modes.
--  **GPMC_MODE_CALLBACK** In callback mode, an GPMC transaction
-   functions asynchronously, which means that it does not block a Task’s
-   code execution. After an GPMC transaction is complete, GPMC driver
-   calls a user-provided hook function. Only interrupt based callback is
-   supported.
-
-In NAND flash mode, driver supports following ECC algorithms:
-
--  BCH code 8-bit
--  HAMMING code 1-bit
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All the board specific configurations eg:enabling and pin-mux of GPMC
-pins should be performed before calling any driver APIs.By default
-Board_Init() API supports all initialization sequence for TI supported
-EVMs.Refer `Processor SDK RTOS Board Support <index_board.html#board-support>`__
-for additional details.
-
-Once the board specific configuration is complete driver API GPMC_init()
-can be called to initialize driver
-
-.. rubric:: **GPMC Configuration Structure**
-   :name: gpmc-configuration-structure
-
-GPMC_soc.c file binds driver with hardware attributes on the board
-through GPMC_config structure. This structure must be provided to GPMC
-driver. It must be initialized before the GPMC_init() function is called
-and cannot be changed afterwards. For details about the individual
-fields of this structure, see the Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\gpmc\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/gpmc/GPMC.h>
-
- Sample code for initiating GPMC transaction:
-
-.. code-block:: c
-
-    ...
-    Board_init(boardCfg);
-    ...
-    ...
-    gpmc = GPMC_open(peripheralNum, &gpmcParams);
-    ...
-    ...
-
-    /* Initiate GPMC transfers. Refer Example for details
-    */
-    transferOK = GPMC_transfer(gpmc, &gpmcTransaction);
-    if (!transferOK) {
-    /* GPMC transaction failed */
-    } 
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-Refer Release Note for GPMC support across different EVMs
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | | Description         | Expected Results      |
-+=======================+=======================+=======================+
-| GPMC NOR/NAND Read    | | Simple example to   | Following prints will |
-| Example Application   |   read data from GPMC | come on console based |
-|                       |   NOR/NAND flash on   | on pass/fail          |
-|                       |   board.              | criteria:             |
-|                       |                       |                       |
-|                       |                       | **Pass criteria:**    |
-|                       |                       |                       |
-|                       |                       | GPMC flash device ID: |
-|                       |                       | 0x##, manufacturer    |
-|                       |                       | ID: 0x##              |
-|                       |                       |                       |
-|                       |                       | GPMC flash read test  |
-|                       |                       | passed.               |
-|                       |                       |                       |
-|                       |                       | All tests have        |
-|                       |                       | passed.               |
-+-----------------------+-----------------------+-----------------------+
-| GPMC NOR/NAND test    | | Driver Unit Test    | Following prints will |
-| application           |   application to test | come on console based |
-|                       |   GPMC NOR/NAND flash | on pass/fail          |
-|                       |   read/erase/write    | criteria:             |
-|                       |                       |                       |
-|                       |                       | **Pass criteria:**    |
-|                       |                       |                       |
-|                       |                       | GPMC flash device ID: |
-|                       |                       | 0x##, manufacturer    |
-|                       |                       | ID: 0x##              |
-|                       |                       |                       |
-|                       |                       | GPMC flash block      |
-|                       |                       | erase test passed.    |
-|                       |                       |                       |
-|                       |                       | GPMC flash write test |
-|                       |                       | passed.               |
-|                       |                       |                       |
-|                       |                       | GPMC flash read test  |
-|                       |                       | passed.               |
-|                       |                       |                       |
-|                       |                       | All tests have        |
-|                       |                       | passed.               |
-+-----------------------+-----------------------+-----------------------+
-|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-
-.. note::
-
-   1. GPMC Test Application supports write test, by default write test is
-      disabled, user can enable the write test by defining
-      TEST_GPMC_FLASH_WRITE in test/src/GPMC_board.h.
-
-   2. In GPMC_Test_icev2AM335x, J5 pin2 & 3 should be shorted on
-      iceV2AM335x board in order to test GPMC NOR flash.
-
-   3. In GPMC_Test_evmAM437x, J2 pin1 & 2 should NOT be shorted on
-   evmAM437x board in order to test GPMC NAND flash.
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\gpmc\\docs\\doxygen\\html\\index |
-|                                   | .html                                   |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\gpmc\\docs\\ReleaseNotes_GPMC_   |
-|                                   | LLD.pdf                                 |
-+-----------------------------------+-----------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_HYPLNK.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_HYPLNK.rst
deleted file mode 100644
index bad61d4f8..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_HYPLNK.rst
+++ /dev/null
@@ -1,283 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_HYPLNK
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-Hyperlink is a point-to-point peripheral. Each device has equal
-capability to operate on the address space of the other device. This
-also means that there is no complex enumeration in order to get started.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-The LLD is intended to bring up the Hyperlink peripheral and open memory
-mappings.
-
-.. rubric:: Interrupts
-   :name: interrupts
-
-There is an interrupt generation example (in
-PDK_INSTALL_DIR/packages/ti/drv/hyplnk/example/cicInterruptExample)
-which maps and pokes the other device's CIC (Chip/SOC level interrupt
-controller) to generate interrupts for data transfers.
-
-The PDK_INSTALL_DIR/packages/ti/drv/hyplnk/example/common/hyplnkIsr.c
-monitors local interrupts to detect fatal errors. It can also be used
-for IO interrupts, but there is only one output event that has to be
-demuxed. Thus for multicore orthogonality, the cicInterruptExample is
-often better example (because each destination core can have completely
-independent interrupts).
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The driver itself is entirely configured via API at runtime. However,
-the examples are configured using compiler flags that are in
-hyplnkPlatCfg.h and hyplnkLLDCfg.h.
-
-.. rubric:: Hyperlink configuration structure
-   :name: hyperlink-configuration-structure
-
-The hyplnk_device.c binds the driver to the hardware on the board. It is
-passed into the driver via the call to Hyplnk_init().
-
-APIs
-^^^^^
-
-.. rubric:: API Call Flow
-   :name: api-call-flow
-
-The API call flow is covered in
-example\memoryMappedExample\src\hyplnkExample.
-
-They key parts are:
-
-#. Initialize the LLD via Hyplnk_init().
-#. Configure PLL, PSC and memories via hyplnkExampleSysSetup() which is
-   all example code
-#. Install ISR(s)
-#. Enable the peripheral using sequence in hyplnkExamplePeriphSetup()
-#. Open memory maps using hyplnkExampleAddrMap() as a guide
-#. Exchange data with memcpy or EDMA using mapped address (returned from
-   hyplnkExampleAddrMap).
-
-|
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-Hyperlink/hyplnk is supported only on Keystone devices. It is available
-on 6678, 6657, K2H, K2K, K2E. All examples can be used in either
-loopback (on any EVM without any special cables or breakout cards) or
-with two boards. For 6678 or 6657, the required cable is
-`HL5CABLE <https://store.ti.com/HL5CABLE-Hyperlink-Cable-P2888.aspx>`__.
-For K2H/K2K/K2E, the breakout card is
-`RTM-BOCRT <http://www.ti.com/devnet/docs/catalog/endequipmentproductfolder.tsp?actionPerformed=productFolder&productId=17440>`__,
-and the cable is also required. Below is a picture showing how a K2H EVM
-is connected to a 6678 EVM via breakout card and cable.
-
-
-.. Image:: /images/K2-k1-hyplnk.jpg
-
-+-----------------+-----------------+-----------------+-----------------+
-| Name            | Description     | EVM             | Expected        |
-|                 |                 | Configuration   | Results         |
-+=================+=================+=================+=================+
-| memoryMappedExa | Memory mapped   | Loopback runs   | Link is         |
-| mple            | data exchange   | without any     | established and |
-|                 | with loopback   | extra hardware. | data is         |
-|                 | or 2 devices    | See below for   | exchanged.      |
-|                 |                 | details on      |                 |
-|                 |                 | configuring     |                 |
-|                 |                 | board-to-board. |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| cicInterruptExa | CIC-based       | Loopback runs   | Interrupts are  |
-| mple            | interrupt       | without any     | sent between    |
-|                 | exchange.       | extra hardware. | ARM Linux       |
-|                 |                 | See below for   | Userspace and   |
-|                 |                 | details on      | DSPs.           |
-|                 |                 | configuring     |                 |
-|                 |                 | board-to-board. |                 |
-+-----------------+-----------------+-----------------+-----------------+
-
-.. rubric:: Setup of multiple EVMs with one instance of CCS
-   :name: setup-of-multiple-evms-with-one-instance-of-ccs
-
-This is only needed for 2 board use cases. See
-`Multi-Emulator_Debug_with_CCS <http://processors.wiki.ti.com/index.php/Multi-Emulator_Debug_with_CCS>`__
-for general configuration of multiple EVMs/emulators within one instance
-of CCS.
-
-.. rubric:: Detailed instructions to run memoryMappedExample
-   :name: detailed-instructions-to-run-memorymappedexample
-
-If running with one board, enable loopback via uncommenting
-hyplnk_EXAMPLE_LOOPBACK in
-PDK_INSTALL_DIR/packages/ti/drv/hyplnk/example/common/hyplnkLLDCfg.h.
-
-Compile the project for the specific device/evm in use.
-
-For loopback: Load the example with hyplnk_EXAMPLE_LOOPBACK definined
-onto one board and run. The results should be as below.
-
-For 2 board: Make sure the both boards configuration match each other by
-checking
-PDK_INSTALL_DIR/packages/ti/drv/hyplnk/example/common/hyplnkLLDCfg.h:
-
-::
-
-    hyplnk_EXAMPLE_PORT --> which port to use for K2H/K2K/K2E
-    hyplnk_EXAMPLE_ALLOW_x_LANES --> 0, 1 or 4 lanes
-    hyplnk_EXAMPLE_SERRATE_xxpxxx --> serdes rate setup
-
-Load the same example on both boards. It is fulling symmetric. No
-special configuration is needed to distinguish side A and side B. Each
-side should generate output similar to below.
-
-.. rubric:: Detailed instructions to run cicInterruptExample
-   :name: detailed-instructions-to-run-cicinterruptexample
-
-This only works on devices with A15 running Linux (K2H, K2K, K2E). See
-PDK_INSTALL_DIR/packages/ti/drv/hyplnk/example/cicInterruptExample/Readme.txt
-for instructions.
-
-.. rubric:: Sample example output
-   :name: sample-example-output
-
-This came from k2h device running in loopback.
-
-::
-
-    Version #: 0x02010005; string HYPLNK LLD Revision: 02.01.00.05:Dec 24 2015:17:48:28
-    About to do system setup (PLL, PSC, and DDR)
-    Power domain is already enabled.  You probably re-ran without device reset (which is OK)
-    Constructed SERDES configs: PLL=0x00000228; RX=0x0046c495; TX=0x000ccf95
-    system setup worked
-    About to set up HyperLink Peripheral
-    ============================Hyperlink Testing Port 0
-    ========================================== begin registers before initialization ===========
-    Revision register contents:
-      Raw    = 0x4e902101
-    Status register contents:
-      Raw        = 0x00003004
-    Link status register contents:
-      Raw       = 0x00000000
-    Control register contents:
-      Raw             = 0x00000000
-    Control register contents:
-      Raw        = 0x00000000
-    ============== end registers before initialization ===========
-    Hyperlink Serdes Common Init Complete
-    Hyperlink Serdes Lane 0 Init Complete
-    Hyperlink Serdes Lane 1 Init Complete
-    Hyperlink Serdes Lane 2 Init Complete
-    Hyperlink Serdes Lane 3 Init Complete
-    ============== begin registers after initialization ===========
-    Status register contents:
-      Raw        = 0x04402005
-    Link status register contents:
-      Raw       = 0xfdf0bdf0
-    Control register contents:
-      Raw             = 0x00006206
-    ============== end registers after initialization ===========
-    Waiting 5 seconds to check link stability
-    Precursors 1
-    Postcursors: 19
-    Link seems stable
-    About to try to read remote registers
-    ============== begin REMOTE registers after initialization ===========
-    Status register contents:
-      Raw        = 0x0440080f
-    Link status register contents:
-      Raw       = 0xfdf0bdf0
-    Control register contents:
-      Raw             = 0x00006202
-    ============== end REMOTE registers after initialization ===========
-    Peripheral setup worked
-    About to read/write once
-    Single write test passed
-    About to pass 65536 tokens; iteration = 0
-    === this is not an optimized example ===
-    Link Speed is 4 * 3.125 Gbps
-    Passed 65536 tokens round trip (read+write through hyplnk) in 16829 Mcycles
-    Approximately 256799 cycles per round-trip
-    === this is not an optimized example ===
-    Checking statistics
-    About to pass 65536 tokens; iteration = 1
-    === this is not an optimized example ===
-    Link Speed is 4 * 3.125 Gbps
-    Passed 65536 tokens round trip (read+write through hyplnk) in 16829 Mcycles
-    Approximately 256799 cycles per round-trip
-    === this is not an optimized example ===
-    Checking statistics
-    About to pass 65536 tokens; iteration = 2
-    .
-    .
-    .
-
-Debug FAQ
----------
-
-#. If it seems to not work, check for lError and rError in the status
-   register (hyplnkStatusReg_s). If these appear, it means double ecc
-   error occurred and the link is non functional. This is fatal error.
-   Next look at hyplnkECCErrorReg_s for single (corrected) bit errors.
-   After startup these should increment slowly (order of minutes, hours,
-   days, not seconds or less). If they are incrementing quickly (several
-   times per minute or second), then it means the SERDES coefficients
-   should be calibrated by following the Keystone SERDES UG. See
-   references section.
-#. Note that if the link goes down (uncorrectable ECC error) it is
-   possible for the entire interconnect to lock up. If this occurs, it
-   will not be possible to access any memory even through the JTAG
-   interface (CCS will return errors instead of reading memory, and
-   often disconnect the target). Thus the primary cause of this lockup
-   should be avoided by carefully following the shutdown/reset
-   requirement in section 2.9 of the Hyperlink UG (which is to invoke
-   serial stop, and wait for it to take effect before resetting either
-   endpoint).
-#. Another workaround for ECC single errors is to lower link rate and/or
-   reduce to 1 lane. This can be done by adjusting the commented defines
-   in
-   PDK_INSTALL_DIR/packages/ti/drv/hyplnk/example/common/hyplnkLLDCfg.h.
-
-Additional References
----------------------
-
-Additional documentation can be found in:
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| Hardware Peripheral Hyperlink     | `User                                   |
-| Users Guide                       | Guide <http://www.ti.com/lit/spru       |
-|                                   | gw8>`__                                 |
-+-----------------------------------+-----------------------------------------+
-| Serdes Users Guide                | `User                                   |
-|                                   | Guide <http://www.ti.com/lit/spru       |
-|                                   | ho3>`__                                 |
-+-----------------------------------+-----------------------------------------+
-| CIC Peripheral Users Guide        | `CIC User                               |
-|                                   | Guide <http://www.ti.com/lit/spru       |
-|                                   | gw4>`__                                 |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\hyplnk\\docs\\doxygen\\html\\ind |
-|                                   | ex.html                                 |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\hyplnk\\docs\\ReleaseNotes_HYP   |
-|                                   | LNK_LLD.pdf                             |
-+-----------------------------------+-----------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_I2C.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_I2C.rst
deleted file mode 100644
index 1ca0261df..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_I2C.rst
+++ /dev/null
@@ -1,300 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_I2C
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-I2C module provides an interface to any I2C-bus-compatible device
-accessible via I2C serial bus. External components attached to I2C bus
-can serially transmit/receive data to/from the CPU through two-wire
-interface. Driver supports three types of transfers in both I2C controller
-mode and target mode
-
--  Read
--  Write
--  Write followed by read
-
-In addition driver supports following modes of operation:
-
--  **I2C_MODE_BLOCKING:** By default, driver operates in blocking mode.
-   In blocking mode, a Task’s code execution is blocked until
-   transaction is complete. This ensures only one transaction operates
-   at a given time. Driver supports both interrupt or non-interrupt
-   based blocking modes.
--  **I2C_MODE_CALLBACK** In callback mode, an I2C transaction functions
-   asynchronously, which means that it does not block a Task’s code
-   execution. After an I2C transaction is complete, I2C driver calls a
-   user-provided hook function. Only interrupt based callback is
-   supported.
-
-.. note::
-
-   If I2C peripheral is in reset during a transfer, it can cause the I2C
-   bus to hang. I2C V0 IP (Keystone SoCs) does not have hardware support to
-   recover the I2C bus from hanging, user needs to power cycle the board as
-   a workaround. For I2C V1 IP (AM3/4/5 SoCs), the application can call
-   I2C_control() API and use I2C_CMD_RECOVER_BUS to recover the I2C bus.
-
-
-.. rubric::  Firmware
-   :name: firmware
-
-TI PRU-ICSS cores (Programmable Real-Time Unit Industrial Communication
-Subsystem) is firmware programmable and can take on various
-personalities. Processor SDK package includes I2C Firmware support.
-Refer `I2C FW <index_pru_icss_fw.html#pru-icss-i2c>`__ for
-additional details.
-
-|
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All the board specific configurations eg:enabling and pin-mux of I2C
-pins should be performed before calling any driver APIs.By default
-Board_Init() API supports all initialization sequence for TI supported
-EVMs.Refer `Processor SDK RTOS Board
-Support <index_board.html#board-support>`__ for additional
-details.
-
-Once the board specific configuration is complete driver API I2C_init()
-can be called to initialize driver
-
-.. rubric::  **I2C Configuration Structure**
-   :name: i2c-configuration-structure
-
-I2C_soc.c file binds driver with hardware attributes on the board
-through I2C_config structure. This structure must be provided to I2C
-driver. It must be initialized before the I2C_init() function is called
-and cannot be changed afterwards. For details about the individual
-fields of this structure, see the Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\i2c\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/i2c/I2C.h>
-
- Sample code for initiating I2C transaction:
-
-::
-
-    ...
-    Board_init(boardCfg);
-    ...
-    I2C_socGetInitCfg(peripheralNum, &i2c_cfg);
-    ...
-    I2C_socSetInitCfg(peripheralNum, &i2c_cfg);
-    ...
-    i2c = I2C_open(peripheralNum, &i2cParams);
-    ...
-    ...
-
-    /* Initiate I2C transfers. Refer Example for details
-    */
-    I2C_transactionInit(&i2cTransaction);
-    transaction.controllerMode   = true;
-    ...
-    ...
-    transferOK = I2C_transfer(i2c, &i2cTransaction);
-    if (transferOK != I2C_STS_SUCCESS) {
-    /* I2C transaction failed */
-    } 
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-Refer Release Note for I2C support across different EVMs
-
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-|| Name                 || Description          ||  Expected Results    | SoC Supported       | Build Type          |
-+=======================+=======================+=======================+=====================+=====================+
-| I2C_EepromRead        || Simple example to    || Following prints will|    AM335x,          | CCS project         |
-| Example application   | read fixed number     |  come on console based|    AM437x,          |                     |
-|                       | of bytes from         |  on pass/fail         |    AM571x,          |                     |
-|                       | EEPROM on board and   |  criteria:            |    AM572x,          |                     |
-|                       | compares it with      ||                      |    AM574x,          |                     |
-|                       | expected data.        || **Pass criteria:**   |    k2g,             |                     |
-|                       |                       ||                      |    k2hk,k2l,k2e,k2l |                     |
-|                       |                       || EEPROM data matched  |    c6657,c6678      |                     |
-|                       |                       |   All tests have      |    omapl137,        |                     |
-|                       |                       |   passed.             |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| I2C_TestApplication   || Driver Unit Test     || Following prints will|    AM335x,          | CCS project         |
-|                       | application for       |  come on console based|    AM437x,          |                     |
-|                       | additional I2C        |  on pass/fail         |    AM571x,          |                     |
-|                       | speed and other tests |  criteria:            |    AM572x,          |                     |
-|                       |                       ||                      |    AM574x,          |                     |
-|                       |                       || **Pass criteria:**   |    k2g,             |                     |
-|                       |                       ||                      |    k2hk,            |                     |
-|                       |                       || I2C Test: 100Kbps:   |    k2l,             |                     |
-|                       |                       |  PASS                 |    k2e,             |                     |
-|                       |                       ||                      |    c6657,           |                     |
-|                       |                       || I2C Test: 400Kbps:   |    c6678,           |                     |
-|                       |                       |  PASS                 |    omapl137,        |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || I2C Test: timeout    +---------------------+---------------------+
-|                       |                       |  test passed          |    am65xx           | makefile            |
-|                       |                       ||                      |    j721e            |                     |
-|                       |                       || All tests have       |                     |                     |
-|                       |                       |  passed.              |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| I2C_SMP_Test          || Driver Unit Test     || Following prints will|   am572x-evm        | CCS project         |
-| Application           | application for       |  come on console based|                     |                     |
-|                       | additional I2C        |  on pass/fail         |                     |                     |
-|                       | speed and other tests |  criteria:            |                     |                     |
-|                       | with SMP enabled.     ||                      |                     |                     |
-|                       | (A15 and A53 cores)   || **Pass criteria:**   |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || I2C Test: 100Kbps:   |                     |                     |
-|                       |                       |  PASS                 |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || I2C Test: 400Kbps:   |                     |                     |
-|                       |                       |  PASS                 |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || I2C Test: timeout    +---------------------+---------------------+
-|                       |                       |  test passed          |    am65xx           | makefile            |
-|                       |                       ||                      |    j721e            |                     |
-|                       |                       || All tests have       |                     |                     |
-|                       |                       |  passed.              |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| I2C_TemperatureSensor || Example to get the   || Following prints will|    AM572x,          | CCS project         |
-|                       | temperature value     |  come on console based|                     |                     |
-|                       | from the temperature  |  on pass/fail         |                     |                     |
-|                       | sensor and displays   |  criteria:            |                     |                     |
-|                       | on the serial         ||                      |                     |                     |
-|                       | console.              || **Pass criteria:**   |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || Temperature =        |                     |                     |
-|                       |                       |  "value in            |                     |                     |
-|                       |                       |  centigrades" C       |                     |                     |
-|                       |                       |  All tests have       |                     |                     |
-|                       |                       |  passed.              |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| I2C_controller/target || Application          || Following prints will|    AM572x,          | CCS project         |
-|                       | demonstrates          |  come on console based|    AM574x,          |                     |
-|                       | controller/target     |  on pass/fail         |    k2g,             |                     |
-|                       | transfer of I2C.      |  criteria:            |    omapl138,        |                     |
-|                       | Application use       ||                      |                     |                     |
-|                       | case requires two     || **Pass criteria:**   |                     |                     |
-|                       | EVMs. One acts as     ||                      |                     |                     |
-|                       | Controller and the    || All tests have       |                     |                     |
-|                       | other as target. I2C  | passed.               |                     |                     |
-|                       | connections           |                       |                     |                     |
-|                       | information and       |                       |                     |                     |
-|                       | addtional details     |                       |                     |                     |
-|                       | are as follows:       |                       |                     |                     |
-|                       ||                      |                       |                     |                     |
-|                       || AM57xx boards I2C bus|                       |                     |                     |
-|                       | connection on J9      |                       |                     |                     |
-|                       | (controller board <-->|                       |                     |                     |
-|                       | target board)         |                       |                     |                     |
-|                       ||                      |                       |                     |                     |
-|                       || pin22 (SCL)<-->      |                       |                     |                     |
-|                       | pin22 (SCL)           |                       |                     |                     |
-|                       ||                      |                       |                     |                     |
-|                       || pin24 (SDA)<--> pin24|                       |                     |                     |
-|                       | (SDA)                 |                       |                     |                     |
-|                       ||                      |                       |                     |                     |
-|                       || pin21 (GND)<--> pin21|                       |                     |                     |
-|                       | (GND)                 |                       |                     |                     |
-|                       ||                      |                       |                     |                     |
-|                       || K2G boards I2C bus   |                       |                     |                     |
-|                       | connection on J12     |                       |                     |                     |
-|                       | (controller board <-->|                       |                     |                     |
-|                       | target board)         |                       |                     |                     |
-|                       | pin28 (SCL)<-->       |                       |                     |                     |
-|                       | pin28 (SCL)           |                       |                     |                     |
-|                       | pin30 (SDA)<-->       |                       |                     |                     |
-|                       | pin30 (SDA)           |                       |                     |                     |
-|                       | pin50 (GND)<-->       |                       |                     |                     |
-|                       | pin50 (GND)           |                       |                     |                     |
-|                       ||                      |                       |                     |                     |
-|                       |                       |                       |                     |                     |
-|                       || OMAPL138/C6748       |                       |                     |                     |
-|                       | boards I2C bus        |                       |                     |                     |
-|                       | connection on J15     |                       |                     |                     |
-|                       | (controller board <-->|                       |                     |                     |
-|                       | target board)         |                       |                     |                     |
-|                       | pin13 (SCL)<-->       |                       |                     |                     |
-|                       | pin13 (SCL)           |                       |                     |                     |
-|                       | pin15 (SDA)<-->       |                       |                     |                     |
-|                       | pin15 (SDA)           |                       |                     |                     |
-|                       | pin35 (GND)<-->       |                       |                     |                     |
-|                       | pin35 (GND)           |                       |                     |                     |
-|                       ||                      |                       |                     |                     |
-|                       || Run                  |                       |                     |                     |
-|                       | "I2C_Target_<BoardTy  |                       |                     |                     |
-|                       | pe>_<arm/c66x/m4>Test |                       |                     |                     |
-|                       | Project"              |                       |                     |                     |
-|                       | first on Target EVM   |                       |                     |                     |
-|                       | and then              |                       |                     |                     |
-|                       | "I2C_Controller_<Boar |                       |                     |                     |
-|                       | dType>_<arm/c66x/m4>  |                       |                     |                     |
-|                       | TestProject"          |                       |                     |                     |
-|                       | on Controller EVM.    |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-
-.. note::
-
-   I2C_Test Application supports write test on Keystone II EVMs, by default
-   write test is disabled, user can enable the write test by defining
-   I2C_EEPROM_WRITE_ENABLE in test/eeprom_read/src/I2C_board.h.
-   I2C_TemperatureSensor Application is supported only on AM572x GP EVM.
-
-Building I2C examples
-----------------------
-
--  Makefile based examples and dependent libraries can be built from the top level or module level I2C makefile, refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__  for details of how to setup the build environment. Once you have setup the build environment, issue the following commands:
-::
-
-   To build and clean libs/apps from top-level makefile:
-   cd <pdk>/packages
-   make i2c
-   make i2c_clean
-
-   To build and clean libs/apps from module-level makefile:
-   cd <pdk>/packages/ti/drv/i2c
-   make all
-   make clean
-
-
--  RTSC CCS project based examples are built from CCS
-::
-
-   cd <pdk>/packages
-   ./pdkProjectCreate.sh [soc] [board] [endian] i2c [project type] [processor] [SECUREMODE=<yes/no>]
-   Import and build CCS Project from  <pdk>/packages/MyExampleProjects/
-
-
-Additional References
----------------------
-
-+-----------------------+------------------------------------------+
-| **Document**          |  **Location**                            |
-+-----------------------+------------------------------------------+
-| API Reference Manual  | $(TI_PDK_INSTALL_DIR)\\packages\\ti      |
-|                       | \\drv\\i2c\\docs\\doxygen\\html\\index.  |
-|                       | html                                     |
-+-----------------------+------------------------------------------+
-| Release Notes         | $(TI_PDK_INSTALL_DIR)\\packages\\ti      |
-|                       | \\drv\\i2c\\docs\\ReleaseNotes_I2C_LL    |
-|                       | D.pdf                                    |
-+-----------------------+------------------------------------------+
-
-|
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_ICSS_EMAC_LLD_FW.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_ICSS_EMAC_LLD_FW.rst
deleted file mode 100644
index 12932090b..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_ICSS_EMAC_LLD_FW.rst
+++ /dev/null
@@ -1,289 +0,0 @@
-Introduction
--------------
-
-The ICSS_EMAC (industrial communications subsystem Ethernet Media Access
-Controller) driver provide APIs to transmit and receive packets with a
-firmware based Ethernet switch that has been implemented on TI’s
-PRU-ICSS (Programmable Real-Time Unit Subsystem and Industrial
-Communication SubSystem) 32-bit RISC cores.
-
-|
-
-.. rubric::  Software Architecture
-   :name: software-architecture
-
-The ICSS EMAC low level driver can be partitioned into the following:
-
--  Driver software running on the host processor, provides a well
-   defined set of APIs to configure the driver, send packets to the
-   firmware and receive packet from the firmware.
--  Firmware which implements a 2 port ethernet switch supporting 802.1d
-   @100 Mbps. This runs on the TI-PRU-ICSS cores.
-
-|
-
-.. rubric::  Driver Features
-   :name: driver-features
-
-ICSS_EMAC LLD implements following:
-
--  Rx - Copying packet received from firmware and providing it to TCP/IP
-   stack
--  Tx - Providing packet from TCP/IP stack to firmware
--  Learning/Forwarding Data Base
--  Storm Prevention implementation
--  Host Statistics implementation
--  TCP/IP stack related initialization
--  Configuring IP address
--  ARM interrupt management
-
-
-For details of the driver, please refer to
-  `[1] <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_ICSS-EMAC-Design>`__
-
-|
-
-User Interface
-----------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-| **Board Specific Configuration**
-| All the board specific configurations eg: enabling clock and pin-mux
-  for GPIO/MDIP/IEP pins should be performed before calling any driver
-  APIs. By default Board_Init() API supports all initialization sequence
-  for TI supported EVMs. In addition it initializes UART instance for
-  Console/STDIO.Refer `Processor SDK RTOS Board
-  Support <index_board.html#board-support>`__ for
-  additional details.Once board specific configuration is complete 
-  driver APIS can be invoked.
-
-|
-| **ICSS_EMAC Configuration Structure**
-| The icss_emacSoc.c file contains the declaration of the hardware
-  attributes corresponding to the ICSS_EMAC subsystem. Hardware
-  attributes includes base address of various sub-subsystems required by
-  the the ICSS_EMAC LLD. This configuration is required and needs to be
-  passed in as part of the ICSS_EMAC Handle when calling the
-  icss_emacInit API. For details about individual fields of this
-  structure, see the Doxygen help by opening
-  PDK_INSTALL_DIR\\packages\\ti\\drv\\icss_emac\\docs\\doxygen\\html\\index.html.
-
-|
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/icss_emac/icss_emacDrv.h>
-
-.. rubric:: API Call Flow
-   :name: api-call-flow
-
-The below sequence indicates the calling sequence of ICSS_EMAC driver
-APIs for a use case of an EMAC example which implements single Ethernet
-MAC using PRU-ICSS Instance 2, ETH0. For additional details refer
-example inside package
-
-::
-
-    ...
-    Board_init(cfg);
-
-    /* Perform MDIO init */
-    ICSS_EMAC_testMdioInit(CSL_MPU_PRUSS2_U_MII_MDIO_REGS);
-
-::
-
-    /* Create handle for PRUICSS instance*/
-    ICSS_EMAC_testPruIcssHandle2= PRUICSS_create(pruss_config,2);
-
-    /* Setup crossbar configuration to receive PRU-ICSS interrupts and map them to A15 (illustration for PRU2ETH0) */
-    CSL_xbarDspIrqConfigure(..);  /* Link ISR */
-    CSL_xbarDspIrqConfigure(..);  /* RX PKT ISR */
-    CSL_xbarDspIrqConfigure(..);  /* TX PKT ISR */
-
-::
-
-    /*Initialize driver */
-    ...
-    ICSS_EmacInit(..);
-
-    /* Register callbacks for RX/TX, Link Interrupts, these are called in context of ISR */
-    ICSS_EmacRegisterPort0ISRCallback(..);
-    ICSS_EmacRegisterHwIntRx(..);
-    ICSS_EmacRegisterHwIntTx(..);
-
-::
-
-    /* Enable interrupts for RX/TX/Link*/
-    ICSS_EMAC_testInterruptInit(ICSS_EMAC_testHandle2);
-
-::
-
-    /* Enable Link Interrupt in MDIO sub-system */
-    ICSS_EMAC_testMdioEnableLinkInterrupt(..);
-
-::
-
-    /* At this point, ICSS_EMAC LLD APIs can be called */
-    </syntaxhighlight>
-
-.. rubric::  Firmware
-   :name: firmware
-
-TI PRU-ICSS cores (Programmable Real-Time Unit Industrial Communication
-Subsystem) is firmware programmable and can take on various
-personalities. Examples include an SORTE, ethernet Switch, Industrial
-protocol switch. Please refer to `ICSS-EMAC Firmwares <index_pru_icss_fw.html#pru-icss-firmware>`__ for
-further explanation.
-
-|
-
-Application
-------------
-
-Examples
-^^^^^^^^^
-
-Refer “ICSS_EMAC_<Basic/Switch>Example_<SOC>_<CPU>Testproject” for
-additional reference. Refer Release Note for ICSS_EMAC supported on
-different EVMs.
-
-
-+-----------------+-----------------+-----------------+-----------------+
-|| Name           || Description    || EVM            || Expected       |
-|                 |                 | Configuration   | Results         |
-+=================+=================+=================+=================+
-| ICSS_EMAC_Basic | EMAC Loopback   | 10/100 Mb/s     | Unit Test will  |
-| Example         | test at         | loopback cable  | print ^All      |
-|                 | PRU-ICSS        |                 | tests have      |
-|                 | EMAC PHY.       |                 | passed^ via     |
-|                 |                 |                 | UART console.   |
-|                 | | Example       |                 |                 |
-|                 |   demonstrates  |                 |                 |
-|                 |   loopback      |                 |                 |
-|                 |   capability by |                 |                 |
-|                 |   sending dummy |                 |                 |
-|                 |   broadcast     |                 |                 |
-|                 |   packet to     |                 |                 |
-|                 |   PRU-ICSS      |                 |                 |
-|                 |   instance 2,   |                 |                 |
-|                 |   ethernet port |                 |                 |
-|                 |   0 (PRU ETH0). |                 |                 |
-|                 |   Unit test     |                 |                 |
-|                 |   registers     |                 |                 |
-|                 |   receive       |                 |                 |
-|                 |   packet        |                 |                 |
-|                 |   callback      |                 |                 |
-|                 |   routine with  |                 |                 |
-|                 |   LLD to be     |                 |                 |
-|                 |   called for RX |                 |                 |
-|                 |   packet. Call  |                 |                 |
-|                 |   back routine  |                 |                 |
-|                 |   will extract  |                 |                 |
-|                 |   packet        |                 |                 |
-|                 |   received,     |                 |                 |
-|                 |   perform       |                 |                 |
-|                 |   simple memory |                 |                 |
-|                 |   comparison    |                 |                 |
-|                 |   against       |                 |                 |
-|                 |   packet sent   |                 |                 |
-|                 |   for integrity |                 |                 |
-|                 |   check. Unit   |                 |                 |
-|                 |   test will     |                 |                 |
-|                 |   iterate 10    |                 |                 |
-|                 |   times for     |                 |                 |
-|                 |   packet        |                 |                 |
-|                 |   transmission  |                 |                 |
-|                 |   and reception |                 |                 |
-|                 |   check.        |                 |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| ICSS_EMAC_Switc | Switch Loopback | 100 Mb/s        | Unit Test will  |
-| hExample        | test at         | loopback cable  | print ^All      |
-|                 | PRU-ICSS        |                 | tests have      |
-|                 | EMAC PHY.       |                 | passed^ via     |
-|                 |                 |                 | UART console.   |
-|                 | | Example       |                 |                 |
-|                 |   demonstrates  |                 |                 |
-|                 |   switch        |                 |                 |
-|                 |   learning      |                 |                 |
-|                 |   loopback      |                 |                 |
-|                 |   capability by |                 |                 |
-|                 |   sending dummy |                 |                 |
-|                 |   broadcast     |                 |                 |
-|                 |   packet to     |                 |                 |
-|                 |   PRU-ICSS      |                 |                 |
-|                 |   instance,     |                 |                 |
-|                 |   ethernet      |                 |                 |
-|                 |   port. Unit    |                 |                 |
-|                 |   test          |                 |                 |
-|                 |   registers     |                 |                 |
-|                 |   receive       |                 |                 |
-|                 |   packet        |                 |                 |
-|                 |   callback      |                 |                 |
-|                 |   routine with  |                 |                 |
-|                 |   LLD to be     |                 |                 |
-|                 |   called for RX |                 |                 |
-|                 |   packet. Call  |                 |                 |
-|                 |   back routine  |                 |                 |
-|                 |   will extract  |                 |                 |
-|                 |   packet        |                 |                 |
-|                 |   received,     |                 |                 |
-|                 |   perform       |                 |                 |
-|                 |   simple memory |                 |                 |
-|                 |   comparison    |                 |                 |
-|                 |   against       |                 |                 |
-|                 |   packet sent   |                 |                 |
-|                 |   for integrity |                 |                 |
-|                 |   check. As     |                 |                 |
-|                 |   with switch   |                 |                 |
-|                 |   for every 1   |                 |                 |
-|                 |   transmitted   |                 |                 |
-|                 |   packet,       |                 |                 |
-|                 |   firmware will |                 |                 |
-|                 |   respond back  |                 |                 |
-|                 |   with 2        |                 |                 |
-|                 |   recieved      |                 |                 |
-|                 |   packets. Unit |                 |                 |
-|                 |   test will     |                 |                 |
-|                 |   iterate 10    |                 |                 |
-|                 |   times for     |                 |                 |
-|                 |   packet        |                 |                 |
-|                 |   transmission  |                 |                 |
-|                 |   and reception |                 |                 |
-|                 |   check.        |                 |                 |
-+-----------------+-----------------+-----------------+-----------------+
-
-|
-
-Debug Guide
-------------
-
-For debugging ICSS EMAC examples or LLD. Please refer to `ICSS-EMAC
-Debug Guide <http://processors.wiki.ti.com/index.php/ICSS_EMAC_LLD_debug_guide>`__.
-
-Additional References
-----------------------
-
-+-----------------------------------+------------------------------------------+
-| **Document**                      | **Location**                             |
-+-----------------------------------+------------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti      |
-|                                   | \\drv\\icss_emac\\docs\\doxygen\\html\\  |
-|                                   | index.html                               |
-+-----------------------------------+------------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti      |
-|                                   | \\drv\\icss_emac\\docs\\ReleaseNotes_    |
-|                                   | ICSS_EMAC_LLD.pdf                        |
-+-----------------------------------+------------------------------------------+
-| ICSS-EMAC LLD Details             | `[2] <http://processors.wiki.ti.c        |
-|                                   | om/index.php/ICSS-EMAC>`__               |
-+-----------------------------------+------------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_IOLINK.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_IOLINK.rst
deleted file mode 100644
index 39933b57a..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_IOLINK.rst
+++ /dev/null
@@ -1,164 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_IOLINK
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The IO-LINK Master driver provides an interface to any IO-Link devices
-(sensors or actuators) accessible via a half-duplex UART serial bus on
-SoC. It also provides a well-defined API layer which allows applications
-(IO-Link master stack) to manage IO-Link devices via simple portable APIs.
-
-The driver supports the following major functionalities:
-
--  Standard APIs to initialize/de-initialize/control the common Software
-   IP driver
--  Configuration/Control of the PRU Frame Handler firmware to handle the
-   messages transferred between the IO-Link master and device
--  Timer/Interrupt driven IO-Link communication between IO-Link master and
-   device to meet the timing requirement of IO-Link master protocol
-
-In addition a sample IO-Link master stack interface layer is provided in
-the IO-Link master demo application to provide an interface between the
-IO-Link master stack and the driver.
-
-.. note::
-
-   The stack interface layer should be ported to integrate a new master
-   stack.
-
-
-.. rubric::  Firmware
-   :name: firmware
-
-TI PRU-ICSS cores (Programmable Real-Time Unit Industrial Communication
-Subsystem) is firmware programmable and can take on various
-personalities. Processor SDK package includes IOLINK Firmware support.
-Refer `IOLINK Frame Handler FW <index_pru_icss_fw.html#pru-icss-iolink>`__ for
-additional details.
-
-|
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All the board specific configurations eg:enabling and pin-mux of IO-Link
-PRU pins should be performed before calling any driver APIs. By default
-Board_Init() API supports all initialization sequence for TI supported
-EVMs. Refer `Processor SDK RTOS Board
-Support <index_board.html#board-support>`__ for additional
-details.
-
-Once the board specific configuration is complete driver API IOLINK_init()
-can be called to initialize driver
-
-.. rubric::  **IOLINK Configuration Structure**
-   :name: iolink-configuration-structure
-
-IOLINK_soc.c file binds driver with hardware attributes on the board
-through IOLINK_config structure. This structure must be provided to IOLINK
-driver. It must be initialized before the IOLINK_init() function is called
-and cannot be changed afterwards. For details about the individual
-fields of this structure, see the Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\iolink\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/iolink/IOLINK.h>
-
- Sample code for IOLINK control operation:
-
-::
-
-    ...
-    Board_init(boardCfg);
-    ...
-    IOLINK_socGetFwCfg(peripheralNum, &iolink_cfg);
-    ...
-    IOLINK_socSetFwCfg(peripheralNum, &iolink_cfg);
-    ...
-    IOLINK_init();
-    ...
-    iolinkHandle = IOLINK_open(peripheralNum, &iolinkParams);
-    ...
-    status = IOLINK_control(iolinkHandle, iolinkCmd, &iolinkCmdArg);
-    ...
-
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-Refer Release Note for IOLINK support across different EVMs
-
-+-----------------------+-----------------------+------------------------------------------------+---------------+------------+
-|| Name                 || Description          ||  Expected Results                             | SoC Supported | Build Type |
-+=======================+=======================+================================================+===============+============+
-| IOLINK_Stack          || Demo stack example   || Following prints will come on console         | AM437x        | makefile   |
-| Example application   |  to control 4 Autosen |  based on devices connected to the master:     | (TIDA-010016) |            |
-|                       |  AO001 (sensor) and 4 || autosen gmbh device AO001 connected on port 0 |               |            |
-|                       |  AD003 (actuator)     || autosen gmbh device AO001 detected an object  |               |            |
-|                       |  devices              || autosen gmbh device AD003 connected on port 1 |               |            |
-|                       |                       || autosen gmbh device AD003 display turned on   |               |            |
-|                       |                       |                                                |               |            |
-+-----------------------+-----------------------+------------------------------------------------+---------------+------------+
-
-.. note::
-
-   IOLINK demo example application uses 4 Autosen sensor devices and 4
-   Autosen actuator devices. It pairs one sensor with one actuator
-   when the devices are connected. If a sensor detects an object, it
-   controls the paired acutator to turn on the display on the actuator.
-   If the sensor does not detect an object, it controls the paired
-   actuator to turn off the display.
-
-Building IOLINK example
-----------------------
-
--  Makefile based examples and dependent libraries can be built from
-   the top level or module level IOLINK makefile, refer to the
-   `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__
-   for details of how to setup the build environment. Once you have
-   setup the build environment, issue the following commands:
-::
-
-   To build and clean libs/apps from top-level makefile:
-   cd <pdk>/packages
-   make iolink
-   make iolink_clean
-
-   To build and clean libs/apps from module-level makefile:
-   cd <pdk>/packages/ti/drv/iolink
-   make all
-   make clean
-
-
-Additional References
----------------------
-
-+-----------------------+--------------------------------------------------+
-| **Document**          |  **Location**                                    |
-+-----------------------+--------------------------------------------------+
-| API Reference Manual  | $(TI_PDK_INSTALL_DIR)\\packages\\ti              |
-|                       | \\drv\\iolink\\docs\\doxygen\\html\\index.html   |
-+-----------------------+--------------------------------------------------+
-| Release Notes         | $(TI_PDK_INSTALL_DIR)\\packages\\ti              |
-|                       | \\drv\\iolink\\docs\\ReleaseNotes_IOLINK_LLD.pdf |
-+-----------------------+--------------------------------------------------+
-
-|
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_IPCLLD.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_IPCLLD.rst
deleted file mode 100644
index 7626bd420..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_IPCLLD.rst
+++ /dev/null
@@ -1,336 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_IPCLLD
-
-Overview
------------
-
-
-TI Jacinto7/AM65XX family of devices consists of many cores - ARM53/72, R5Fs (MCU or Main Domain) and/or DSPs (C66x / C7x). The actual cores vary with actual device. Refer to the datasheet of the device for the actual cores present on SoC. Inter-Processor Communication (IPC) provides a communication channel between various cores. IPCLLD is the low-level driver for IPC, which provides a core-agnostic and OS-agnostic framework for communication.
-
-More information regarding the `TI multicore processors <http://www.ti.com/processors/automotive-processors/overview.html>`_ is available .
-
-
-Terms and Abbreviation
-------------------------
-
-=======   =============================================
-Term      Definition or Explanation
-=======   =============================================
-IPC       Inter-Processor Communication
-RirtIO    Virtual I/O driver
-MailBox   IP which provides queued interrupt mechanism  for communication channel
-VRing     Ring Buffer in shared memory
-PDK       Platform Development Kit
-PSDKRA    Processor SDK RTOS Automotive
-PSDK      Processor SDK Linux Automotive
-=======   =============================================
-
-
-References
------------
-* `Sitara Processor Datasheet <http://www.ti.com/lit/gpn/am6548>`_
-*  For J721e datasheet, please contact TI presentative
-
-
-Features
---------
-
-* Provides ipc low-level driver, which can be compiled for any of the cores on AM65xx or J721E devices
-* Supports Bios/Bios communication and Linux/Bios concurrently for all cores
-* Supports TI RTOS, Linux, QNX and baremetal (No-OS) use.
-* It can be extended for any third-party RTOS by adding OS adaptation layer
-* IPCLLD also provides many examples for quick reference
-
-
-Installation
-------------
-
-IPCLLD is part of TI PDK (Platform Development Kit) package. Once PRSDK is installed, PDK and all dependent packages and tool-chains are installed automatically.
-IPCLLD can also be located at <PRSDK_HOME>/pdk/packages/ti/drv/ipc. IPCLLD is also available publically at `<https://git.ti.com/processor-sdk/pdk/>`_ at packages/ti/drv/ipc.
-
-It can also be cloned using following git command:
-
-* git clone git://git.ti.com/processor-sdk/pdk.git
-* Provides many examples for quick reference
-
-The file  and directory oraganization are as below.
-
- .. image:: /images/ipclld_file_org.png
-                :height: 944
-                :width: 435
-
-
-Build
------
-
-IPCLLD uses the PDK build systems to build the IPCLLD library and example applications.
-
-Dependency of External PDK Components
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-IPCLLD does not access any hardware diretly. It uses the PDK/csl component to configure Mailbox registers. It uses sciclient to set/release Mailbox interrupt. Also it uses PDK/osal to configure OS-related steps like Semaphore etc.
-
-- pdk/csl : Configures Mailbox registers
-- pdk/sciclient : Set Mailbox interrupts
-- pdk/osal : To register for HWI and other kernel stuffs.
-
-
-
-Command to build IPCLLD
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The build can be done either from the IPCLLD's path in the PDK packages, or from the PDK build folder. For either method, the following environment variables must be defined, or supplied with the build command (if they are different from the defaults of the SDK installation):
-
-- SDK_INSTALL_PATH: Installation root for sdk
-- TOOLS_INSTALL_PATH: where all the tool chains are installed, if different from SDK_INSTALL_PATH
-- PDK_INSTALL_PATH: Installtion root for pdk
-
-The following build instructions are for Linux. For Windows build, please replace "make" with "gmake".
-
-Method 1:
-
-These libraries and examples are built from the IPCLLD's path in the PDK packages:
-
-    PDK_INSTALL_DIR/packages/ti/drv/ipc
-
-=======  ======================================================================================  ===========
-Target   Build Command                                                                           Description
-=======  ======================================================================================  ===========
-lib      make PDK_INSTALL_PATH=PDK_INSTALL_DIR/packages SDK_INSTALL_PATH=SDK_INSTALL_PATH lib    IPCLLD library
-apps     make PDK_INSTALL_PATH=PDK_INSTALL_DIR/packages SDK_INSTALL_PATH=SDK_INSTALL_PATH apps   IPCLLD examples
-clean    make PDK_INSTALL_PATH=PDK_INSTALL_DIR/packages SDK_INSTALL_PATH=SDK_INSTALL_PATH clean  Clean IPCLLD library and examples
-all      make PDK_INSTALL_PATH=PDK_INSTALL_DIR/packages SDK_INSTALL_PATH=SDK_INSTALL_PATH all    Build IPCLLD library and examples
-=======  ======================================================================================  ===========
-
-Method 2:
-
-If building from the PDK build folder, then use following steps to build
-
-    Go to PDK_INSTALL_DIR/packages/ti/build
-
-=======  ==========================================================================================================  ===========
-Target   Build Command                                                                                               Description
-=======  ==========================================================================================================  ===========
-lib      make -s -j BUILD_PROFILE=<debug/release> BOARD=<am65xx_evm/j721e_evm> CORE=<core_name> ipc                  IPCLLD library
-example  make -s -j BUILD_PROFILE=<debug/release> BOARD=<am65xx_evm/j721e_evm> CORE=<core_name> ipc_echo_test        ipc_echo_test example (this can be replaced with any available IPC test name to build the specific test)
-clean    make -s -j BUILD_PROFILE=<debug/release> BOARD=<am65xx_evm/j721e_evm> CORE=<core_name> ipc_echo_test_clean  Clean the ipc_echo_test (this can be replaced with any available IPC test name to build the specific test)
-=======  ==========================================================================================================  ===========
-
-See `Example Details`_ for list of supported examples.
-
-Available Core names
-^^^^^^^^^^^^^^^^^^^^
-
-AM65XX:
-        - mpu1_0 (A53)
-        - mcu1_0 (r5f0_0)
-	- mcu1_1 (r5f0_1)
-J721E:
-	- mpu1_0 (A72)
-	- mcu1_0 (mcu-r5f0_0)
-        - mcu1_1 (mcu-r5f0_1)
-        - mcu2_0 (main-r5f0_0)
-        - mcu2_1 (main-r5f0_1)
-        - mcu3_0 (main-r5f1_0)
-        - mcu3_1 (main-r5f1_1)
-        - c66xdsp_1 (c66x_0)
-        - c66xdsp_2 (c66x_1)
-        - c7x_1 (c71x_0)
-
-Expected Output
-^^^^^^^^^^^^^^^
-
-The built example binaries can be found in the PDK's binary folder:
-
-    PDK_INSTALL_PATH/packages/ti/binary/<test_name>/bin/<board_name>/
-
-Running the IPCLLD examples
----------------------------
-
-IPCLLD comes with the following examples.
-
-Example Details
-^^^^^^^^^^^^^^^
-
-- **ipc_echo_test:** This is most generic example application where mpu1_0 is running Linux, and all other cores running bios. All cores talk to each other bi-diectionally. It is send ping message and remote end responds pong message. There are 10000 ping/pong messages exchanged between each core-pair.
-- **ex01_bios_2core_echo_test:** This is the simplistic ping/pong application between any two cores running BIOS
-- **ex02_bios_multicore_echo_test:** All cores running BIOS, many-to-many communication, each sending ping/pong with each other. mpu1_0 is also running BIOS.
-- **ex03_linux_bios_2core_echo_test:** This is simplistic ping/pong application where mpu1_0 running Linux and any other core is running Bios.
-- **ex04_linux_baremetal_2core_echo_test:** AM65xx only. This is a ping/pong application where mpu1_0 is running Linux and the other core is baremetal (no OS).
-
-Loading Remote Firmware
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Remote firmware can be loading using CCS or using uBoot SPL.
-
-1. **Loading using CCS** :
-
-    Sciclient module contains default system firmware and CCS script to load the system firmware. The load scripts should be modified to reflect the correct full-path of the script location. Once the script is updated,
-
-    * start TI CCS 9.1 or newer
-    * open CCS script console using menu **View --> Scripting Console**
-    * Run the script using following command (example below is for J721E, use the appropriate one for your target)
-        - loadJSFile("PDK_INSTALL_DIR/packages/ti/drv/sciclient/tools/ccsLoadDmsc/j721e/launch.js")
-
-      .. image:: /images/ipclld_LoadingSysFw_sciclient.png
-                :height: 160
-                :width: 941
-    * Connect the cores
-        - select the core
-        - right-click and connect
-    * Load the remote binaries
-        - Menu **Run --> Load Program**
-    * Run the cores.
-    * After running the cores, the sample output should look something like below.
-
-      .. image:: /images/ipclld_Sample_output_mpu.png
-                :height: 377
-                :width: 672
-
-
-2. **Loading using SPL/uBoot**
-
-  Run following steps to configure remote firmware for SPL loading with HLOS running on MPU
-
-  1) Copy the remote firmware to rootfs at /lib/firmware/pdk-ipc folder
-  2) cd /lib/firmware
-  3) Remove old soft link for remote cores
-
-     * rm j7*
-  4) Create new soft links
-
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_c66xdsp_1_release.xe66 j7-c66_0-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_c66xdsp_2_release.xe66 j7-c66_1-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_c7x_1_release.xe71     j7-c71_0-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_mcu2_0_release.xer5f   j7-main-r5f0_0-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_mcu2_1_release.xer5f   j7-main-r5f0_1-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_mcu3_0_release.xer5f   j7-main-r5f1_0-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_mcu3_1_release.xer5f   j7-main-r5f1_1-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_testb_mcu1_0_release.xer5f  j7-mcu-r5f0_0-fw
-     * ln -s /lib/firmware/pdk-ipc/ipc_echo_test_mcu1_1_release.xer5f   j7-mcu-r5f0_1-fw
-
-  5) sync : write the changes to filesystem
-  6) Reboot the system
-
-
-Running the Echo Tests
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In this section ipc_echo_test is used to demonstrate, but same instructions apply to other examples that have Linux on MPU, though test output may be slightly different.
-
-  1) Login as root
-  2) Start sample app as below
-
-     - modprobe rpmsg_client_sample count=5
-
-     .. image:: /images/ipclld_Linux_Start.png
-                :height: 270
-                :width: 581
-
-   3) After running the sample app, it should display something below
-
-    .. image:: /images/ipclld_linux_output.png
-                :height: 796px
-                :width: 983px
-
-
-IPCLLD Design Details
----------------------
-
-- Ring Buffer is used as shared memory to transfer the data. It must be reserved system wide. The base-address and size of ring Buffer must be provided to IPCLLD. It must be same for all core applications. The invidual memory-range for Ring Buffer between core combinations are calculated internally inside the library. The default base-address and size used in the IPC examples is
-
-=======  =============  ==========
-Device   Base Address   Size
-=======  =============  ==========
-J721E    0xAA000000     0x1C00000
-AM65XX   0xA2000000     0x200000
-=======  =============  ==========
-
-The VRing base address and size is passed from the application during the Ipc_initVirtIO() call. See `Writing HelloWorld App using IPCLLD`_ for the example of usage.
-
-Additionally the Ring Buffer memory used when communicating with MPU running Linux must be reserved system wide. The base-address and size of the ring buffer is different from what is used between cores not running Linux. The base-address and size of the ring Buffer is provided to IPCLLD when Linux updates the core's resource table with the allocated addresses. Linux allocates the base-address from the first memory-region. See `Resource Table`_ for more information.
-
-- For each RPmessage object, the memory must be provided to library from local heap. All subsequent send/recv API is using rpmessage buffer provided during the create function.
-- RPMessage can transfer maximum of 512 bytes of data. For larger data transfers, it is recommended to pass a pointer/handle/offset to a larger shared memory buffer inside the message data.
-- For firmware that will communicate with Linux over IPC, a Resource Table is required. See `Resource Table`_ for more information.
-
-Typical Data-Flow in IPCLLD communication between two cores
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Following picture illustrates the data flow between two cores using mailbox IP as transport.
-
-.. image:: /images/ipclld_data_flow.png
-                :height: 470
-                :width: 687
-
-Resource Table
-^^^^^^^^^^^^^^
-For applications that will use Linux IPC, a resource table is required. Example resource tables can be found in the IPC examples:
-
-========  =========================================
-Device    Resource Table Example Location
-========  =========================================
-J721E     examples/common/src/ipc_rsctable.h
-AM65XX    examples/common/src/ipc_am65xx_rsctable.h
-========  =========================================
-
-The resource table must have at least one entry, the VDEV entry, to define the the vrings used for IPC communication with Linux.
-Optionally, the resource table can also have a TRACE entry which defines the location of the remote core trace buffer.
-
-The VDEV entry specifies the address as RPMSG_VRING_ADDR_ANY, meaning that the address will be allocated by the Linux driver during loading. The allocation is made from the first memory-region specified in the dts file for the remote core. For example, if the dts entry for mcu_r5fss0_core0 is ::
-
-    reserved_memory: reserved-memory {
-        #address-cells = <2>;
-	#size-cells = <2>;
-	ranges;
-
-	mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 {
-        	compatible = "shared-dma-pool";
-        	reg = <0 0xa0000000 0 0x100000>;
-        	no-map;
-        };
-
-        mcu_r5fss0_core0_memory_region: r5f-memory@a0100000 {
-        	compatible = "shared-dma-pool";
-        	reg = <0 0xa0100000 0 0xf00000>;
-        	no-map;
-        };
-    }
-
-then the allocation for the vrings will come from the 0xa0000000 entry.
-
-Memory Considerations
-^^^^^^^^^^^^^^^^^^^^^
-As mentioned in `IPCLLD Design Details`_, the Ring Buffer memory must be reserved system-wide. In addition, the Ring Buffer memory should be configured as non-cached on all cores using IPCLLD. For examples of configurations for Ring Buffer memory, refer to the examples in pdk/packages/ti/drv/ipc/examples/.
-
-Writing HelloWorld App using IPCLLD
------------------------------------
-- **Step1: Initialize MultiProc with SelfId, and how many remote cores** ::
-
-     Ipc_mpSetConfig(selfProcId, numProc, remoteProc);
-
-- **Step2: Load the Resource Table (required only if running Linux on A72/A53)** ::
-
-     Ipc_loadResourceTable((void*)&ti_ipc_remoteproc_ResourceTable);
-
-See `Resource Table`_ for details on the resource table.
-
-- **Step3: Initialize VirtIO (note: Base Address for Shared Memory used for RingBuffer)** ::
-
-     vqParam.vqObjBaseAddr = (void*)sysVqBuf;
-     vqParam.vqBufSize     = numProc * Ipc_getVqObjMemoryRequiredPerCore();
-     vqParam.vringBaseAddr = (void*)VRING_BASE_ADDRESS;
-     vqParam.vringBufSize  = VRING_BUFFER_SIZE;
-     Ipc_initVirtIO(&vqParam);
-
-- **Step4: Initialize RPMessage** ::
-
-     RPMessage_init(&cntrlParam);
-
-- **Step5: Send Message** ::
-
-     RPMessage_send(handle, dstProc, ENDPT1, myEndPt, (Ptr)buf, len);
-
-- **Step6: Receive Message** ::
-
-     RPMessage_recv(handle, (Ptr)buf, &len, &remoteEndPt, &remoteProcId, timeout);
-
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_MCASP.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_MCASP.rst
deleted file mode 100644
index 561d1d79a..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_MCASP.rst
+++ /dev/null
@@ -1,448 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_MCASP
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The multichannel audio serial port (McASP) functions as a
-general-purpose audio serial port optimized for the needs of
-multichannel audio applications. The McASP is useful for time-division
-multiplexed (TDM) stream, Inter-Integrated Sound (I2S) protocols, and
-intercomponent digital audio interface transmission (DIT).The
-multichannel buffered serial port (McASP) peripheral allows direct
-interface to other TI DSPs, codecs, and other devices in a system. The
-following sub sections explain the hardware (McASP peripheral) and
-software context of the McASP LLD.
-
-The device driver exposes a set of well-defined APIs which are used by
-the application layer to send and receive data via the McASP peripheral.
-The driver also exposes a set of well-defined OS abstraction APIs which
-are used to ensure that the driver is OS independent and portable. The
-McASP driver uses the CSL McASP register layer for all McASP MMR access.
-The McASP driver also interfaces with the EDMA3/UDMA library to be able to
-transfer data to and from McASP peripheral and data memory.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The McASP driver provides a sample implementation sequence which
-initializes the MCASP IP block. The McASP Device initialization API is
-implemented as a sample prototype:
-
-::
-
-    void McaspDevice_init (void)
-
-The function initializes all the instance specific information like base
-address of instance CFG registers, FIFO address for the instance, TX and
-RX CPU event numbers, TX and RX EDMA event numbers etc.
-
-For details about individual fields of this structure, see the Doxygen
-help by opening
-PDK_INSTALL_DIR\Packages\ti\drv\mcasp\docs\doxygen\html\index.html.
-
-::
-
-     int32_t Mcasp_socGetInitCfg(uint32_t index, Mcasp_HwInfo *cfg)
-
-The function obtains the soc configuration parameters such as interrupt
-numbers, mux configuration parameters etc.
-
-::
-
-     int32_t Mcasp_socSetInitCfg(uint32_t index, const Mcasp_HwInfo *cfg)
-
-The function set the soc configuration parameters such as interrupt
-numbers, mux configuration parameters etc.
-
-APIs
-^^^^^
-
-Refer to below API files:
-
-::
-
-    #include <ti/drv/mcasp/mcasp_drv.h>
-    #include <ti/drv/mcasp/soc/mcasp_soc.h>
-
-.. rubric:: McASP Buffer formats
-   :name: mcasp-buffer-formats
-
-The McASP driver provides various buffer formats for sending the data
-to/from the audio device. The differences between these formats arise
-from the way the audio samples are collected from various serializers
-and their timeslots and arranged in the system's memory. This way the
-application can choose to run audio processing algorithms over the data
-without the need for re-arranging those data every frame. The buffer
-format is provided in the **Mcasp_ChanParams.dataFormat** in the form of
-**Mcasp_BufferFormat** defined in mcasp_drv.h The below section provides
-an overview of the various formats. In the explanatory diagrams in each
-section, McASP controller recieves samples in frame intervals denoted by
-t1,t2..tn. The McASP driver collects these and arranges those samples in
-the memory in various formats in to the host's System memory. We have
-chosen 32 bit samples and 32-bit word addresses throughout for
-simplicity.
-
-.. rubric:: Mcasp_BufferFormat_1SER_1SLOT
-   :name: mcasp_bufferformat_1ser_1slot
-
-This is applicable if only one serializer and one timeslot is used. The
-samples are ordered in the order they received or sent.
-
-.. Image:: /images/1SLOT_1SER.PNG
-
-.. rubric:: Mcasp_BufferFormat_1SER_MULTISLOT_INTERLEAVED
-   :name: mcasp_bufferformat_1ser_multislot_interleaved
-
-This is applicable if multiple slots are used with one serializer. The
-samples from the different timeslots are stored interleaved in the
-memory as below. Different timeslots' samples are denoted by different
-colors and are labelled t1,t2..tn according to the time they arrive at
-the serializer.
-
-.. Image:: /images/1SER_MULTISLOT_INTERLEAVED.PNG
-
-.. rubric:: Mcasp_BufferFormat_1SER_MULTISLOT_NON_INTERLEAVED
-   :name: mcasp_bufferformat_1ser_multislot_non_interleaved
-
-This is applicable if multiple slots are used with one serializer. The
-samples from the different timeslots are grouped together on the basis
-of the timeslot and stored in the memory as shown below. Different
-timeslots' samples are denoted by different colors and are labelled
-t1,t2..tn according to the time they arrive at the serializer.
-
-.. Image:: /images/1SER_MULTISLOT_NON_INTERLEAVED.PNG
-
-NOTE: if the non-interleaved format is used, the Mcasp_ChanParams->
-hwFifoEventDMARatio must be set to 1.
-
-.. rubric:: Mcasp_BufferFormat_MULTISER_1SLOT_SER_INTERLEAVED
-   :name: mcasp_bufferformat_multiser_1slot_ser_interleaved
-
-This is applicable if multiple serializers are used with one time slot
-is used for each of the serializers. The samples from the different
-serializers are stored in the memory in interleaved fashion as shown
-below Different serializers' samples are denoted by different colors and
-are labelled S1,S2..Sn according to the time they arrive at the
-serializer.
-
-.. Image:: /images/1SER_MULTISER_1SLOT_SER_INTERLEAVED_2.PNG
-
-|
-
-.. rubric:: Mcasp_BufferFormat_MULTISER_1SLOT_SER_NON_INTERLEAVED
-   :name: mcasp_bufferformat_multiser_1slot_ser_non_interleaved
-
-This is applicable if multiple serializers are used with one timeslots
-each per serializer. The samples from the different timeslots are
-grouped together on the basis of the serializer and stored in the memory
-as shown below Different serializers' samples are denoted by different
-colors and are labelled S1,S2..Sn according to the time they arrive at
-the serializer.
-
-.. Image:: /images/1SER_MULTISER_1SLOT_SER_NON_INTERLEAVED.PNG
-
-.. rubric:: Mcasp_BufferFormat_MULTISER_MULTISLOT_SEMI_INTERLEAVED_1
-   :name: mcasp_bufferformat_multiser_multislot_semi_interleaved_1
-
-This is applicable if multiple serializers are used and each serializer
-containing multiple timeslots. The samples are stored in the memory
-interleaved based on serializer and timeslots as shown below. In this
-example, there are 3 serializers and 2 timeslots per serializers whose
-samples are noted by Ln (left) and Rn (right). Different serializers'
-samples are denoted by different colors.
-
-.. Image:: /images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_1_UPDATED.PNG
-
-.. rubric:: Mcasp_BufferFormat_MULTISER_MULTISLOT_SEMI_INTERLEAVED_2
-   :name: mcasp_bufferformat_multiser_multislot_semi_interleaved_2
-
-This is applicable if multiple serializers are used and each serializer
-containing multiple timeslots. The samples are grouped based on the
-serializer and within one serializer, the timeslots are interleaved as
-shown below. In this example, there are 3 serializers and 2 timeslots
-per serializers whose samples are noted by Ln (left) and Rn
-(right).Different serializers' samples are denoted by different colors.
-
-.. Image:: /images/1SER_MULTISER_MULTISLOT_SEMI_INTERLEAVED_2.PNG
-
-NOTE: if the non-interleaved format is used, the Mcasp_ChanParams->
-hwFifoEventDMARatio must be set to 1.
-
-.. rubric:: Mcasp WordBits Selection
-   :name: mcasp-wordbits-selection
-
-With all the frame formats explained above, there is an option to choose
-which bits to pack from the 32-bit serializer data obtained from/to the
-McASP serializer, when the word size is less than the slot size. This
-option is exercised by setting the Mcasp_chanParams->wordBitsSelect to
-Mcasp_wordBitsSelect_LSB/Mcasp_wordBitsSelect_MSB.
-
-If the default Mcasp_wordBitsSelect_LSB option is selected, the LSBs are
-packed in to the system memory.
-
-Below is an example of word size = 16bits and slot size = 32 bits and
-the Mcasp_wordBitsSelect_LSB option is used. On the receiving side, the
-serializer holds the 32 bit data whose LSB 16 bits are picked up and
-packed in to the system memory. The MSB 16 bits are ignored.
-
-.. Image:: /images/WordSelect_LSB.PNG
-
-If the Mcasp_wordBitsSelect_MSB option is used, the serializer's
-MSB-16bits are packed in to the system memory. The LSBs are ignored.
-
-.. Image:: /images/WordSelect_MSB.PNG
-
-.. rubric:: Priming
-   :name: priming
-
-Applications using McASP driver often might send/receive one or two
-transfers via McASP before sending the application data in/out of McASP
-through the driver. This would internally set up transfer request queues
-so that the application can seamlessly send/receive data without the
-possibility of underrun. This process, a.k.a priming is used in the
-example application provided with the Processor SDK. In this example two
-frames are sent/received prior to submitting the application's audio
-data to the McASP driver. The number of transfer requests to prime is
-application dependent and some applications where there may be a lot of
-delay between transfer requests, enough to cause an underrun, the
-priming factor could be higher.
-
-Application
-------------
-
-Examples & Unit tests
-^^^^^^^^^^^^^^^^^^^^^
-
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-| Name                               || Description              | | Expected Results    |  SOCs    | Build type  |
-+====================================+===========================+=======================+==========+=============+
-| Audio_ExampleProject               | | Example                 | | Audio sent in to    | AM335X   | CCS Project |
-|                                    |   demonstrating           |   the EVM being       | AM437x   |             |
-|                                    |   sample McASP            |   played out via the  | AM572x   |             |
-|                                    |   loopback using AIC31    |   stereo output of    | K2G      |             |
-|                                    |   codec. Reference example|   the EVM             | OMAPL137 |             |
-|                                    |   for developers          |                       | OMAPL138 |             |
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-| Audio_SMP_ExampleProject           | | Example                 | | Audio sent in to    | AM572x-  | CCS Project |
-|                                    |   demonstrating           |   the EVM being       | EVM      |             |
-|                                    |   sample McASP            |   played out via the  |          |             |
-|                                    |   loopback using AIC31    |   stereo output of    |          |             |
-|                                    |   codec. Reference example|   the EVM             |          |             |
-|                                    |   for developers with SMP |                       |          |             |
-|                                    |   enabled.(A15 core only) |                       |          |             |
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-| DeviceLoopback_ExampleProject      | | Example                 | | Digital ramp        | AM335X   | CCS Project |
-|                                    |   demonstrating           |   pattern sent to     | AM437x   |             |
-|                                    |   sample McASP device     |   McASP and getting   | AM571x   |             |
-|                                    |   loopback .              |   looped back         | AM572x   |             |
-|                                    |   Reference example       |   internally using    | AM574x   |             |
-|                                    |   for developers          |   device loopback     | K2G      |             |
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-| AudioEQ_ExampleProject             | | Example                 | | Three band          | AM572x   | CCS Project |
-|                                    |   demonstrating           |   Equalization of     | K2G      |             |
-|                                    |   stereo audio            |   stereo channel      |          |             |
-|                                    |   using biquad            |   filters with gain   |          |             |
-|                                    |   filters . Reference     |   control using       |          |             |
-|                                    |   design for              |   serial console      |          |             |
-|                                    |   developers. **TI        |   inputs              |          |             |
-|                                    |   Design Guide**:         |                       |          |             |
-|                                    |   `TIDEP0069`_            |                       |          |             |
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-| DeviceLoopback_TestApp             | | Unit test               | | Digital ramp        | AM65x    | Makefile    |
-|                                    |   demonstrating           |   pattern sent to     | J721e    |             |
-|                                    |   sample McASP device     |   McASP and getting   |          |             |
-|                                    |   loopback .              |   looped back         |          |             |
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-| DeviceLoopback_SMP_TestApp         | | Unit test               | | Digital ramp        | AM65x    | Makefile    |
-|                                    |   demonstrating           |   pattern sent to     | J721e    |             |
-|                                    |   sample McASP device     |   McASP and getting   |          |             |
-|                                    |   loopback with SMP       |   looped back         |          |             |
-|                                    |   enabled (A53 core only).|                       |          |             |
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-| DeviceLoopback_Regression_TestApp  | | Regression unit test    | | Menu Driven test    | AM65x    | Makefile    |
-|                                    |   which tests various     |   sending digital ramp| J721e    |             |
-|                                    |   features/configurations |   and getting looped  |          |             |
-|                                    |   of the MCASP driver     |   back in various     |          |             |
-|                                    |   This is a menu based    |   configurations      |          |             |
-|                                    |   test application        |                       |          |             |
-+------------------------------------+---------------------------+-----------------------+----------+-------------+
-
-AudioEQ_ExampleProject
-^^^^^^^^^^^^^^^^^^^^^^^
-
-This example demonstrates stereo audio equalizer using biquad filters.
-
--  Filter default configurations are:
-
-	-  Low_Fc       = 250.0   (Low Shelf cutoff frequency in Hz)
-	-  High_Fc      = 1000.0  (High Shelf cutoff frequency in Hz)
-	-  Sample_Rate  = 44100.0 (Number of samples per second)
-	-  Q_Factor     = 0.707   (Bandwidth of frequency that will be affected by an equalizer)
-	-  Default_Gain = 0.0     (increase or decrease in audio signal strength, expressed in dB)
-
--  The default Gain has been set to 0, in order to suppress any noise.
-   The default Gain can be changed based on the test case requirement at, ti/drv/mcasp/example/src/audioEQ.c 'defaultGain = 0.0'.
-
--  The filter gains can be tuned from the uart console based on the test case requirement.
-
-Sample log for the Audio Equalizer test is shown below
-
-::
-
-    ******** Audio EQ Demo ********
-    NUM_BUFS=2
-    PRIME_COUNT=2
-
-    EDMA driver initialization successful.
-
-
-    ======================================================
-
-     Currently playing Audio effect Demo.
-     Make sure a stereo input is connected to Line In and
-     Connect an headphone or a speaker to LineOut.
-
-    ======================================================
-
-    Initialization complete. priming about to begin
-     Demo currently shows 3 band equalization using shelving biquad filters
-     * low band = 0Hz to 250Hz
-     * mid band = 250Hz to 1000Hz,
-     * high band = 1000Hz to 22000Hz
-      All bands are boosted with a 8db Peak Gain
-
-
-    Do you wish to keep the equalization ON ? (y or n)
-    y
-
-    ======================================================
-
-    Press 0 and hit Enter to print current gain settings
-
-    OR
-
-    Select the Frequency Band to adjust the gain
-
-    *   Press 1 for Low  and hit Enter
-    *   Press 2 for High  and hit Enter
-    *   Press 3 for Mid and hit Enter
-    All other input will not have any effect
-
-    ======================================================
-
-    1
-
-    Enter the value of gain in dB (Recommendation -8 to 8)
-    4
-    Gain updated
-
-
-    Do you wish to keep the equalization ON ? (y or n)
-    n
-    Equalization OFF
-
-
-    Do you wish turn ON the equalization? (y or n)
-
-|
-
-Building CCS projects based examples
-----------------------------------------------
-
-CCS Projects mentioned in the above table are built using pdkProjectCreate.bat/sh as explained in
-`PDK Example and Test Project Creation <index_overview.html#pdk-example-and-test-project-creation>`__
-
-Building MCASP Test applications via makefiles
-----------------------------------------------
-
-- MCASP Test applications and dependent libraries are built from the top level
-  mcasp makefile
-
-- Refer to the `Processor SDK RTOS Getting Started Guide
-  <index_overview.html#setup-environment>`__  for details of how to setup the
-  build environment. Once you have setup the build environment, issue the
-  following commands:
-
-   -  cd <pdk>/packages/
-
-   -  To build: make mcasp
-
-   -  To clean: make mcasp_clean
-
-- Similarly, to build at the module level, issue the following commands for
-  rebuilding :
-
-   - cd <pdk>/packages/ti/drv/mcasp
-
-   - To build: make all
-
-   - To clean: make clean
-
-.. _AudioEQ example: http://www.ti.com/tool/tidep0069
-
-.. _TIDEP0069: http://www.ti.com/lit/ug/tidubq2/tidubq2.pdf
-
-
-.. rubric:: Introduction
-   :name: introduction-1
-
-The sample application demonstrates the use of the MCASP driver for
-audio playback. The application uses McASP LLD, and programs the AIC
-codec on the EVM to send and receive the audio input. The audio received
-from the AIC codec is loop back-ed at the application and sent back to
-the AIC codec via MCASP LLD.
-
-.. rubric:: Audio test setup
-   :name: audio-test-setup
-
-Please ensure the below before running the demo
-
-#. Connect the EVM’s stereo audio input to the PC’s stereo audio output
-#. Connect the EVM’s stereo audio output to powered speakers. Please
-   make sure the amplification on the speakers is high enough for the
-   audio output to be heard
-
-.. rubric:: Building and running the Example
-   :name: building-and-running-the-example
-
-#. Run pdkProjectCreate to create the
-   MCASP_Audio_<evm>_<device>ExampleProject
-#. Load the project on to CCS and build the same.
-#. Build the example
-#. Load the MCASP_Audio_<evm>_<device>ExampleProject
-#. Run the example
-
-.. rubric:: Testing the example
-   :name: testing-the-example
-
-#. Play an audio file on the PC.
-#. You should be able to hear the same audio on the speakers connected
-   to the EVM. It is the PC’s audio output which is loop backed at the
-   EVM’s MCASP example outputted to the speakers.
-
-NOTE: Please make sure the speakers’ output volume is high enough for
-the audio to be audible.
-
-Additional References
----------------------
-
-+-----------------------------------+----------------------------------------+
-| **Document**                      | **Location**                           |
-+-----------------------------------+----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\mcasp\\docs\\doxygen\\html\\inde|
-|                                   | x.html                                 |
-+-----------------------------------+----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\mcasp\\docs\\ReleaseNotes_MCAS  |
-|                                   | P_LLD.pdf                              |
-+-----------------------------------+----------------------------------------+
-| Software design Specification     | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\mcasp\\docs\\MCASP_LLD_SDS.pdf  |
-+-----------------------------------+----------------------------------------+
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_MCBSP.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_MCBSP.rst
deleted file mode 100644
index 6c774860b..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_MCBSP.rst
+++ /dev/null
@@ -1,94 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_MCBSP
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The multichannel buffered serial port (MCBSP) peripheral allows direct
-interface to other TI DSPs, codecs, and other devices in a system. The
-primary use for the MCBSP is for audio interface purposes. The following
-sub sections explain the hardware (MCBSP peripheral) and software
-context of the MCBSP LLD.
-
-The device driver exposes a set of well-defined APIs which are used by
-the application layer to send and receive data via the MCBSP peripheral.
-The driver also exposes a set of well-defined OS abstraction APIs which
-are used to ensure that the driver is OS independent and portable. The
-MCBSP driver uses the CSL MCBSP register layer for all MCBSP MMR access.
-The MCBSP driver also interfaces with the EDMA3 library to be able to
-transfer data to and from MCBSP peripheral and data memory.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The MCBSP Driver initialization API needs to be called only once and it
-initializes the internal driver data structures like device objects.
-Application developers need to ensure that they call the MCBSP Driver
-Init API before they call the MCBSP Device Initialization. Following API
-is used to initialize the MCBSP Driver
-
-::
-
-    int32_t mcbspInit (void)
-
-MCBSP Peripheral Configuration
-The MCBSP driver provides a sample implementation sequence which
-initializes the MCBSP IP block. The MCBSP Device initialization API is
-implemented as a sample prototype:
-
-::
-
-    void McbspDevice_init (void)
-
-For details about individual fields of this structure, see the Doxygen
-help by opening
-PDK_INSTALL_DIR\Packages\ti\drv\MCBSP\docs\doxygen\html\index.html.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/MCBSP/mcbsp_drv.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+
-| Name                  | Description           |
-+=======================+=======================+
-| MCBSP_Example         |   Example             |
-| application           |   demonstrating       |
-|                       |   *sample MCBSP       |
-|                       |   loopback* test.     |
-|                       |   Reference example   |
-|                       |   for developers      |
-+-----------------------+-----------------------+
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\MCBSP\\docs\\doxygen\\html\\inde |
-|                                   | x.html                                  |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\MCBSP\\docs\\ReleaseNotes_MCBS   |
-|                                   | P.pdf                                   |
-+-----------------------------------+-----------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_MMCSD.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_MMCSD.rst
deleted file mode 100644
index 4560c904a..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_MMCSD.rst
+++ /dev/null
@@ -1,433 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_MMCSD
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-MMCSD module provides an interface between CPU and any
-MMCSD-bus-compatible device that connects via MMCSD serial bus. External
-components attached to MMCSD bus can serially transmit/receive data
-to/from the CPU device through two-wire interface
-
-.. rubric:: Key Features
-   :name: key-features
-
-| Type of transfers
-
-   -   Read
-   -   Write
-   -   Write followed by read
-
-| Operating modes
-
-   -   Blocking(interrupt or Non interrupt)
-   -   Callback mode(interrupt)
-
-| Supports only controller mode. Peripheral mode is not supported
-
-|
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All board specific configurations eg:enabling clock and pin-mux for
-UART pins are required before calling any driver APIs.By default
-Board_Init() API supports all initialization sequence for TI supported
-EVMs. In addition it initializes UART instance for Console/STDIO.Refer
-`Processor SDK RTOS Board
-Support <index_board.html#board-support>`__ for
-additional details.Once board specific configuration is complete 
-MMCSD_init() API can be called to initialize driver.
-
-.. rubric:: **MMCSD Configuration Structure**
-   :name: mmcsd-configuration-structure
-
-The MMCSD_soc.c file binds driver with hardware attributes on the
-board through MMCSD_config structure. This structure must be 
-initialized before the MMCSD_init() function is called and cannot be
-changed afterwards. For details about the individual fields of this
-structure, see the Doxygen help by opening
-\\docs\\doxygen\\html\\index.html
-
-APIs
-^^^^^
-
-Reference for API header file with documentation
-
-::
-
-    #include <ti/drv/mmcsd/MMCSD.h>
-
-.. rubric:: API Call Flow
-   :name: api-call-flow
-
-The below sequence indicates the calling sequence of MMCSD driver APIs
-for a use case of write transaction in blocking mode:
-
-::
-
-     MMCSD_Handle MMCSD;
-     UInt peripheralNum = 0; /* Such as MMCSD0 */
-     MMCSD_Params MMCSDParams;
-     ...
-     MMCSD_Params_init(&MMCSDParams);
-     MMCSD = MMCSD_open(peripheralNum, &MMCSDParams);<br>if (MMCSD == NULL) {<br> /* Error opening MMCSD */
-     ...
-     readOK = MMCSD_read(MMCSD, rxBuffer , startBlock, numBlock); /* Perform MMCSD read */
-     if (!transferOK) { /* MMCSD transaction failed */}
-
-     writeOK = MMCSD_write(MMCSD, TxBuffer , startBlock, numBlock); /* Perform MMCSD write */
-     if (!writeOK) { /* MMCSD transaction failed */}
-
-
-.. rubric:: eMMC Usage
-   :name: emmc-usage
-
-MMCSD driver supports eMMC device. Application need to configure the
-eMMC device for an instance of peripheral. It is also recommended to
-configure the operating bus width of eMMC device.
-
-::
-
-    mmcsdInitCfg[MMCSD_INSTANCE].cardType = MMCSD_CARD_EMMC;
-    mmcsdInitCfg[MMCSD_INSTANCE].supportedBusWidth = MMCSD_BUS_WIDTH_8BIT;
-    MMCSD_init();
-
-.. rubric:: EDMA Usage
-   :name: edma-usage
-
-MMCSD driver supports EDMA operations to transfer data between memory
-and MMCSD peripheral.
-
-Driver uses separate source files for these operations.Refer source
-MMCSD_soc.c for DMA MMCSD SOC configuration. Application need to create
-EDMA handle and update the configuration before MMCSD_init() API.
-
-::
-
-    mmcsdInitCfg[MMCSD_INSTANCE].edmaHandle = MMCSDApp_edmaInit();/* Refer Example/Test */
-    MMCSD_init();
-
-Refer “MMCSD_[Usecase]_[Board/SoC]_DMA_[cpu][Example/Test]project” for
-additional reference. Refer SDK Release Note for supported EVMs.
-
-.. rubric:: UHS Mode Usage
-   :name: uhs-mode-usage
-
-The MMCSD driver supports UHS-I cards. Feature is available for AM57x
-SOC and is dependent on board or platform support for run-time switching
-from 3.0V to 1.8V. Feature is validated on AM572x GP EVM 3.0
-
-Application
-------------
-
-Examples & Unit tests
-^^^^^^^^^^^^^^^^^^^^^
-
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| Name                             |   Description                 |  Expected Results     |  Supported SOCs | Build Type   |
-+==================================+===============================+=======================+=================+==============+
-| MMCSD_FATFS_ExampleProject       |   Example initializes         | When a card is        |  AM335x         |              |
-|                                  |   the card and checks         | detected with valid   |  AM437x         |              |
-|                                  |   for valid FAT               | FAT partition a       |  AM571x         |              |
-|                                  |   partition. When a           | console interface     |  AM572x         |              |
-|                                  |   valid FAT partition         | apperas like "0:> "   |  AM574x         |              |
-|                                  |   is detected console         |                       |  K2G            |              |
-|                                  |   interface for               |                       |  OMAPL137x      |              |
-|                                  |   command execution           |                       |  OMAPL138x      |              |
-|                                  |   is provided.                |                       |                 | CCS Project  |
-|                                  |   Console commands            |                       |                 |              |
-|                                  |   supported are ls            |                       |                 |              |
-|                                  |   (to list files of           |                       |                 |              |
-|                                  |   directory), cd              |                       |                 |              |
-|                                  |   (change directory),         |                       |                 |              |
-|                                  |   pwd (present                |                       |                 |              |
-|                                  |   working directory)          |                       |                 |              |
-|                                  |   and cat (text file          |                       |                 |              |
-|                                  |   read operation).            |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_Test_Project               |                               | Prints  on  console   |  AM335x         |              |
-|                                  |   Unit Test                   | All tests have passed |  AM437x         |              |
-|                                  |   application                 |                       |  AM571x         |              |
-|                                  |   demonstrating write         |                       |  AM572x         |              |
-|                                  |   and read a fixed            |                       |  AM574x         | CCS Project  |
-|                                  |   number of bytes             |                       |  K2G            |              |
-|                                  |   into MMCSD card.            |                       |  OMAPL137x      |              |
-|                                  |   Verifies written            |                       |  OMAPL138x      |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL.         |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_DMA_Test_Project           |                               | Prints on console     |  AM335x         |              |
-|                                  |   Unit Test                   | All tests have passed |  AM437x         |              |
-|                                  |   application                 |                       |  AM571x         |              |
-|                                  |   demonstrating write         |                       |  AM572x         |              |
-|                                  |   and read a fixed            |                       |  AM574x         | CCS Project  |
-|                                  |   number of bytes             |                       |  K2G            |              |
-|                                  |   into MMCSD card.            |                       |  OMAPL137x      |              |
-|                                  |   Verifies written            |                       |  OMAPl138x      |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL.         |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_SMP_Test_Project           |                               | Prints  on  console   |  AM572x - EVM   |              |
-|                                  |   Unit Test                   | All tests have passed |                 |              |
-|                                  |   application                 |                       |                 |              |
-|                                  |   demonstrating write         |                       |                 |              |
-|                                  |   and read a fixed            |                       |                 | CCS Project  |
-|                                  |   number of bytes             |                       |                 |              |
-|                                  |   into MMCSD card.            |                       |                 |              |
-|                                  |   Verifies written            |                       |                 |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL in SMP   |                       +-----------------+--------------+
-|                                  |   mode.                       |                       |  am65xx,j721e   |   makefile   |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_SMP_DMA_Test_Project       |                               | Prints on console     |  AM572x - EVM   |              |
-|                                  |   Unit Test                   | All tests have passed |                 |              |
-|                                  |   application                 |                       |                 |              |
-|                                  |   demonstrating write         |                       |                 |              |
-|                                  |   and read a fixed            |                       |                 | CCS Project  |
-|                                  |   number of bytes             |                       |                 |              |
-|                                  |   into MMCSD card.            |                       |                 |              |
-|                                  |   Verifies written            |                       |                 |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL in SMP   |                       +-----------------+--------------+
-|                                  |   mode with DMA enabled.      |                       |  am65xx,j721e   |   makefile   |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_EMMC_TestProject           |                               | Prints on console     |  AM335x         |              |
-|                                  |   Unit Test                   | All tests have passed |  AM437x         |              |
-|                                  |   application                 |                       |  AM571x         |              |
-|                                  |   demonstrating write         |                       |  AM572x         |              |
-|                                  |   and read a fixed            |                       |  AM574x         | CCS Project  |
-|                                  |   number of bytes             |                       |  K2G            |              |
-|                                  |   into eMMC device.           |                       |  OMAPL137x      |              |
-|                                  |   Verifies written            |                       |  OMAPL138x      |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL.         |                       |                 |              |
-|                                  |                               |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_EMMC_DMA_TestProject       |                               | Prints on console     |  AM335x         |              |
-|                                  |   Unit Test                   | All tests have passed |  AM437x         |              |
-|                                  |   application                 |                       |  AM571x         |              |
-|                                  |   demonstrating write         |                       |  AM572x         |              |
-|                                  |   and read a fixed            |                       |  AM574x         |              |
-|                                  |   number of bytes             |                       |  K2G            | CCS Project  |
-|                                  |   into eMMC device.           |                       |  OMAPL137x      |              |
-|                                  |   Verifies written            |                       |  OMAPL138x      |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL.         |                       |                 |              |
-|                                  |                               |                       |                 |              |
-|                                  |                               |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMC Test Application             |                               | Prints on console     |                 |              |
-|                                  |   Unit Test                   | All tests have passed |                 |              |
-|                                  |   application                 |                       |                 |              |
-|                                  |   demonstrating write         |                       |                 |              |
-|                                  |   and read a fixed            |                       |                 |              |
-|                                  |   number of bytes             |                       |                 |              |
-|                                  |   into MMC device.            |                       |                 |              |
-|                                  |   Verifies written            |                       |                 |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL.         |                       |                 |              |
-|                                  |   Supported only on           |                       |                 |              |
-|                                  |   OMAPL137 platform.          |                       |  OMAPL137x      | CCS Project  |
-|                                  |                               |                       |                 |              |
-|                                  |   There is no on-board        |                       |                 |              |
-|                                  |   eMMC chip on OMAPL137       |                       |                 |              |
-|                                  |   platform. Need to use       |                       |                 |              |
-|                                  |   external MMC card           |                       |                 |              |
-|                                  |   inserted into MMCSD         |                       |                 |              |
-|                                  |   slot of the board.          |                       |                 |              |
-|                                  |   Currently the driver        |                       |                 |              |
-|                                  |   supports standard MMC       |                       |                 |              |
-|                                  |   card and other cards        |                       |                 |              |
-|                                  |   like MMCplus may not        |                       |                 |              |
-|                                  |   work. The example           |                       |                 |              |
-|                                  |   requires the card           |                       |                 |              |
-|                                  |   size to be at least         |                       |                 |              |
-|                                  |   2GB.                        |                       |                 |              |
-|                                  |                               |                       |                 |              |
-|                                  |                               |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_TestApp                    |                               | Prints on console     |                 |              |
-|                                  |   Unit Test                   | All tests have passed |                 |              |
-|                                  |   application                 |                       |                 |              |
-|                                  |   demonstrating write         |                       |                 |              |
-|                                  |   and read a fixed            |                       |                 |              |
-|                                  |   number of bytes             |                       |  AM65x          | Makefile     |
-|                                  |   into MMCSD card.            |                       |  J721e          |              |
-|                                  |   Verifies written            |                       |                 |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL.         |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-|  MMCSD_DMA_TestApp               |   Functionally same           | Prints on console     |                 |              |
-|                                  |   as MMCSD_TestApp            | All tests have passed |                 |              |
-|                                  |   but with DMA enabled        |                       |  AM65x          | Makefile     |
-|                                  |                               |                       |  J721e          |              |
-|                                  |                               |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_EMMC_TestApp               |                               |                       |                 |              |
-|                                  |   Unit Test                   | Prints  on console    |                 |              |
-|                                  |   application                 | All tests have passed |                 |              |
-|                                  |   demonstrating write         |                       |                 |              |
-|                                  |   and read a fixed            |                       |  AM65x          | Makefile     |
-|                                  |   number of bytes             |                       |  J721e          |              |
-|                                  |   into the onboard            |                       |                 |              |
-|                                  |   EMMC.Verifies written       |                       |                 |              |
-|                                  |   data pattern to             |                       |                 |              |
-|                                  |   conclude PASS/FAIL.         |                       |                 |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_EMMC_DMA_TestApp           |   Functionally                | Prints on console     |                 |              |
-|                                  |   Same as EMMC_TestApp        | All tests have passed |  AM65x          | Makefile     |
-|                                  |   but using  DMA mode         |                       |  J721e          |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_Baremetal_TestApp          |   Baremetal version of        | Prints on console     |                 |              |
-|                                  |   MMCSD_TestApp               | All tests have passed |                 |              |
-|                                  |                               |                       |  AM65x          | Makefile     |
-|                                  |                               |                       |  J721e          |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_Baremetal_DMA_TestApp      |   Baremetal version of        | Prints on console     |                 |              |
-|                                  |   MMCSD_EMMC_TestApp          | All tests have passed |                 |              |
-|                                  |                               |                       |  AM65x          | Makefile     |
-|                                  |                               |                       |  J721e          |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_Baremetal_EMMC_TestApp     |   Baremetal version of        | Prints on console     |                 |              |
-|                                  |   MMCSD_EMMC_TestApp          | All tests have passed |                 |              |
-|                                  |                               |                       |  AM65x          | Makefile     |
-|                                  |                               |                       |  J721e          |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_Baremetal_EMMC_DMA_TestApp |   Functionally same as        | Prints on console     |                 |              |
-|                                  |   MMCSD_Baremetal_EMMC_TestApp| All tests have passed |                 |              |
-|                                  |   but with DMA enabled        |                       |  AM65x          | Makefile     |
-|                                  |                               |                       |  J721e          |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_Regression_TestApp         |   Menu driven regression test | Prints on console     |                 |              |
-|                                  |   which tests various         | All tests have passed |  AM65x          | Makefile     |
-|                                  |   configurations of SD card   |                       |  J721e          |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-| MMCSD_EMMC_Regression_TestApp    |   Menu driven regression test | Prints on console     |                 |              |
-|                                  |   which tests various         | All tests have passed |  AM65x          | Makefile     |
-|                                  |   configurations of EMMC      |                       |  J721e          |              |
-+----------------------------------+-------------------------------+-----------------------+-----------------+--------------+
-
-Benchmarking Read/Write Performance (on AM65x/J721e)
------------------------------------------------
-
-The MMCSD_<EMMC>_Regression_TestApp application (listed above) measures
-read/write throughput (in mega bytes per sec).
-
-It measures the following:
-
-- RAW read/write throughput:  This involves the reading/writing of a continuous
-  block of data, say 1MB data buffer on to the SD/eMMC using
-  MMCSD_Read()/MMCSD_Write().
-
-- FATFS read/write (SD Only) throughput: This involves reading/writing of a 1MB
-  buffer of data through f_read()/f_write(). Please note that FAT32 is tested
-  with SD card only
-
-Benchmarking Steps
-------------------
-
-The performance benchmarks on SD Read/Write can be done with the following
-steps:
-
-- Load the MMCSD_Regression_TestApp on A53/R5 core of AM65x or mpu1_0/mcu1_0
-  core of J721e
-
-- Insert SD Card formatted with FAT32 format preferably with allocation
-  size=4096 bytes for better performance.
-
-- Run the application. It presents with a menu of various modes the SD card
-  which can be run on the UART console
-
-- Select the desired mode from the list (say HS mode) and press Enter
-
-- The test will run RAW & FATFS read/writes of various buffer sizes 256K, 512K,
-  1024K and 2048K. This might take a minute or two to complete.
-
-- Two tables are printed at the end of the test run for this mode with RAW &
-  FATFS throughput numbers for each buffer size.
-
-- Note: Instead of running each mode seperately, you can select "All non
-  powercycle tests" option (-1)  which runs all the supported modes along with
-  the throughput numbers for each of them.
-
-
-EMMC performance benchmarks can be measured with the following steps
-
-- Load the MMCSD_EMMC_Regression_TestApp on A53/R5 core of AM65x or
-  mpu1_0/mcu1_0 core of J721e
-
-- Run the application. It presents with a menu of various eMMC modes which can
-  be run on the UART console
-
-- Select the desired mode from the list (say HS-DDR mode) and press Enter
-
-- The test will run RAW read/writes of various buffer sizes 256K, 512K, 1024K
-  and 2048K. This might take a minute or two to complete.
-
-- A table is printed at the end of the test with the RAW throughput numbers for
-  each buffer size.
-
-.. note:: Instead of running each mode seperately, you can select "All non
-   powercycle tests" option (-1)  which runs all the supported modes along with
-   the throughput numbers for each of them.
-
-Building CCS projects based examples
-------------------------------------
-
-CCS Projects mentioned in the above table are built using pdkProjectCreate.bat/sh as explained in
-`PDK Example and Test Project Creation <index_overview.html#pdk-example-and-test-project-creation>`__
-
-
-Building MMCSD Test applications via makefiles
-----------------------------------------------
-
-- MMCSD Test applications and dependent libraries are built from the top level
-  mmcsd makefile
-
-- Refer to the `Processor SDK RTOS Getting Started Guide
-  <index_overview.html#setup-environment>`__  for details of how to setup the
-  build environment. Once you have setup the build environment, issue the
-  following commands:
-
-   - cd <pdk>/packages/
-
-   - To build: make mmcsd
-
-   - To clean: make mmcsd_clean
-
-- Similarly, to build at the module level, issue the following commands for
-  rebuilding:
-
-   - cd <pdk>/packages/ti/drv/mmcsd
-
-   - To build: make all
-
-   - To clean: make clean
-
-
-Additional References
----------------------
-
-+-----------------------------------+--------------------------------------------+
-| **Document**                      | **Location**                               |
-+-----------------------------------+--------------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti        |
-|                                   | \\drv\\mmcsd\\docs\\doxygen\\html\\inde    |
-|                                   | x.html                                     |
-+-----------------------------------+--------------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti        |
-|                                   | \\drv\\mmcsd\\docs\\ReleaseNotes_MMCS      |
-|                                   | D_LLD.pdf                                  |
-+-----------------------------------+--------------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_NWAL.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_NWAL.rst
deleted file mode 100644
index 2f73ee495..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_NWAL.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_NWAL
-
-|
-
-.. rubric:: Introduction
-   :name: introduction
-
-| The NWAL (Network Adaptation Layer) driver provides a well-defined set
-  of APIs which could be used for applications interfacing with NetCP
-  (Network Coprocessor) module in Keystone family of SOCs (C66x, K2x).
-
-.. rubric:: Driver Features
-   :name: driver-features
-
--  Initialization of NetCP low level driver resources
--  Initialization of Packet DMA related resources associated with NetCP
--  Classification of incoming packets based on L2: MAC header fields
--  Classification of incoming packets based on L3: IPv4/IPv6 header
-   fields
--  Routing of packets to host based on L4: UDP/TCP/GTP-U
--  Unidirectional IPSec SA creation and deletion
--  In band offload of IPSec encryption/decryption for the outgoing
-   packets
--  Access to SA data mode acceleration for data plane applications.
--  Supports offload of the following features to NETCP Hardware during
-   transmission of packets:
-
-   -  IPv4 checksum/L4:TCP/UDP checksum/IPSec Encryption
-   -  Redirection of packets through a specific MAC port
-   -  Software Insertion of L2/L3/L4 header
-
--  Upon reception of packet, module provides additional meta data
-   details including:
-
-   -  Status of IP checksum/UDP/TCP checksum results
-   -  Offset to L2/L3/L4 protocol offsets. Appropriate layer offset will
-      be valid only if classification or routing is enabled at NETCP
-   -  Ingress MAC port information
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-Following modes of operations are supported by NWAL when sending control
-configuration request to configure NetCP firmware. **BLOCKING Mode**: In
-this mode, status of API request used to configure NetCP is returned
-back in API call context.
-
-**Non-BLOCKING Mode**: In this mode, application can invoke a separate
-poll routine to retrieve status response result.
-
-|
-
-.. rubric:: Driver Configuration
-   :name: driver-configuration-nwal
-
-The driver configures the NWAL subsystem using the nwalGlobCfg_t
-structure.
-
-This structure must be initialized before the nwal_create() function API
-is called and cannot be changed afterwards. For details regarding
-individual fields of this structure, see the Doxygen help by opening
-PDK_INSTALL_DIR/packages/ti/drv/nwal/docs/doxygen/html/index.html.
-
-.. rubric:: **APIs**
-   :name: apis
-
-API reference for application can be found in below file:
-
-::
-
-    #include <ti/drv/nwal/nwal.h>
-
-.. rubric:: Example
-   :name: example
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results      |
-+=======================+=======================+=======================+
-| nwalUnitTest          | | Unit Test           | | User observes the   |
-| Application           |   application to test |   output printed over |
-|                       |   all APIs            |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-
-.. rubric:: Additional References
-   :name: additional-references
-
-
-.. list-table::
-   :header-rows: 1
-
-   * - **Document**
-
-     - **Location**
-
-   * - API Reference Manual
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/nwal/docs/doxygen/html/index.html``
-
-   * - Release Notes
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/nwal/docs/ReleaseNotes_NWAL_LLD.pdf``
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_PA.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_PA.rst
deleted file mode 100644
index 121241260..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_PA.rst
+++ /dev/null
@@ -1,181 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_PA
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The packet accelerator (PA) is one of the main components of the network
-coprocessor (NETCP) peripheral in KeyStone devices, including C6678,
-K2H/K/E/L. The PA works together with the security accelerator (SA) and
-the gigabit Ethernet switch subsystem to form a network processing
-solution. The purpose of PA in the NETCP is to perform packet processing
-operations such as packet header classification, checksum generation,
-and multi-queue routing.
-
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The driver configures the PASS subsystem using Pa_config_t structure.
-This structure must be initialized before the Pa_create() function is
-called and cannot be changed afterwards. Also, there are bunch of
-system/global configurations and per entry configurations for PA. For
-details about individual fields of this structure and other
-configuration API structures, see the Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\PA\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-API reference for application can be found in below file:
-
-::
-
-    #include <ti/drv/PA/PA.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results      |
-+=======================+=======================+=======================+
-| PA_Example            | | Example             | | User observes the   |
-| application           |   demonstrating       |   output printed over |
-|                       |   *simple emac        |   the CCS console     |
-|                       |   loopback* use case. |                       |
-|                       |   Reference example   |                       |
-|                       |   for developers      |                       |
-+-----------------------+-----------------------+-----------------------+
-| PA_UnitTestApplicatio | | Unit Test           | | User observes the   |
-| n                     |   application to test |   output printed over |
-|                       |   all APIs            |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-| PA_PktCapTestApplicat | | Packet Capture Unit | | User observes the   |
-| ion                   |   Test application.   |   output printed over |
-|                       |                       |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-
-FAQ
----
-
-.. rubric:: What is the difference between internal loopback and
-   external loopback?
-   :name: what-is-the-difference-between-internal-loopback-and-external-loopback
-
--  CPSW_LOOPBACK_INTERNAL (default): The transmitted packet is
-   loopbacked at the SGMII through SGMII internal loopback
--  CPSW_LOOPBACK_EXTERNAL: The transmitted packet should be loopbacked
-   by an application outside of the SOC, e.g., PC, PHY.
-
-.. rubric:: How to test PA EMAC example with a PC?
-   :name: how-to-test-pa-emac-example-with-a-pc
-
-The EVM has to be connected to PC via RJ-45 port. By default, the PA
-example uses the internal loopback mode, please change code: int
-cpswLpbkMode = CPSW_LOOPBACK_INTERNAL to CPSW_LOOPBACK_EXTERNAL.
-
-To test the egress path (from SOC to PC):
-
--  Rebuilt the CCS project, load and run.
--  The PC should receive 10 identical UDP packets sending out by the PA
-   example, the packet is defined by an array pktMatch[] in the code.
-
-To test the ingress direction (from PC to SOC): The PC needs a tool to
-send out packets with controlled MAC address, IP address and UDP port
-matching the PA layer 2, 3 and 4 classifications, defined by the
-following functions:
-
--  Add_MACAddress(): ethInfo.dst
--  Add_IPAddress(): ipInfo.dst
--  Add_Port (): ports
-
-.. rubric:: How to use PA EMAC example to test other Ethernet ports than
-   default?
-   :name: how-to-use-pa-emac-example-to-test-other-ethernet-ports-than-default
-
-The Keystone devices may have multiple Ethernet ports, connected through
-an internal GbE switch with a host port. There is a pre-defined symbol
-"NUM_PORTS" in the text file when creating the PA project. This controls
-how many ports used in loopback mode test. In non-loopback case, the
-port number may be hardcoded by gNum_Mac_Ports. This has to be changed
-for the test. On EVMs, those additional Ethernet ports may be accessed
-by various ways: Rear-Transition Module – Breakout Card (RTM-BOC) or
-Advanced Mezzanine Card – Breakout Card (AMC-BOC), or AMC backplane,
-they are EVM hardware dependent. For example, K2E has 8 SGMII ports. In
-the K2E EVM, two Ethernet PHYs (PHY1 and PHY2) are connected to SoC
-SGMII 0 and 1 respectively, to provide a copper interface and routed to
-a Gigabit RJ-45 connector. The SGMII 2 and 3 of SoC are routed to Port 0
-and 1 of the AMC edge connector backplane interface. The SGMII 4 to 7
-are routed to RTM connector which can be accessed by RTM BOC. The PA
-EMAC example by default tests all 8 ports in loopback. To test
-additional ports in non-loopback, check/modify the gNum_Mac_Ports
-defined to include the SGMII testing port.
-
-.. rubric:: Can PA be used to forward all incoming packets to host?
-   :name: can-pa-be-used-to-forward-all-incoming-packets-to-host
-
-The design of PA is to use firmware to offload host for classifying
-packets, the PA has layer 2, 3 and 4 classifications. PA LLD supports
-two APIs to add MAC LUT1 classification and routing. The application can
-call either the first generation API Pa_addMac() or the second
-generation Pa_addMac2() APIs. When using the first API, initialize all
-the elements of paEthInfo_t with zero and update the routing info
-paRouteInfo_t with pa_DEST_HOST. When using the second generation API,
-paEthInfo2_t with validBitMap = 0 and paRouteInfo2_t (in paParamDesc)
-with pa_DEST_HOST can be passed. Please refer to Pa_addMac and
-Pa_addMac2() API explanations as provided under the doxygen folder of PA
-(Or refer to Pa.h interface header file).
-
-.. rubric:: What are the right PA/NETCP/Ethernet user guides to use for different keystone devices?
-   :name: what are the right PA/NETCP/Ethernet user guides to use for different keystone devices
-
--	All Keystone I (C665x, C667x) devices use the same Serdes and documented in respective datasheets (See Device State Control Registers)
--   All Keystone II (K2H, K2K, K2G, K2E, K2L) device use the same Serdes and documented in http://www.ti.com/lit/pdf/SPRUHO3
--	For Keystone I, C667x has PA and NETCP GEN1, C665x has neither
--	For Keystone II, K2H/K2K use the same PA and NETCP GEN1 as C667x, K2E/K2L uses a different PA2 and NETCP GEN2
--	For Keystone II, K2G has neither PA nor NETCP
-
-To summarize:
-
-+--------+--------------------+----------------------------------+----------------------------------+----------------------------------+
-| SOC    | Serdes             | Ethernet                         | PA                               | Netcp                            |
-+--------+--------------------+----------------------------------+----------------------------------+----------------------------------+
-|C665x   |See datasheet       |http://www.ti.com/lit/pdf/SPRUHH1 |N/A                               |N/A                               |
-+--------+--------------------+----------------------------------+----------------------------------+----------------------------------+
-|C667x   |See datasheet       |http://www.ti.com/lit/pdf/SPRUGV9 |http://www.ti.com/lit/pdf/SPRUGS4 |http://www.ti.com/lit/pdf/SPRUGZ6 |
-|        |                    |                                  |Driver: lib\<CPU>\ti.drv.pa       |                                  |
-+--------+--------------------+----------------------------------+----------------------------------+----------------------------------+
-|K2H/K2K |http://www.ti.com/  |Same as C667x                     |Same as C667x	                    |Same as C667x                     |
-|        |lit/pdf/SPRUHO3     |                                  |                                  |                                  |
-+--------+--------------------+----------------------------------+----------------------------------+----------------------------------+
-|K2G     |Same as K2H/K2K     |http://www.ti.com/lit/pdf/SPRUHY8 |N/A                               |N/A                               |
-+--------+--------------------+----------------------------------+----------------------------------+----------------------------------+
-|K2E/K2L |Same as K2H/K2K     |http://www.ti.com/lit/pdf/SPRUHZ3 |http://www.ti.com/lit/pdf/SPRUHZ2 |http://www.ti.com/lit/pdf/SPRUHZ0 |
-|        |                    |                                  |Driver: lib\<CPU>\ti.drv.pa2      |                                  |
-+--------+--------------------+----------------------------------+----------------------------------+----------------------------------+
-
-
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\PA\\docs\\doxygen\\html\\index.h |
-|                                   | tml                                     |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\PA\\docs\\ReleaseNotes_PA_LLD.   |
-|                                   | pdf                                     |
-+-----------------------------------+-----------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_PCIe.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_PCIe.rst
deleted file mode 100644
index e9f57d107..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_PCIe.rst
+++ /dev/null
@@ -1,488 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_PCIe
-
-Overview
---------
-
-PCIe module supports dual operation mode: End Point (EP or Type0) or
-Root Complex (RC or Type1). This driver focuses on EP mode but it also
-provides access to some basic RC configuration/functionality. For RC
-this is the lowest level; additional software is needed to perform
-generic enumeration of third party devices.
-
-The PCIe subsystem has two address spaces. The first (Address Space 0)
-is dedicated for local application registers, local configuration
-accesses and remote configuration accesses. The second (Address Space 1)
-is dedicated for data transfer. This PCIe driver focuses on
-configuration of the interface and sending/receiving interrupts via
-Address Space 0. Data is transferred outside the scope of the LLD using
-CPU or EDMA through the data area.
-
-There are three revisions of the pcie hardware. The first, v0, in KeyStone
-devices (C66x, K2x). The second, v1, is in AM57xx devices. The third,
-v2, is in AM65xx devices.  The LLD
-abstacts the configuration of standards-based PCIe registers (Type 0,
-Type 1 and Capabilities registers) so same user code can be used on both
-device types. However, there are different interfaces for the registers
-not based on PCIe standards (port logic and ti-conf which generally
-covers interrupts and address translation). That portion of user code
-needs to differ between C66x/K2x, AM57xx, and AM65xx devices.
-
-The example includes configuration of one SoC as EP and a second as RC.
-It then performs a simple CPU-based memory transfer (EDMA can be used
-via the same addresses used by the CPU), and interrupt generation (from
-EP) and reception (to RC). It also shows differences in user code
-required to support both C66x/K2x, AM57xx and AM65xx devices.
-
-.. rubric:: Differences in Operation between C66x/K2x and AM57xx devices
-   :name: differences-in-operation-between-c66xk2x-and-am57xx-devices
-
-C66x/K2x, AM57xx, and AM65xx are functionally identical, except that interrupts
-are handled by example and lld only on AM57xx.  Also older devices only support
-gen 1/2, while AM65xx supports gen 3.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-The LLD is intended to bring up the PCIe peripheral, open memory
-mappings, and send/receive interrupts.
-
-.. rubric:: Root Complex (RC)
-   :name: root-complex-rc
-
-The PCIe peripheral can be used as a root complex. One or more other
-endpoints can be connected (more than one requires a PCIe switch on the
-board). The LLD configures the peripheral in RC mode. It doesn't attempt
-to emulate the full enumeration capability of a Linux driver. Instead
-the user will need to supply code specific to each endpoint they intend
-to support.
-
-.. rubric:: Endpoint (EP)
-   :name: endpoint-ep
-
-The PCIe peripheral can be used as an endpoint. This is the more
-intended usecase for the LLD. Once the link is initialized, the LLD can
-provide data addresses and send interrupts to the RC.
-
-.. rubric:: Interrupts
-   :name: interrupts
-
-The example for AM57XX provides code to send interrupts from an
-endpoint, and the LLD/example together contain code to receive/demux the
-interrupts (both MSI and Legacy) on an RC.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: Board-specific configuration
-   :name: board-specific-configuration
-
-PCIe's board specific configuration is in the example in
-PDK_INSTALL_DIR/packages/ti/drv/pcie/example/sample/am57x/src/pcie_sample_board.c.
-Calling sequence is in example and repeated below.
-
-.. rubric:: PCIe configuration structure
-   :name: pcie-configuration-structure
-
-The pcie_soc.c binds the driver to the hardware on the board. It is
-passed into the driver via the call to Pcie_init().
-
-API Call Flow
-^^^^^^^^^^^^^
-
-The API call flow is covered in pcie_sample.c.
-
-The overall components are:
-
-#. Initialize the driver
-#. Initialize the SERDES and Power the peripheral (see example code for
-   order for each device)
-#. Configure RC or EP symmetrically to talk to another similar device
-#. Perform data IO and interrupt.
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------+-----------------+-----------------+-----------------+
-| Name            | Description     | EVM             | Expected        |
-|                 |                 | Configuration   | Results         |
-+=================+=================+=================+=================+
-| PCIE_idkAM57[1\ | 2-device PCIe   | **IMPORTANT:**  | **AM572x/AM574x |
-| 24]x*ExamplePr\ | connection      | Cable must be   | or AM571x       |
-| oject           |                 | `MODIFIED`_     | EVM** : One     |
-|                 |                 | in order to     | board is        |
-|                 |                 | avoid damaging  | EP/other is RC; |
-|                 |                 | the clock       | link is         |
-|                 |                 | drivers in the  | established and |
-|                 |                 | SoC!            | data/interrupts |
-|                 |                 |                 | exchanged. All  |
-|                 |                 |                 | printed output  |
-|                 |                 | Connect two     | goes to the     |
-|                 |                 | like AM57xx     | serial console. |
-|                 |                 | IDK EVMs J22    |                 |
-|                 |                 | `MODIFIED`_     |                 |
-|                 |                 | male-male       |                 |
-|                 |                 | crossover       |                 |
-|                 |                 | PCIe x1 or x4   |                 |
-|                 |                 | cable and       |                 |
-|                 |                 | optional        |                 |
-|                 |                 | straight-through|                 |
-|                 |                 | extender. For   |                 |
-|                 |                 | AM572x/AM574x   |                 |
-|                 |                 | we used a       |                 |
-|                 |                 | one-lane        |                 |
-|                 |                 | cross cable;    |                 |
-|                 |                 | for AM571x we   |                 |
-|                 |                 | used a 4-lane   |                 |
-|                 |                 | cross cable.    |                 |
-|                 |                 | | Projects      |                 |
-|                 |                 | available for   |                 |
-|                 |                 | C66, A15, and   |                 |
-|                 |                 | M4.             |                 |
-|                 |                 |                 |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| PCIE_sample_Ex\ | 2-device PCIe   | **IMPORTANT:**  | **AM65xx IDK**  |
-| ampleProject    | connection      | Cable must be   | One board is EP/|
-|                 |                 | `MODIFIED`_     | other           |
-| (for AM65xx IDK)|                 | in order to     | is              |
-|                 |                 | avoid damaging  | RC;             |
-|                 |                 | the clock       | link is         |
-|                 |                 | drivers in the  | established and |
-|                 |                 | SoC!            | data            |
-|                 |                 |                 | exchanged. All  |
-|                 |                 |                 | printed output  |
-|                 |                 | Connect two     | goes to the     |
-|                 |                 | like AM65xx     | serial console. |
-|                 |                 | IDK EVMs PCIe   |                 |
-|                 |                 | using a         |                 |
-|                 |                 | `MODIFIED`_     |                 |
-|                 |                 | male-male       |                 |
-|                 |                 | crossover       |                 |
-|                 |                 | PCIe x1 or x4   |                 |
-|                 |                 | cable and       |                 |
-|                 |                 | optional        |                 |
-|                 |                 | straight-through|                 |
-|                 |                 | extender.       |                 |
-|                 |                 |                 |                 |
-|                 |                 | We used a       |                 |
-|                 |                 | one-lane        |                 |
-|                 |                 | cross cable.    |                 |
-|                 |                 |                 |                 |
-|                 |                 | Executables     |                 |
-|                 |                 | for A53 (mpu)   |                 |
-|                 |                 | and R5 (mcu)    |                 |
-|                 |                 | available.      |                 |
-|                 |                 |                 |                 |
-|                 |                 | Note: this is   |                 |
-|                 |                 | NOT a CCS       |                 |
-|                 |                 | project.  It    |                 |
-|                 |                 | is built from   |                 |
-|                 |                 | running         |                 |
-|                 |                 | ``make pcie``   |                 |
-|                 |                 | from $(TI_PDK\  |                 |
-|                 |                 | _INSTALL_DIR)/\ |                 |
-|                 |                 | packages.       |                 |
-|                 |                 | Result is in    |                 |
-|                 |                 | ti/binary.      |                 |
-|                 |                 |                 |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| PCIE_evmK2G*Ex\ | 2-device PCIe   | **IMPORTANT:**  | **K2G EVM** :   |
-| ampleProject    | connection      | Cable must be   | One board is    |
-|                 |                 | `MODIFIED`_     | EP/other is RC; |
-|                 |                 | in order to     | link is         |
-|                 |                 | avoid damaging  | established and |
-|                 |                 | the clock       | data is         |
-|                 |                 | drivers in the  | exchanged. All  |
-|                 |                 | SoC!            | printed output  |
-|                 |                 |                 | goes to serial  |
-|                 |                 |                 | console.        |
-|                 |                 |                 |                 |
-|                 |                 | Connect two     |                 |
-|                 |                 | K2G  EVMs J5    |                 |
-|                 |                 | using a         |                 |
-|                 |                 | `MODIFIED`_     |                 |
-|                 |                 | male-male       |                 |
-|                 |                 | crossover       |                 |
-|                 |                 | PCIe x1 cable   |                 |
-|                 |                 | and optional    |                 |
-|                 |                 | straight-through|                 |
-|                 |                 | extender. We    |                 |
-|                 |                 | used a          |                 |
-|                 |                 | one-lane        |                 |
-|                 |                 | cross cable.    |                 |
-|                 |                 | Ensure that     |                 |
-|                 |                 | jumper J15 is   |                 |
-|                 |                 | positioned to   |                 |
-|                 |                 | the left hand   |                 |
-|                 |                 | two pins as     |                 |
-|                 |                 | viewed with     |                 |
-|                 |                 | "J15"           |                 |
-|                 |                 | silkscreen      |                 |
-|                 |                 | right side up   |                 |
-|                 |                 | (pin 0 isn't    |                 |
-|                 |                 | clearly         |                 |
-|                 |                 | marked). In     |                 |
-|                 |                 | the right       |                 |
-|                 |                 | hand            |                 |
-|                 |                 | position, the   |                 |
-|                 |                 | PCIe PLL will   |                 |
-|                 |                 | NOT get         |                 |
-|                 |                 | clock.          |                 |
-|                 |                 | Projects        |                 |
-|                 |                 | available for   |                 |
-|                 |                 | C66 and A15.    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| PCIE_idkAM571x\ | Packet Exchange | **IMPORTANT:**  | **AM571X        |
-| _*armEdmaPktEx\ | over PCIe       | Cable must be   | >=REV1.3A       |
-| ampleProject    | Benchmark       | `MODIFIED`_     | IDK** : One     |
-| *(Available     |                 | in order to     | board is        |
-| starting in     |                 | avoid damaging  | EP/other is RC; |
-| Processor-SDK   |                 | the clock       | link is         |
-| 3.1)*           |                 | drivers in the  | established and |
-|                 |                 | SoC!            | data is         |
-|                 |                 |                 | exchanged.      |
-|                 |                 |                 | Produces same   |
-|                 |                 |                 | output as       |
-|                 |                 |                 | standard        |
-|                 |                 |                 | ExampleProject, |
-|                 |                 | Connect two     | except EP also  |
-|                 |                 | like            | prints packet   |
-|                 |                 | >=REV1.3A       | exchange        |
-|                 |                 | AM571x  IDK     | benchmark       |
-|                 |                 | EVMs J22        | results.        |
-|                 |                 | using a         |                 |
-|                 |                 | `MODIFIED`_     |                 |
-|                 |                 | male-male       |                 |
-|                 |                 | crossover       |                 |
-|                 |                 | PCIe x4 cable   |                 |
-|                 |                 | and optional    |                 |
-|                 |                 | straight-through|                 |
-|                 |                 | extender. We    |                 |
-|                 |                 | used a 4-lane   |                 |
-|                 |                 | cross cable.    |                 |
-|                 |                 | Projects        |                 |
-|                 |                 | available for   |                 |
-|                 |                 | A15 only.       |                 |
-|                 |                 | >=REV1.3A EVM   |                 |
-|                 |                 | required (for   |                 |
-|                 |                 | x4 PCIe         |                 |
-|                 |                 | connectors).    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| Remaining       | 2-device PCIe   | Connect two     | **6678, 6657,   |
-| PCIE_*ExampleP\ | connection      | like C66x/K2x   | K2E, K2H,       |
-| roject          |                 | (except K2G,    | K2L** : One     |
-|                 |                 | see previous    | board is        |
-|                 |                 | row) EVMs using | EP/other is RC; |
-|                 |                 | an AMC breakout | link is         |
-|                 |                 | card. For K2L,  | established and |
-|                 |                 | it is necessary | data exchanged. |
-|                 |                 | to configure    | For A15         |
-|                 |                 | the mux via the | projects, all   |
-|                 |                 | BMC console     | printed output  |
-|                 |                 | with            | goes to serial  |
-|                 |                 | "interface_muxs | console. For    |
-|                 |                 | el              | C66 projects,   |
-|                 |                 | pcie" command.  | all printed     |
-|                 |                 | Projects        | output goes to  |
-|                 |                 | available for   | CCS console.    |
-|                 |                 | A15 and/or C66  |                 |
-|                 |                 | as present in   |                 |
-|                 |                 | each device.    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| PCIE_Qos_Examp\ | 2-device PCIe   | **IMPORTANT:**  | **AM65xx IDK**  |
-| leProject       | connection      | Cable must be   | One board is EP/|
-|                 |                 | `MODIFIED`_     | other           |
-| (for AM65xx IDK)|                 | in order to     | is              |
-|                 |                 | avoid damaging  | RC;             |
-|                 |                 | the clock       | link is         |
-|                 |                 | drivers in the  | established and |
-|                 |                 | SoC!            | data            |
-|                 |                 |                 | exchanged with  |
-|                 |                 |                 | TC0/TC1/TC2(DDR)|
-|                 |                 | Connect two     | /TC3(MSMC).     |
-|                 |                 | like AM65xx     | Then PCIE CPU   |
-|                 |                 | IDK EVMs PCIe   | read latency    |
-|                 |                 | using a         | with TC3 is     |
-|                 |                 | `MODIFIED`_     | measured with   |
-|                 |                 | male-male       | background PCIE |
-|                 |                 | crossover       | read traffic    |
-|                 |                 | PCIe x1 or x4   | over TC0 using  |
-|                 |                 | cable and       | DMA.            |
-|                 |                 | optional        | All printed     |
-|                 |                 | straight-through| output goes to  |
-|                 |                 | extender.       | serial console. |
-|                 |                 |                 |                 |
-|                 |                 | We used a       |                 |
-|                 |                 | one-lane        |                 |
-|                 |                 | cross cable.    |                 |
-|                 |                 |                 |                 |
-|                 |                 | Executables     |                 |
-|                 |                 | for A53 (mpu)   |                 |
-|                 |                 | and R5 (mcu)    |                 |
-|                 |                 | available.      |                 |
-|                 |                 |                 |                 |
-|                 |                 | Note: this is   |                 |
-|                 |                 | NOT a CCS       |                 |
-|                 |                 | project.  It    |                 |
-|                 |                 | is built from   |                 |
-|                 |                 | running         |                 |
-|                 |                 | ``make pcie``   |                 |
-|                 |                 | from $(TI_PDK\  |                 |
-|                 |                 | _INSTALL_DIR)/\ |                 |
-|                 |                 | packages.       |                 |
-|                 |                 | Result is in    |                 |
-|                 |                 | ti/binary.      |                 |
-|                 |                 |                 |                 |
-+-----------------+-----------------+-----------------+-----------------+
-
-.. _MODIFIED: http://processors.wiki.ti.com/index.php/PCIe_CableMod
-
-.. rubric:: Quick setup of xds100 for two EVMs
-   :name: quick-setup-of-xds100-for-two-evms
-
-#. create new target configuration using XDS100v2 and AM572x (or AM571x)
-   from the basic tab.
-#. Select Advanced tab.
-#. Highlight the XDS100v2, and click the "new" button and add second
-   XDS100v2.
-#. Highlight the newly added XDS100v2, click the "add" button and select
-   a second Am572x.
-#. open command prompt, and run ti\ccs_base\common\uscif\xds100serial to
-   get your serial numbers
-#. Highlight first XDS100v2, select "Debug Probe Selection" to "Select
-   by Serial number" and enter one of the 2 serial numbers
-#. Repeat second XDS100v2, setting to to the second serial number.
-
-General instructions for configuring multiple EVMs with any emulator
-type are available in
-`Debugging with Multiple Debug Probes <http://software-dl.ti.com/ccs/esd/documents/sdto_ccs_multi-probe-debug.html>`__
-
-.. rubric:: Detailed instructions to run example
-   :name: detailed-instructions-to-run-example
-
-Ensure 2 Like EVMs are connected with a x1 PCIe male/male cross cable
-(for AM5XX) or a breakout card (for C667x, C665x, K2x)
-
-Build project(s) appropriate for your EVM. Projects for A15 and C66 are
-provided based on core types available on each device.
-
-Load via jtag either the ARM or DSP projects (but don't mix and match)
-onto the first arm or dsp core of each the 2 EVMs. Same .out file
-supports both RC and EP. Use an "expressions" window to set PcieModeGbl
-to PCIE_RC_MODE on one EVM (it makes that EVM RC). Leave the second EVM
-alone (pcie_EP_MODE). Run the loaded cores. See table above to determine
-whether output is expected on serial console or CCS console.
-
-.. rubric:: Sample example output
-   :name: sample-example-output
-
-Note that output will vary slightly based on device type. The following
-is from A57XX. The output from the RC and EP are interleaved since this
-is run from a 2*XDS1000 double config as described in `Quick setup of
-xds100 for two EVMs <#quick-setup-of-xds100-for-two-evms>`__
-
-::
-
-    **********************************************
-    *             PCIe Test Start                *
-    *                RC mode                     *
-    **********************************************
-
-    Version #: 0x02020003; string PCIE LLD Revision: 02.02.00.03:Dec 24 2015:17:38:37
-
-    PCIe Power Up.
-    PLL configured.
-    Successfully configured Inbound Translation!
-    Successfully configured Outbound Translation!
-    Starting link training...
-    **********************************************
-    *             PCIe Test Start                *
-    *                EP mode                     *
-    **********************************************
-
-    Version #: 0x02020003; string PCIE LLD Revision: 02.02.00.03:Dec 24 2015:17:38:37
-
-    PCIe Power Up.
-    PLL configured.
-    Successfully configured Inbound Translation!
-    Successfully configured Outbound Translation!
-    Starting link training...
-    Link is up.
-    Link is up.
-    End Point received data.
-    End Point sent data to Root Complex, completing the loopback.
-    EP sending interrupts to RC
-    Root Complex received data.
-    RC waiting for 10 of each of 2 types of interrupts
-    RC got all 20 interrupts
-    Test passed.
-    End of Test.
-
-|
-
-Debug FAQ
----------
-
-**If example fails to get link up**
-
-   #. Confirm that male/male cross cable or breakout board is correctly
-      connected.
-   #. If running from ARM cores, confirm that immediately after
-      reset/reload that both devices have PcieModeGbl=PCIE_EP_MODE. If
-      the PCIE_RC_MODE seems to survive reset/reload, it seems to mean
-      watch window failed to refresh. Click the "Refresh" button for the
-      watch window and it should flip back to EP, where you can reset it
-      to RC. Simply running will cause both sides to run as EP, which
-      leads to test failure.
-   #. Confirm that one side of the example has PcieModeGbl=PCIE_RC_MODE
-      and the other is PCIE_EP_MODE.
-
-      .. note:: When changing to RC you must click somewhere outside
-         the expression value to make the modification for RC to "take
-         effect". Simply pressing F8 after modifying the value will run
-         without actually modifying the variable! The modification will
-         be done when the ARM or DSP is stopped, **so everything looks
-         right, except that the log will show "PCIe test start EP mode"
-         twice** instead of "PCIe test start EP mode" once and "PCIe
-         test start RC mode" once.
-
-**How to debug common PCIe issues**
-
-Please refer to `PCI Express (PCIe)
-FAQ <http://www.ti.com/lit/an/sprac59a/sprac59a.pdf>`__ for Keystone devices.
-
-
-Additional References
----------------------
-
-Additional documentation can be found in:
-
-+-----------------------------------+---------------------------------------------+
-| **Document**                      | **Location**                                |
-+-----------------------------------+---------------------------------------------+
-| Hardware Peripheral Users Guide   | -  C66x/K2x: `User                          |
-|                                   |    Guide <http://www.ti.com/lit/sprugs6>`__ |
-|                                   |                                             |
-|                                   | -  AM57XX: TRM Chapter 24.9                 |
-|                                   |    titled "PCIe Controller"                 |
-|                                   |                                             |
-|                                   | -  AM65XX: TRM Chapter 12.2.2               |
-|                                   |    titled "Peripheral Component Controller  |
-|                                   |    Interconnect Express (PCIe)              |
-|                                   |    Subsystem"                               |
-|                                   |                                             |
-+-----------------------------------+---------------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)/packages/ti           |
-|                                   | /drv/pcie/docs/doxygen/html/index           |
-|                                   | .html                                       |
-+-----------------------------------+---------------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)/packages/ti           |
-|                                   | /drv/pcie/docs/ReleaseNotes_PCIE_LLD.pdf    |
-+-----------------------------------+---------------------------------------------+
-
-|
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_PKTLIB.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_PKTLIB.rst
deleted file mode 100644
index 7f2727b20..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_PKTLIB.rst
+++ /dev/null
@@ -1,78 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_PKTLIB
-
-.. rubric:: Introduction
-   :name: introduction
-
-The packet library (PKTLIB) provides higher layer of abstraction for
-underlying CPPI hardware descriptors to application layer.
-Functionalities include:
-
--  Zero copy operation for:
-
-   -  Packet split/merge operations
-   -  Cloning operations
-   -  Headroom/Tail room addition through merge operation
-
--  Allocations of packet buffer and descriptors during startup time
--  Allows packet allocation by HW at Rx CPPI DMA
--  Efficient recycling of data buffers including the case of buffers
-   being referenced by multiple CPPI descriptors
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-A pktlib heap can be created in on of the following two modes:
-
--  Private: only visible on the core where the heap was created
--  Shared: visible across multiple cores
-
-.. rubric:: Driver Configuration
-   :name: driver-configuration-pktlib
-
-Applications can use Pktlib_createHeap() API to create heap(s) in the
-system and heap properties are specified by the Pktlib_HeapCfg
-configuration structure. This configuration structure should be
-populated by the application and passed to the PKTLIB module when a heap
-is being created via the Pktlib_createHeap() API. Multiple heaps can
-exist in the system where each heaps properties are specified by the
-Pktlib_HeapCfg configuration structure.
-
-For details about individual fields of this structure, see the Doxygen
-help by opening
-<PDK_INSTALL_DIR>/packages/ti/runtime/pktlib/docs/doxygen/html/index.html.
-
-.. rubric:: **APIs**
-   :name: apis
-
-API reference for application can be found in below file:
-
-::
-
-    #include <ti/runtime/pktlib/pktlib.h>
-
-.. rubric:: Example
-   :name: example
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results      |
-+=======================+=======================+=======================+
-| pktlibUnitTest        | | Unit Test           | | User observes the   |
-| Application           |   application to test |   output printed over |
-|                       |   all APIs            |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-
-.. rubric:: Additional References
-   :name: additional-references
-
-+-----------------------------------+-----------------------------------+
-| **Document**                      | **Location**                      |
-+-----------------------------------+-----------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)/packages/ti |
-|                                   | /runtime/pktlib/docs/doxygen/html |
-|                                   | /index.html                       |
-+-----------------------------------+-----------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)/packages/ti |
-|                                   | /runtime/pktlib/docs/ReleaseNotes |
-|                                   | _pktlib.pdf                       |
-+-----------------------------------+-----------------------------------+
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_PM.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_PM.rst
deleted file mode 100644
index 9cbcaf940..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_PM.rst
+++ /dev/null
@@ -1,130 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_PM
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The Power Management (PM) low level driver provide power and thermal
-management capabilities for RTOS applications.
-
-.. rubric:: **Supported Devices**
-   :name: supported-devices
-
-+------------+---------+---------+--------+--------+----------+--------+--------+------------------------------+
-| **Device** | **A53** | **A15** | **A8** | **A9** | **C66x** | **M4** | **R5F**| **Tested On**                |
-+------------+---------+---------+--------+--------+----------+--------+--------+------------------------------+
-| AM65xx     | X       |         |        |        |          |        | X      | AM65x EVM, AM65x IDK         |
-+------------+---------+---------+--------+--------+----------+--------+--------+------------------------------+
-| AM57xx     |         | X       |        |        | X        | X      |        | AM572x GP EVM, AM571x GP EVM |
-+------------+---------+---------+--------+--------+----------+--------+--------+------------------------------+
-| AM335x     |         |         | X      |        |          |        |        | AM335x GP EVM                |
-+------------+---------+---------+--------+--------+----------+--------+--------+------------------------------+
-| AM437x     |         |         |        | X      |          |        |        | AM437x GP EVM                |
-+------------+---------+---------+--------+--------+----------+--------+--------+------------------------------+
-| K2G        |         | X       |        |        | X        |        |        | K2G EVM                      |
-+------------+---------+---------+--------+--------+----------+--------+--------+------------------------------+
-
-.. note::
-
-    PM on AM335x and AM437x devices supports only OPP modifications.  CPU idle
-    and other PM modes on these devices are only for reference and are not
-    validated on the EVM every release.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-The following board-specific actions must take place prior to calling
-any PM Power APIs:
-
--  A board-specific I2C implementation must be registered with the PM
-   HAL layer
--  The PMIC Ops structure matching the executing device's PMIC must be
-   registered with PM HAL layer
--  Device clock rates must be initialized through the PM LIB layer
-
-For working examples of how to implement the listed items, see the
-"main" functions of any PM example in
-``[PDK_INSTALL_DIR]\packages\ti\drv\pm\examples``.
-
-.. rubric:: **PM Configuration Structure**
-   :name: pm-configuration-structure
-
-The pm\src\pmrtos\prcm\PowerDevice.c file configures the PM driver
-through the PowerDevice_config structure. This structure must be
-provided to PM driver. The structure is a global defined within
-PowerDevice.c and must be initialized prior to calling Power_init(). The
-structure cannot be changed after calling Power_init(). For details
-about individual fields of this structure, see the Doxygen help by
-opening
-``[PDK_INSTALL_DIR]\packages\ti\drv\pm\docs\doxygen\html\index.html``.
-
-APIs
-^^^^^
-
-The following lists the main application interfaces; see the end of this
-page for a link to the API Reference Manual with full details.
-
-PM TI RTOS base API reference for applications can be found in below
-file:
-
-::
-
-    #include <ti/drv/pm/Power.h>  /* Contains the core TI RTOS Power implementation APIs */
-
-PM TI RTOS extended API reference for applications can be found in the
-below file:
-
-::
-
-    #include <ti/drv/pm/PowerExtended.h>  /* Contains TI RTOS Power API extensions such as thermal management */
-
-PM TI RTOS device-specific API reference for applications can be found
-in the below file:
-
-::
-
-    #include <ti/drv/pm/PowerDevice.h>  /* Contains device-specific TI RTOS Power API definitions and structures */
-
-|
-
-Application
-------------
-
-Examples
-^^^^^^^
-
-.. csv-table::
-   :header: "Name", "Description", "Expected Results"
-   :widths: 20, 30, 70
-
-    "PM RTOS Application","Example demonstarting power management use cases. Reference example for developers","Application cycles the processor running the application through various power states using the PM APIs. User observes the output printed over the device's UART connection. **Note:** The example should be run in *Free Run* mode when loaded and executed in Code Composer Studio in order to prevent sleep API testing interruptions from the JTAG.  Use the following  steps to execute the application on the    AM57xx's M4 and C66 processors in Code Composer Studio:  -  Connect to CortexA15_0 waiting until the GEL file initialization completes -  Run the GEL: Scripts-->AM572x MULTICORE  Initialization-->AM572x_MULTICORE_EnableAllCores -  Connect to M4_IPU1_C0 or the C66xx_DSP1  -  Load the PM RTOS application's M4 or c66 executable -  Free run the M4_IPU1_C0 or the C66xx_DSP1"
-    "PM RTOS Thermal Application","Example demonstrating thermal management use case. Reference example for developers","Application sets high and low thermal set points using the PM APIs.The set points are triggered by     internally heating up the processor.User observes the output printed over the device's UART connection. Use the following steps to execute the application on the AM57xx's M4 and C66 processors in Code Composer Studio:   -  Connect to CortexA15_0 waiting until the GEL file initialization completes -  Run the GEL:Scripts-->AM572x MULTICORE Initialization-->AM572x_MULTICORE_EnableAllCores -  Connect to M4_IPU1_C0 or the C66xx_DSP1 -     Load the PM RTOS Thermal application's M4 or c66 executable -  Run the M4_IPU1_C0 or the C66xx_DSP1"
-    "PM Measurement Application ", "Menu-based application allowing selection of processor OPPs and benchmark tests.", "Application allows the user to control the processor's OPP settings via the PM driver. The application  also allows the user to select execution of the Dhrystone benchmark for performance and power profiling under different OPP settings. The application's menu is printed over the device's UART connection. **Note:** The     measurement application is only supported on the AM335x device at the moment."
-    "PM System Configuration Test","Example demonstrating system configuration use-case", "This example is available at '<install_path>/packages /ti/drv/pm/examples/systemconfig'. The PM System Configuration test is an  example running on tda2xx A15 core, tda2xx M4 core,tda3xx IPU (M4) core and AM65xx(A53 and R5). This example demonstrates the ability to configure the desired power state for a given module based on the entries in the   power spread sheet.The example loops through the different modules and power states and tries to program the same for each module using PM LIB sysconfig APIs before declaring pass or fail.The example illustrates the   use of Power Management LIB which allows system configuration."
-    "PM CLock Rate Configuration Test ","Example demonstrating clockrate configuration use-case","This example is available at '<install_path>/packages/ti/drv/pm/ examples/clkrate_manager' The Clock Rate Configuration test is an example running on A15 core and IPU (M4) Core for tda2xx/tda2ex/tda2px ,IPU (M4) core for tda3xx ,A53(MPU) and R5(MCU) for AM65xx. This example demonstrates the ability to read the clock rate for different clocks for a given CPU (MPU/IPU/DSP/GPU/IVA/EVE). The example first reads the current clock configuration and then checks for OPP_NOM, OPP_OD and OPP_HIGH frequencies along with voltage changes by using the PMLIB clock rate APIs before declaring pass or fail. The example illustrates the use of Power Management LIB which allows changing the CPU OPP. For AM65xx, this example first loops through all modules and gets the clockrate for all of their clocks.Then, it tries to set the frequencies for some clocks of different modules. "
-
-
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\pm\\docs\\doxygen\\html\\index.h |
-|                                   | tml                                     |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\pm\\docs\\ReleaseNotes_PM_LLD.   |
-|                                   | pdf                                     |
-+-----------------------------------+-----------------------------------------+
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_PRUSS.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_PRUSS.rst
deleted file mode 100644
index 99d159cfa..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_PRUSS.rst
+++ /dev/null
@@ -1,147 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_PRUSS
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-| The PRUSS (Programmable Real-Time Unit Subsystem) provides a
-  well-defined API layer which allows applications to use the PRUSS low
-  level driver to control  sub system.
-
-|
-
-.. rubric:: Firmware
-   :name: firmware
-
-The PRUSS (Programmable Real-Time Unit Subsystem) is firmware
-programmable and can take on various personalities. Examples include an
-ethernet MAC, ethernet Switch, Industrial protocol switch. For a good
-example, please refer to `Simple Open Real Time Ethernet Protocol (SORTE)
-<index_pru_icss_fw.html#pru-icss-sorte>`__
-
-.. rubric:: Driver Features
-   :name: driver-features
-
--  PRU control features i.e enable/disable/reset a PRU
--  Helper functions i.e. load and execute firmware in PRU
--  Memory mapping of PRU/L3/External memories
--  PRU and Host event management (i.e. map sys_evt/channel/hosts in PRU
-   INTC generate interrupts, wait for occurrence of an event, and
-   acknowledge interrupts
--  Interrupt management for A15/C66x CPU targets
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All the board specific configurations like enabling the clock and
-pin-mux of UART/GPIO/PRUSS ICSS pins should be performed before
-calling any of the driver APIs.
-
-|
-.. rubric::  **PRUSS Configuration Structure**
-   :name: pruss-configuration-structure
-
-The pruicss_device.c file contains the declaration of the PRUICSS
-config structure. This structure must be provided to the driver at the
-time when PRUICSS_create() API is called to creat the PRUICSS_Handle.
-This handle is subsequently required to make any PRUSS LLD API call.
-
-APIs
-^^^^^
-
-Reference API header file:
-
-::
-
-    #include <ti/drv/pruss/pruicss.h>
-
-.. rubric:: API Call Flow
-   :name: api-call-flow
-
-Below sequence indicates calling sequence of PRUSS driver APIs for a use
-case of sending INTC event to the PRU. Refer example code within module
-for additional details
-
-::
-
-     ...
-     /* Initialize Board */
-     Board_init(boardCfg);
-
-     /* Creates handle for PRUICSS instance */
-     handle = PRUICSS_create(pruss_config,instance);
-
-     /* Disable PRUICSS instance */
-     PRUICSS_pruDisable(handle,instance );
-
-     /* Register an Interrupt Handler for an event */
-     PRUICSS_registerIrqHandler(handle,pruEvtoutNum,intrNum,eventNum,waitEnable,irqHandler);
-
-     /* Sets the buffer pointer for PRU */
-     PRUICSS_setPRUBuffer(..);
-
-     /* API to do Interrupt-Channel-host mapping */
-     PRUICSS_pruIntcInit(handle,&pruss_intc_initdata);
-
-     /* Execute program on PRU */
-     PRUICSS_pruExecProgram(handle,0);
-
-      /* Enable PRU */
-     PRUICSS_pruEnable(handle,0);
-
-     /* Generates INTC event */
-     PRUICSS_pruSendEvent(handle,ARM_PRU0_EVENT);
-
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  ||  Description         ||  Expected Results    |
-+=======================+=======================+=======================+
-| PRUSS_TestApplication || Test application is  || Following prints     |
-|                       |   designed to ping    | expected on console   |
-|                       |   pong an event       | based on pass/fail    |
-|                       |   between CPU         | criteria:             |
-|                       |   target(A15/C66x)    ||                      |
-|                       |   and PRU for a fixed || **Pass criteria:**   |
-|                       |   count.Application   |                       |
-|                       |   is to test PRU’s    || Prints related to    |
-|                       |   load, control and   | sending and           |
-|                       |   Interrupt           | receiving  event from |
-|                       |   controller          | PRU will be printed   |
-|                       |   functionalities.    | on  console. Test     |
-|                       |                       | program at the end    |
-|                       |                       | expected to output:   |
-|                       |                       | "All tests have       |
-|                       |                       | passed"               |
-+-----------------------+-----------------------+-----------------------+
-
-Additional References
----------------------
-
-+-----------------------------------+----------------------------------------+
-|   **Document**                    | **Location**                           |
-+-----------------------------------+----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\pruss\\docs\\doxygen\\html\\inde|
-|                                   | x.html                                 |
-+-----------------------------------+----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\pruss\\docs\\ReleaseNotes_PRUS  |
-|                                   | S_LLD.pdf                              |
-+-----------------------------------+----------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_QMSS.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_QMSS.rst
deleted file mode 100644
index bfaeded75..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_QMSS.rst
+++ /dev/null
@@ -1,415 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_QMSS
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The Queue Manager Sub System (QMSS) low level driver provides the
-interface to Queue Manager Subsystem hardware which is part of the
-Multicore Navigator functional unit for a keystone device. QMSS provides
-hardware assisted queue system and implements fundamental operations
-such as en-queue and de-queue, descriptor management, accumulator
-functionality and configuration of infrastructure DMA mode. The LLD
-provides APIs to get full entitlement of supported hardware
-functionality.
-
-The LLD also includes accumulation and QoS (Quality of Service)
-firmware. QoS enables restriction of data rates in bytes per second or
-packets per second, weighted round robin queue selection, and selective
-descriptor dropping for oversubscribed queues. Accumulation The APIs are
-provided through the LLD. The API documentation for both QoS and
-Accumulator is available in the API Reference manual below. The
-capabilities of the QoS firmware are documented in their design
-documents. The capabilities of the accumulator are documented in the
-Hardware Peripheral User Guide.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-QMSS library (ti.drv.qm) supports below modes
-
-**Joint Mode**: In this mode, only linkingRAM0Base, linkingRAM0Size, and
-linkingRAM1Base are used to configure all QM groups simultaneously. For
-all existing devices (K2H, K2K) this is only mode that should be used.
-For the rest of the devices such as K2L, K2E, 6678 and 6657, this is the
-only mode available.
-
-**Split Mode**: This mode shouldn't be used as it doesn't support all
-peripherals on the device.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The driver configures the QMSSSS subsystem using
-Qmss_GlobalConfigGroupRegs(system configuration) structure. The default
-global configuration per device is present under qmss_device.c file
-provided per device.
-
-For details about individual fields of this structure, see the Doxygen
-help by opening
-PDK_INSTALL_DIR\QMSSckages\ti\drv\QMSS\docs\doxygen\html\index.html.
-
-APIs
-^^^^^
-
-API header for application:
-
-::
-
-    #include <ti/drv/QMSS/QMSS_drv.h>
-
-Please see the doxygen in "API Reference Manual" below for details.
-
-|
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  || Description          | Expected Results      |
-+=======================+=======================+=======================+
-| QMSS_Example          | | Example             | | User observes the   |
-| application           |   demonstrating       |   output printed over |
-|                       |   *infra DMA,         |   the CCS console     |
-|                       |   interrupt test* use |                       |
-|                       |   case. Reference     |                       |
-|                       |   example for         |                       |
-|                       |   developers          |                       |
-+-----------------------+-----------------------+-----------------------+
-| QMSS_UnitTestApplicat | | Unit Test           | | User observes the   |
-| ion                   |   application to test |   output printed over |
-|                       |   all APIs            |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-
-.. rubric:: Sample Example Output
-   :name: sample-example-output
-
-This came from K2K multicore example:
-
-::
-
-    **************************************************
-    ************ QMSS Multicore Example **************
-    **************************************************
-    **************************************************
-    ************ QMSS Multicore Example **************
-    **************************************************
-    **************************************************
-    **************************************************
-    ************ QMSS Multicore Example **************
-    ************ QMSS Multicore Example **************
-    **************************************************
-    **************************************************
-    Core 1 : Starting BIOS...
-    Core 2 : Starting BIOS...
-    Core 3 : Starting BIOS...
-    Core 0 : Starting BIOS...
-    Core 0 : Created RM packet heap
-    Core 0 : Created IPC MessageQ heap
-    Core 0 : Created receive Q for Client1
-    Core 1 : Opened RM packet heap
-    Core 2 : Opened RM packet heap
-    Core 3 : Opened RM packet heap
-    Core 1 : Opened IPC MessageQ heap
-    Core 2 : Opened IPC MessageQ heap
-    Core 3 : Opened IPC MessageQ heap
-    Core 1 : Created receive Q for Server
-    Core 2 : Created receive Q for Server
-    Core 3 : Created receive Q for Server
-    Core 1 : Opened Server's receive Q
-    Core 1 : Waiting for QMSS to be initialized...
-
-    Core 0 : Opened Client1's receive Q for Server
-    Core 0 : Created receive Q for Client2
-    Core 0 : Opened Client2's receive Q for Server
-    Core 0 : Created receive Q for Client3
-    Core 2 : Opened Server's receive Q
-    Core 2 : Waiting for QMSS to be initialized...
-
-    Core 0 : Opened Client3's receive Q for Server
-
-    -----------------------Initializing---------------------------
-    Core 0 : L1D cache size 4. L2 cache size 0.
-    Core 0 : Memory region 0 inserted
-    Core 0 : Memory region 1 inserted
-    Core 0 : Tx Completion Queue Number     : 897 opened
-    Core 0 : Number of Tx descriptors requested : 32. Number of descriptors allocated : 32
-    Core 0 : Number of Rx descriptors requested : 32. Number of descriptors allocated : 32
-    Core 0 : Number of Sync free descriptors requested : 32. Number of descriptors allocated : 32
-    Core 0 : Sync Queue Number              : 9025 opened
-    Core 0 : Sync Cfg Queue Number          : 9026 opened
-    Core 0 : Sync Free Queue Number         : 898 opened
-    Core 0 : Receive Free Queue Number      : 736 opened
-    Core 0 : Transmit Free Queue Number     : 8928 opened
-    Core 0 : System initialization completed: 8928
-    Core 0 : Publishing RM nameserver names for shared queues
-
-    --------------------Queue status CORE 0----------------------
-                        After Initialization
-
-    Tx Free Queue 8928 Entry Count            : 32
-    Rx Free Queue 736 Entry Count            : 32
-    Tx completion Queue 897 Entry Count     : 0
-    Sync Queue 9025 Entry Count              : 0
-    Sync free Queue 898 Entry Count         : 32
-    Sync Cfg Queue 9026 Entry Count          : 0
-    -------------------------------------------------------------
-
-    Core 0 : Registering High Priority interrupt channel : 0 eventId : 48 queue Number : 704
-
-
-    Core 3 : Opened Server's receive Q
-    Core 1 : QMSS initialization done.
-    Core 2 : QMSS initialization done.
-    Core 3 : Waiting for QMSS to be initialized...
-
-
-
-
-    Core 3 : QMSS initialization done.
-
-    Core 1 : Rx Free Queue Number       : 736 opened
-    Core 2 : Rx Free Queue Number       : 736 opened
-    Core 3 : Rx Free Queue Number       : 736 opened
-    Core 1 : Tx Free Queue Number       : 8928 opened
-    Core 2 : Tx Free Queue Number       : 8928 opened
-    Core 3 : Tx Free Queue Number       : 8928 opened
-    Core 1 : Tx Completion Queue Number : 897 opened
-    Core 2 : Tx Completion Queue Number : 897 opened
-    Core 3 : Tx Completion Queue Number : 897 opened
-    Core 1 : Sync Queue Number          : 9025 opened
-    Core 2 : Sync Queue Number          : 9025 opened
-    Core 3 : Sync Queue Number          : 9025 opened
-    Core 1 : Sync Free Queue Number     : 898 opened
-    Core 2 : Sync Free Queue Number     : 898 opened
-    Core 3 : Sync Free Queue Number     : 898 opened
-    Core 1 : Sync Cfg Queue Number      : 9026 opened
-    Core 2 : Sync Cfg Queue Number      : 9026 opened
-    Core 3 : Sync Cfg Queue Number      : 9026 opened
-    Core 1 : Registering High Priority interrupt channel : 1 eventId : 48 queue Number : 705
-    Core 2 : Registering High Priority interrupt channel : 2 eventId : 48 queue Number : 706
-    Core 3 : Registering High Priority interrupt channel : 3 eventId : 48 queue Number : 707
-    Core 1 : Waiting for sync signal
-    Core 2 : Waiting for sync signal
-    Core 3 : Waiting for sync signal
-    Core 0 : Opened Tx channel      : 0
-    Core 0 : Opened Rx channel      : 0
-    Core 0 : Transmit Queue Number  : 800
-    Core 0 : Receive Queue Number   : 704
-    Core 0 : Opened Rx flow         : 0
-    Core 0 : High priority accumulator programmed for channel : 0 queue : 704
-
-    Core 0 : Transmitting 8 packets..........
-
-    *************************************************************
-    Core 0 : Opened Tx channel      : 0
-    Core 0 : Opened Rx channel      : 0
-    Core 0 : Transmit Queue Number  : 800
-    Core 0 : Receive Queue Number   : 705
-    Core 0 : Opened Rx flow         : 0
-    Core 0 : High priority accumulator programmed for channel : 1 queue : 705
-
-    Core 0 : Transmitting 8 packets..........
-
-    *************************************************************
-    Core 0 : Opened Tx channel      : 0
-    Core 0 : Opened Rx channel      : 0
-    Core 0 : Transmit Queue Number  : 800
-    Core 0 : Receive Queue Number   : 706
-    Core 0 : Opened Rx flow         : 0
-    Core 0 : High priority accumulator programmed for channel : 2 queue : 706
-
-    Core 0 : Transmitting 8 packets..........
-
-    *************************************************************
-    Core 0 : Opened Tx channel      : 0
-    Core 0 : Opened Rx channel      : 0
-    Core 0 : Transmit Queue Number  : 800
-    Core 0 : Receive Queue Number   : 707
-    Core 0 : Opened Rx flow         : 0
-    Core 0 : High priority accumulator programmed for channel : 3 queue : 707
-
-    Core 0 : Transmitting 8 packets..........
-
-    *************************************************************
-    Core 0 : Waiting for sync signal
-    Core 0 : Got sync signal
-    *************************************************************
-
-
-    --------------------Queue status CORE 0----------------------
-                        After packet processing
-
-    Tx Free Queue 8928 Entry Count            : 0
-    Rx Free Queue 736 Entry Count            : 32
-    Tx completion Queue 897 Entry Count     : 32
-    Sync Queue 9025 Entry Count              : 4
-    Sync free Queue 898 Entry Count         : 27
-    Sync Cfg Queue 9026 Entry Count          : 1
-    -------------------------------------------------------------
-
-    Core 0 : Waiting for other cores to ack sync signal
-    Core 1 : Got sync signal
-    Core 2 : Got sync signal
-    Core 3 : Got sync signal
-    *************************************************************
-    *************************************************************
-    *************************************************************
-
-
-
-    Core 0 : acks found
-
-    --------------------Deinitializing---------------------------
-
-    --------------------Queue status CORE 0----------------------
-                        Before exit
-
-    Tx Free Queue 8928 Entry Count            : 0
-    Rx Free Queue 736 Entry Count            : 32
-    Tx completion Queue 897 Entry Count     : 32
-    Sync Queue 9025 Entry Count              : 0
-    Sync free Queue 898 Entry Count         : 28
-    Sync Cfg Queue 9026 Entry Count          : 4
-    -------------------------------------------------------------
-
-    Core 0 : Receive free queue closed successfully. Ref count : 0
-    Core 0 : Transmit completion queue closed successfully. Ref count : 3
-    Core 0 : Transmit free queue closed successfully. Ref count : 3
-    Core 0 : Sync queue closed successfully. Ref count : 3
-    Core 0 : Sync free queue closed successfully. Ref count : 3
-    Core 0 : Sync queue closed successfully. Ref count : 3
-    Core 0 : CPPI CPDMA closed successfully
-    Core 0 : CPPI exit successful
-    Core 0: Cleaning regions
-    Core 0: exit QMSS
-    Core 1 : Receive free queue closed successfully. Ref count : 3
-    Core 2 : Receive free queue closed successfully. Ref count : 2
-    Core 3 : Receive free queue closed successfully. Ref count : 1
-    Core 1 : Transmit completion queue closed successfully. Ref count : 2
-    Core 2 : Transmit completion queue closed successfully. Ref count : 1
-    Core 3 : Transmit completion queue closed successfully. Ref count : 0
-    Core 1 : Transmit free queue closed successfully. Ref count : 2
-    Core 2 : Transmit free queue closed successfully. Ref count : 1
-    Core 3 : Transmit free queue closed successfully. Ref count : 0
-    Core 1 : Sync queue closed successfully. Ref count : 2
-    Core 2 : Sync queue closed successfully. Ref count : 1
-    Core 3 : Sync queue closed successfully. Ref count : 0
-    Core 1 : Sync free queue closed successfully. Ref count : 2
-    Core 2 : Sync free queue closed successfully. Ref count : 1
-    Core 3 : Sync free queue closed successfully. Ref count : 0
-    Core 1 : Sync queue closed successfully. Ref count : 2
-    Core 2 : Sync queue closed successfully. Ref count : 1
-    Core 3 : Sync queue closed successfully. Ref count : 0
-    *******************************************************
-    *******************************************************
-    *******************************************************
-    ******** QMSS Multicore (1) Example Done (PASS) *******
-    ******** QMSS Multicore (2) Example Done (PASS) *******
-    ******** QMSS Multicore (3) Example Done (PASS) *******
-    *******************************************************
-    *******************************************************
-    *******************************************************
-    Core 0 : Deleting RM nameserver names for shared queues
-    Instance name: RM_Server
-    Handle: 0x00854578
-    Type:   Server
-
-    Resource Status:
-
-    Core 0 : All resources freed successfully
-    *******************************************************
-    ******** QMSS Multicore (0) Example Done (PASS) *******
-    *******************************************************
-
-Debug FAQ
-----------
-
-#. Double Push - Some queue elements lost.
-
-   #. Pushing the same pointer twice is illegal. In hardware it does
-      something similar to double linking the same object into two
-      places of a software linked list. It corrupts the list, such that
-      some items will be orphaned/lost.
-
-#. NULL Push - Entire queue lost
-
-   #. Pushing NULL (0) clears the entire queue. This is intentionally
-      done by Qmss_QueueEmpty(). However the various Qmss_QueuePush
-      functions don't check for NULL (to save cycles). Don't push NULL
-      (for example received when Qmss_QueuePop finds an empty queue).
-
-#. Hint Bits (4 low LSBs of desc pointer)
-
-   #. These are used to tell DMAs such as CPPI the size of the
-      descriptor. Thus, when receiving descriptors from hardware, you
-      must use QMSS_DESC_PTR() to discard them, else unaligned memory
-      accesses that corrupt descriptors will be generated by software.
-
-#. General lost descriptors
-
-   #. Its not a bad idea to have code that can inventory all your
-      descriptors as part of destructive debug. Iterate over all queues,
-      and pop all descriptors. Set a bit in a large bitmap for each
-      descriptor found. Bits that remain 0 indicate "lost" descriptors
-      which could have happened due to double push or null push or
-      software bugs that simply lost them. By examining the contents of
-      descriptor(s) and buffer(s), can often determine who last used
-      them therefore what part of code lost them.
-   #. Its also good to have nondestructive debug code that can call
-      Qmss_getQueueByteCount() and Qmss_getQueueEntryCount() for each
-      queue. This should be able to find all but a few (~4) descriptors
-      per hardware DMA that are in flight. If large amounts of
-      descriptors are missing, it means there is a bug. For this
-      debug/monitor purpose, its OK to make own Qmss_QueueHandle by
-      casting the queue number (eg (Qmss_QueueHandle)queueNum) since its
-      undesirable to generate accounting/management for purpose of
-      nondestructive debug.
-
-Additional References
----------------------
-
-.. list-table::
-   :header-rows: 1
-
-   * - **Document**
-
-     - **Location**
-
-   * - API Reference Manual
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/QMSS/docs/doxygen/html/index.html``
-
-   * - Release Notes
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/QMSS/docs/ReleaseNotes_QMSS_LLD.pdf``
-
-   * - QoS (Weighted Round Robin and SP QoS tree)
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/QMSS/docs/firmware/qos_sched,qos_sched_drop_sched,qos_sched_wide.pdf``
-
-   * - QoS (Leaky bucket and SRIO TX Scheduler)
-
-     - ``$(TI_PDK_INSTALL_DIR)/packages/ti/drv/QMSS/docs/firmware/qos.pdf``
-
-   * - Hardware Userguide/TRM
-
-     - `UG TRM PDF <http://www.ti.com/lit/sprugr9>`__
-
-   * - CPPI LLD (Navigator/QMSS DMA component)
-
-     - `CPPI LLD`_
-
-.. _CPPI LLD: index_device_drv.html#cppi
-
-|
-
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_QSPI_McSPI.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_QSPI_McSPI.rst
deleted file mode 100644
index a9e8d2ed8..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_QSPI_McSPI.rst
+++ /dev/null
@@ -1,537 +0,0 @@
-Introduction
-------------
-
-SPI driver enables communication for general SPI, MCSPI (Multichannel
-SPI), QSPI (Quad SPI) and OSPI (Octal SPI) based peripherals on board
-through common API to application.
-MCSPI is a generic full-duplex interface supporting transmit and
-receive of data over SPI bus. QSPI/OSPI is a variant of SPI supports four
-receive data lanes. Driver supports configuration for either single,
-dual, quad or octal data lines
-
-Modes of Operation
-------------------
-
-Following modes of operations are supported:
-
-**SPI_MODE_BLOCKING**
-*SPI_transfer()* API blocks code execution until transaction has
-completed. By default, SPI driver operates in blocking mode. This
-ensures only one SPI transaction operates at a given time. This mode
-is supported in both interrupt or non-interrupt configurations.
-
-**SPI_MODE_CALLBACK**
-*SPI_transfer()* API returns without waiting for completion of
-transaction in this case. Callback function registered by application
-is invoked once transaction is complete.This mode is supported only in
-interrupt configuration.
-
-Driver Configuration
---------------------
-
-Board Specific Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All board specific configurations eg:enabling clock and pin-mux for SPI
-pins are required before calling any driver APIs.By default Board_Init()
-API supports all initialization sequence for TI supported EVMs. In
-addition it initializes UART instance for Console/STDIO.Refer `Processor
-SDK RTOS Board Support <index_board.html#board-support>`__
-for additional details.Once board specific configuration is
-complete \ *SPI_init()* API should be called to initialize driver.
-
-SoC Specific Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All SoC specific configurations (eg: SPI module registers base address,
-interrupt configurations, etc.) can be set using SPI_socSetInitCfg() SoC
-driver API before calling any SPI driver APIs. The default SoC specific
-configurations can be retrieved using SPI_socGetInitCfg() SoC driver
-API. 
-
-SPI Configuration Structure
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The *SPI_soc.c* file binds driver with hardware attributes on the board
-through *SPI_config[]* structure. This structure must be provided to the
-SPI driver. It must be initialized before the *SPI_init()* function is
-called and cannot be changed afterwards. For details about individual
-fields of this structure, see Doxygen help by opening
-*PDK_INSTALL_DIR\packages\ti\drv\spi\docs\doxygen\html\index.html.*
-
-Driver  requires common *SPI_config[]*  to configure hardware attributes
-of MCSPI and QSPI/OSPI peripherals on SOC and board. First all MCSPI related
-hardware attributes is defined followed by QSPI/OSPI hardware attributes.
-Application will need to include appropriate offset to instance while
-invoking *SPI_open()* API..
-
-APIs
-----
-
-API Reference for application:
-
-::
-
-    #include <ti/drv/spi/SPI.h>
-
-SPI IP V1 driver also supports multi-channel API's:
-
-::
-
-    #include <ti/drv/spi/MCSPI.h>
-
-Open SPI
-^^^^^^^^
-
-::
-
-    ...
-    Board_init(boardCfg);
-    ...
-    SPI_socGetInitCfg(peripheralNum, &spi_cfg);
-    ...
-    SPI_socSetInitCfg(peripheralNum, &spi_cfg);
-    SPI_Params_init(&spiParams);
-    spiParams.transferMode = SPI_MODE_BLOCKING;
-    spiParams.transferCallbackFxn = NULL;
-    handle = SPI_open(peripheralNum, &spiParams);
-
-SPI IP V1 driver also supports multi-channel open API's:
-
-::
-
-    ...
-    Board_init(boardCfg);
-    ...
-    MCSPI_Params_init(&spiParams);
-    spiParams.transferMode = SPI_MODE_BLOCKING;
-    spiParams.transferCallbackFxn = NULL;
-    handle = MCSPI_open(peripheralNum, channel, &spiParams);
-
-|
-At this point SPI driver is ready for data transfer in blocking mode
-on specific instance identified by handle. Pseudo/Sample code for
-SPI read/write transaction is included below. Refer example for
-additional details
-
-::
-
-    ...
-    spiTransaction.count = n;    /* Transfer Length */
-    spiTransaction. txBuf = transmitBuffer; /* Buffer to be written */
-    spiTransaction.rxBuf = NULL;  /* Buffer holding the received data */
-    transferOK = SPI_transfer(spi, &spiTransaction); /* Perform SPI transfer */
-    if (!transferOK) {
-    /* SPI transaction failed */
-    }
-
-SPI IP V1 driver also supports multi-channel transfer API's:
-
-::
-
-    ...
-    spiTransaction.count = n;    /* Transfer Length */
-    spiTransaction. txBuf = transmitBuffer; /* Buffer to be written */
-    spiTransaction.rxBuf = NULL;  /* Buffer holding the received data */
-    transferOK = MCSPI_transfer(spi, &spiTransaction); /* Perform SPI transfer */
-    if (!transferOK) {
-    /* SPI transaction failed */
-    }
-
-.. note::
-
-  SPI_open API supports configuration of data word length in the
-  SPI_Params. Currently IP V1 driver (for AM3/4/5 devices) supports
-  8/16/32-bit word length, IP V0 driver (for Keystone devices) supports
-  8/16-bit word length.
-
-Examples
---------
-
-SPI
-^^^
-
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| Name                  | Description           | Expected Results      | SoC Supported       | Build Type          |
-+=======================+=======================+=======================+=====================+=====================+
-| SPI_FlashReadWrite    | Sample application    | Following prints on   |    k2g,             | CCS project         |
-|                       | demonstrating read    | console expected:     |    k2hk,            |                     |
-| Example application   | and write of data     | **Pass criteria:**    |    k2l,             |                     |
-|                       | to a NOR flash        |                       |    k2e,             |                     |
-|                       | device connected      | All tests have        |    c6657,           |                     |
-|                       | over SPI interface.   | passed.               |    c6678,           |                     |
-|                       | By default, write     |                       |    omapl137,        |                     |
-|                       | test is disabled,     |                       |                     |                     |
-|                       | user can enable       |                       |                     |                     |
-|                       | write test by         |                       |                     |                     |
-|                       | defining              |                       |                     |                     |
-|                       | TEST_SPI_NOR_WRITE    |                       |                     |                     |
-|                       | in                    |                       |                     |                     |
-|                       | test/src/SPI_board.h  |                       |                     |                     |
-|                       |                       |                       |                     |                     |
-|                       | If write test is      |                       |                     |                     |
-|                       | enabled, write        |                       |                     |                     |
-|                       | transaction is        |                       |                     |                     |
-|                       | verified              |                       |                     |                     |
-|                       | for correctness by    |                       |                     |                     |
-|                       | reading contents      |                       |                     |                     |
-|                       | back.                 |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| SPI_TestApplication   |                       | Following prints on   |    am335x           | CCS project         |
-|                       | Driver unit test      | console expected:     |    AM437x,          |                     |
-|                       | application to        | **Pass criteria:**    |    AM571x,          |                     |
-|                       | validate features     | All tests have        |    AM572x,          |                     |
-|                       | and interfaces for    | passed.               |    AM574x,          |                     |
-|                       | SPI driver            |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| spiLoopback example   |                       | Following prints on   |    k2g,             | CCS project         |
-|                       | Example application   | console expected:     |    k2l,             |                     |
-|                       | to validate           | **Pass criteria:**    |    k2e,             |                     |
-|                       | features and          | All tests have        |    omapl138,        |                     |
-|                       | interfaces for SPI    | passed.               |    AM335x,          |                     |
-|                       | driver in loopback    |                       |    AM437x,          |                     |
-|                       | mode. Configures      |                       |    AM571x,          |                     |
-|                       | the SPI in loopback   |                       |    AM572x,          |                     |
-|                       | mode, transmits a     |                       |    AM574x,          |                     |
-|                       | test pattern and      |                       |                     |                     |
-|                       | receives it back      |                       |                     |                     |
-|                       | from SPI.             |                       |                     |                     |
-|                       |                       |                       |                     |                     |
-|                       |                       |                       |                     |                     |
-|                       | Note: This example    |                       |                     |                     |
-|                       | is intended to        |                       |                     |                     |
-|                       | demonstrate the SPI   |                       |                     |                     |
-|                       | LLD API usage on      |                       |                     |                     |
-|                       | the HW platforms      |                       |                     |                     |
-|                       | where SPI memory is   |                       |                     |                     |
-|                       | not available.        |                       |                     |                     |
-|                       | Currently this        |                       |                     |                     |
-|                       | example is            |                       |                     |                     |
-|                       | supported on          |                       |                     |                     |
-|                       | OMAPL138/C6748        |                       |                     |                     |
-|                       | platforms.            |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-
-|
-QSPI
-^^^^
-
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| Name                  | Description           | Expected Results      | SoC Supported       | Build Type          |
-+=======================+=======================+=======================+=====================+=====================+
-| QSPI_FlashReadWrite   | Sample application    | Following prints on   |    AM437x,          | CCS project         |
-|                       | demonstrating read    | console expected:     |    AM571x,          |                     |
-| Example application   | and write of data     | **Pass criteria:**    |    AM572x,          |                     |
-|                       | to a flash device     |                       |    AM574x,          |                     |
-|                       | connected over QSPI   | All tests have        |    k2g,             |                     |
-|                       | interface. Write      | passed.               |                     |                     |
-|                       | transaction is        |                       |                     |                     |
-|                       | verified  for         |                       |                     |                     |
-|                       | correctness by        |                       |                     |                     |
-|                       | reading contents      |                       |                     |                     |
-|                       | back.                 |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| QSPI_TestApplication  |                       | Following prints on   |    AM437x,          | CCS project         |
-|                       | Driver unit test      | console expected:     |    AM571x,          |                     |
-|                       | application to        | **Pass criteria:**    |    AM572x,          |                     |
-|                       | validate features     | All tests have        |    AM574x,          |                     |
-|                       | and interfaces for    | passed.               |    k2g,             |                     |
-|                       | QSPI driver           |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-
-|
-OSPI
-^^^^
-
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| Name                  | Description           | Expected Results      | SoC Supported       | Build Type          |
-+=======================+=======================+=======================+=====================+=====================+
-| OSPI_TestApplication  |                       | Following prints on   |    am65xx           | makefile            |
-|                       | Driver unit test      | console expected:     |    j721e            |                     |
-|                       | application to        | **Pass criteria:**    |                     |                     |
-|                       | validate features     | All tests have        |                     |                     |
-|                       | and interfaces for    | passed.               |                     |                     |
-|                       | OSPI driver           |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| OSPI_SMP_Test         |                       | Following prints on   |    am65xx           | makefile            |
-| Application           | Driver unit test      | console expected:     |    j721e            |                     |
-|                       | application to        | **Pass criteria:**    |                     |                     |
-|                       | validate features     | All tests have        |                     |                     |
-|                       | and interfaces for    | passed.               |                     |                     |
-|                       | OSPI driver in SMP    |                       |                     |                     |
-|                       | mode. (A53 core)      |                       |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-
-|
-
-MCSPI
-^^^^^
-
-+-----------------+-----------------+-------------------------------------------+---------------------+----------------+-------------------+
-| Name            | Description     | Additional EVM                            | Expected            | SoC Supported  | Build Type        |
-|                 |                 | Configuration                             | Results             |                |                   |
-+=================+=================+===========================================+=====================+================+===================+
-| MCSPI_Serialize | Sample          | **AM57x IDK EVM:**                        | |                   |    AM335x,     | CCS project       |
-| r               | Application     |                                           | | ** **             |    AM437x,     |                   |
-| Example         | demonstrating   |                                           |                     |    AM571x,     |                   |
-| application     | reading data    | Short pins 1  and 2 on header             | Following           |    AM572x,     |                   |
-|                 | generated from  | J37(Industrial I/O)                       | prints  on          |    AM574x,     |                   |
-|                 | industrial      |                                           | console             |                |                   |
-|                 | input module.   | **AM335x ICE v2:**                        | expected:           |                |                   |
-|                 | Application     | Short pins 1 and 2 on header              |                     |                |                   |
-|                 | uses GPIO pins  | J14(Industrial I/O)                       | **Pass              |                |                   |
-|                 | to assert load  |                                           | criteria:**         |                |                   |
-|                 | signal in order | **AM437x IDK EVM:**                       |                     |                |                   |
-|                 | to generate     | Short pins 1 and 2 on                     | All tests have      |                |                   |
-|                 | date from       | header J1(Industrial I/O)                 | passed.             |                |                   |
-|                 | industrial      |                                           |                     |                |                   |
-|                 | input module.   |                                           |                     |                |                   |
-+-----------------+-----------------+-------------------------------------------+---------------------+----------------+-------------------+
-| MCSPI_Dma_Seria | Sample          | **AM57x IDK EVM:**                        | |                   |    AM437x,     | CCS project       |
-| lizer           | Application     | Short pins 1 and 2 on header              | | ** **             |    AM571x,     |                   |
-| Example         | demonstrating   | J37(Industrial I/O)                       |                     |    AM572x,     |                   |
-| application     | reading data    | |                                         | Following           |    AM574x,     |                   |
-|                 | generated from  | **AM437x IDK EVM:**                       | prints  on          |                |                   |
-|                 | industrial      | Short pins 1 and 2 on header              | console             |                |                   |
-|                 | input module    | J1(Industrial I/O)                        | expected:           |                |                   |
-|                 | through EDMA.   |                                           |                     |                |                   |
-|                 | Application     |                                           | **Pass              |                |                   |
-|                 | uses GPIO pins  |                                           | criteria:**         |                |                   |
-|                 | to assert load  |                                           |                     |                |                   |
-|                 | signal in order |                                           | All tests have      |                |                   |
-|                 | to generate     |                                           | passed.             |                |                   |
-|                 | date from       |                                           |                     |                |                   |
-|                 | industrial      |                                           |                     |                |                   |
-|                 | input module.   |                                           |                     |                |                   |
-+-----------------+-----------------+-------------------------------------------+---------------------+----------------+-------------------+
-| MCSPI_SerialFla | Sample          | **AM335x GP EVM:**                        | |                   |    AM335x,     | CCS project       |
-| sh              | Application     | Set the EVM in profile 2                  | | ** **             |                |                   |
-|                 | demonstrating   | (SW8[1] = OFF,                            |                     |                |                   |
-|                 | writing and     |  SW8[2] = ON,                             | Following           |                |                   |
-|                 | reading data    |  SW8[3:4] = OFF)                          | prints  on          |                |                   |
-|                 | from the serial |                                           | console             |                |                   |
-|                 | flash through   |                                           | expected:           |                |                   |
-|                 | MCSPI EDMA      |                                           |                     |                |                   |
-|                 | interface.      |                                           | **Pass              |                |                   |
-|                 |                 |                                           | criteria:**         |                |                   |
-|                 |                 |                                           |                     |                |                   |
-|                 |                 |                                           | All tests have      |                |                   |
-|                 |                 |                                           | passed.             |                |                   |
-+-----------------+-----------------+-------------------------------------------+---------------------+----------------+-------------------+
-| MCSPI_periphera | Application     | **Pin Connections:**                      | | **On              |    AM335x,     | CCS project       |
-| lmode example   | demonstrates    |                                           |   peripheral        |    AM437x,     |                   |
-| application     | peripheral      |                                           |   EVM console:      |    AM571x,     |                   |
-|                 | reciever and    | | **IDK AM571x,**                         |   **\ SPI           |    AM572x,     |                   |
-|                 | transmit        | | **IDK AM572x or IDK AM574x:**           |    initialized      |    AM574x,     |                   |
-|                 | features of     | | EVM1(controller) ==== EVM2(peripheral)  | | Peripheral:PASS:  |    k2g,        |                   |
-|                 | McSPI.          | | J21-Pin24(CLK)---J21-Pin24(CLK)         |   Txd from          |                |                   |
-|                 | Application use | | J21-Pin26(MISO)---J21-Pin28(MISO)       |   controller SPI    +----------------+-------------------+
-|                 | case requires   | | J21-Pin28(MOSI)---J21-Pin26(MOSI)       |                     |    am65xx,     | makefile          |
-|                 | two EVMs. One   | | J21-Pin30(CS)------J21-Pin30(CS)        |                     |    j721e       |                   |
-|                 | acts as         | | J21-Pin22(DGND)--J21-Pin22(DGND)        | | **On Controller   |                |                   |
-|                 | Controller      | |                                         |   EVM console:      |                |                   |
-|                 | and Another as  | | **IDK AM437x:**                         |                     |                |                   |
-|                 | peripheral.     | | EVM1(controller) ==== EVM2(peripheral)  |   initialized       |                |                   |
-|                 | McSPI           | | J16-Pin24(CLK)-----J16-Pin24(CLK)       | | Controller: PASS: |                |                   |
-|                 | connections     | | J16-Pin26(MISO)---J16-Pin28(MISO)       |   Txd from          |                |                   |
-|                 | information and | | J16-Pin28(MOSI)---J16-Pin26(MOSI)       |   peripheral SPI    |                |                   |
-|                 | addtional       | | J16-Pin30(CS)------J16-Pin30(CS)        | | Done              |                |                   |
-|                 | details are as  | | J16-Pin22(DGND)--J16-Pin22(DGND)        |                     |                |                   |
-|                 | follows.        | |                                         |                     |                |                   |
-|                 |                 | | **ICEv2AM335x:**                        |                     |                |                   |
-|                 | **No of Boards  | | EVM1(controller) ==== EVM2(peripheral)  |                     |                |                   |
-|                 | Required**:     | | J3-Pin12(CLK)---------J3-Pin12(CLK)     |                     |                |                   |
-|                 |                 | | J3-Pin14(MIS0)-------J3-Pin16(MISO)     |                     |                |                   |
-|                 | 2               | | J3-Pin16(MOSI)-------J3-Pin14(MOSI)     |                     |                |                   |
-|                 |                 | | J3-Pin18(CS)-----------J3-Pin18(CS)     |                     |                |                   |
-|                 | **Connection    | | J3-Pin2(DGND)--------J3-Pin2(DGND)      |                     |                |                   |
-|                 | requirements:** | |                                         |                     |                |                   |
-|                 |                 | | **BBB AM335x:**                         |                     |                |                   |
-|                 | | Consider EVM1 | | EVM1(controller) ==== EVM2(peripheral)  |                     |                |                   |
-|                 |   as Controller | | P9-Pin31(CLK)-------P9-Pin31(CLK)       |                     |                |                   |
-|                 |   and EVM2 as   | | P9-Pin29(MISO)------P9-Pin30(MISO)      |                     |                |                   |
-|                 |   peripheral.   | | P9-Pin30(MOSI)------P9-Pin29(MOSI)      |                     |                |                   |
-|                 | | ControllerSPI | | P9-Pin28(CS)---------P9-Pin28(CS)       |                     |                |                   |
-|                 |   _CLK          | | P9-Pin1(DGND)-------P9-Pin1(DGND)       |                     |                |                   |
-|                 |   --PeripheralS | |                                         |                     |                |                   |
-|                 |   PI_CLK        | | **K2G EVM:**                            |                     |                |                   |
-|                 | | ControllerSPI | | EVM1(controller) ==== EVM2(peripheral)  |                     |                |                   |
-|                 |   _D0-          | | J12-Pin9(MISO)-------J12-Pin9(MISO)     |                     |                |                   |
-|                 |   --PeripheralS | | J12-Pin11(MOSI)----J12-Pin11(MOSI)      |                     |                |                   |
-|                 |   PI_D1         | | J12-Pin13(CLK)------J12-Pin13(CLK)      |                     |                |                   |
-|                 | | ControllerSPI | | J12-Pin15(CS0)------J12-Pin15(CS0)      |                     |                |                   |
-|                 |   _D1-          | | J12-Pin49(DGND)--J12-Pin49(DGND)        |                     |                |                   |
-|                 |   ---Peripheral | |                                         |                     |                |                   |
-|                 |   SPI_D0        | | **icev2AMIC110 EVM:**                   |                     |                |                   |
-|                 | | ControllerSPI | | EVM1(controller) ==== EVM2(peripheral)  |                     |                |                   |
-|                 |   _CS0          | | J5-Pin12(MISO)-------J5-Pin14(MISO)     |                     |                |                   |
-|                 |   PeripheralSPI | | J5-Pin14(MOSI)------J5-Pin12(MOSI)      |                     |                |                   |
-|                 |   _CS0          | | J4-Pin13(CLK)------J4-Pin13(CLK)        |                     |                |                   |
-|                 | | DGND--------- | | J5-Pin4(CS)---------J5-Pin4(CS)         |                     |                |                   |
-|                 |   -----------DG | | J5-Pin2(DGND)-------J5-Pin2(DGND)       |                     |                |                   |
-|                 |   ND            | |                                         |                     |                |                   |
-|                 |                 | | **am65xx EVM/IDK:**                     |                     |                |                   |
-|                 | **Additional    | | MCU1_0 (controller) ===== MPU1_0        |                     |                |                   |
-|                 | Requirements:** |   (peripheral)                            |                     |                |                   |
-|                 |                 |                                           |                     |                |                   |
-|                 | Run             | | **J721e EVM:**                          |                     |                |                   |
-|                 | "MCSPI_Peripher | | MCU1_0 (controller) ====== MPU1_0       |                     |                |                   |
-|                 | alMode_Peripher |   (peripheral)                            |                     |                |                   |
-|                 | alExample_      |                                           |                     |                |                   |
-|                 | <BoardType><arm |                                           |                     |                |                   |
-|                 | /c66x/m4>Exampl |                                           |                     |                |                   |
-|                 | eProject"       |                                           |                     |                |                   |
-|                 | first on        |                                           |                     |                |                   |
-|                 | Peripheral      |                                           |                     |                |                   |
-|                 | EVM and then    |                                           |                     |                |                   |
-|                 | "MCSPI_Peripher |                                           |                     |                |                   |
-|                 | alMode          |                                           |                     |                |                   |
-|                 | _ControllerExam |                                           |                     |                |                   |
-|                 | ple             |                                           |                     |                |                   |
-|                 | <BoardType>_<ar |                                           |                     |                |                   |
-|                 | m/c66x/m4>Examp |                                           |                     |                |                   |
-|                 | leProject"      |                                           |                     |                |                   |
-|                 | on Controller   |                                           |                     |                |                   |
-|                 | EVM.            |                                           |                     |                |                   |
-|                 |                 |                                           |                     |                |                   |
-|                 | |               |                                           |                     |                |                   |
-|                 | | **Note:**     |                                           |                     |                |                   |
-|                 |                 |                                           |                     |                |                   |
-|                 | A DGND          |                                           |                     |                |                   |
-|                 | connection may  |                                           |                     |                |                   |
-|                 | be required     |                                           |                     |                |                   |
-|                 | from expansion  |                                           |                     |                |                   |
-|                 | connector on    |                                           |                     |                |                   |
-|                 | each board to   |                                           |                     |                |                   |
-|                 | make sure the   |                                           |                     |                |                   |
-|                 | data transfer   |                                           |                     |                |                   |
-|                 | is proper.      |                                           |                     |                |                   |
-|                 |                 |                                           |                     |                |                   |
-|                 | For AM6 or J7,  |                                           |                     |                |                   |
-|                 | only one EVM is |                                           |                     |                |                   |
-|                 | required.       |                                           |                     |                |                   |
-|                 | Peripheral is   |                                           |                     |                |                   |
-|                 | run on MPU1_0   |                                           |                     |                |                   |
-|                 | core and Cont   |                                           |                     |                |                   |
-|                 | roller is run   |                                           |                     |                |                   |
-|                 | on MCU1_0 core  |                                           |                     |                |                   |
-+-----------------+-----------------+-------------------------------------------+---------------------+----------------+-------------------+
-| MCSPI_SMP_Basic | Sample          |                                           | |                   |    AM572x-EVM  | CCS project       |
-| Example         | Application     |                                           | | ** **             |                |                   |
-| application     | demonstrating   |                                           |                     |                |                   |
-|                 | reading data    |                                           | Following           |                |                   |
-|                 | generated from  |                                           | prints  on          |                |                   |
-|                 | industrial      |                                           | console             |                |                   |
-|                 | input module.   |                                           | expected:           |                |                   |
-|                 | Application     |                                           |                     |                |                   |
-|                 | uses GPIO pins  |                                           | **Pass              |                |                   |
-|                 | to assert load  |                                           | criteria:**         |                |                   |
-|                 | signal in order |                                           |                     |                |                   |
-|                 | to generate     |                                           | All tests have      |                |                   |
-|                 | date from       |                                           | passed.             |                |                   |
-|                 | industrial      |                                           |                     |                |                   |
-|                 | input module    |                                           |                     |                |                   |
-|                 | in SMP mode.    |                                           |                     |                |                   |
-|                 | (A15 core)      |                                           |                     |                |                   |
-+-----------------+-----------------+-------------------------------------------+---------------------+----------------+-------------------+
-
-Building SPI examples
-----------------------
-
--  Makefile based examples and dependent libraries can be built from the top level or module level SPI makefile, refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__  for details of how to setup the build environment. Once you have setup the build environment, issue the following commands:
-::
-
-   To build and clean libs/apps from top-level makefile:
-   cd <pdk>/packages
-   make spi
-   make spi_clean
-
-   To build and clean libs/apps from module-level makefile:
-   cd <pdk>/packages/ti/drv/spi
-   make all
-   make clean
-
-
--  RTSC CCS project based examples are built from CCS
-::
-
-   cd <pdk>/packages
-   ./pdkProjectCreate.sh [soc] [board] [endian] spi [project type] [processor] [SECUREMODE=<yes/no>]
-   Import and build CCS Project from  <pdk>/packages/MyExampleProjects/
-
-OSPI Driver Configuration to support QSPI flash
------------------------------------------------
-
-If the board has a QSPI flash, the PDK driver needs to be updated to support the QSPI flash:
-
--  Board QSPI Flash Instance Configuration in board_cfg.h
-::
-
-    #define BOARD_QSPI_NOR_INSTANCE  <OSPI instance connected to QSPI flash>
-
--  SPI SoC Driver Configurations:
-::
-
-    ...
-    OSPI_v0_HwAttrs ospi_cfg;
-
-    SPI_init();
-
-    OSPI_socGetInitCfg(BOARD_QSPI_NOR_INSTANCE, &ospi_cfg);
-    ospi_cfg.xferLines      = OSPI_XFER_LINES_QUAD;
-    ospi_cfg.pageSize       = <QSPI flash page size>;
-    ospi_cfg.devDelays[0]   = <QSPI device delay>;
-    ospi_cfg.devDelays[1]   = <QSPI device delay>;
-    ospi_cfg.devDelays[2]   = <QSPI device delay>;
-    ospi_cfg.devDelays[3]   = <QSPI device delay>;
-    ospi_cfg.rdDataCapDelay = <QSPI read capture delay>;
-    OSPI_socSetInitCfg(BOARD_OSPI_NOR_INSTANCE, &ospi_cfg);
-
-Support for Benchmark Testing
-------------------------------
-
-+-----------------------+-----------------------+-----------------------------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results                        | SOC/Core Suppported   | Build Type            |
-+=======================+=======================+=========================================+=======================+=======================+
-| OSPI flash Test App   | Test application used | Test application                        |  am65xx/A53           | make                  |
-|                       | for performance       | will print on the UART console:         |  am65xx/R5            |                       |
-|                       | benchmarking          |                                         |  j721e/mpu1_0         |                       |
-|                       |                       | Board_flashWrite ### bytes at transfer  |  j721e/mcu1_0         |                       |
-|                       |                       | rate #### Kbps                          |                       |                       |
-|                       |                       |                                         |                       |                       |
-|                       |                       | Board_flashRead ### bytes at transfer   |                       |                       |
-|                       |                       | rate #### Mbps                          |                       |                       |
-|                       |                       |                                         |                       |                       |
-|                       |                       | Board_flashWrite CPU Load %##           |                       |                       |
-|                       |                       |                                         |                       |                       |
-|                       |                       | Board_flashRead CPU Load %##            |                       |                       |
-+-----------------------+-----------------------+-----------------------------------------+-----------------------+-----------------------+
-
-.. note::
-
-  1. Data transfer between DDR and OSPI flash memory, performance measurement does not include time to invalidate/write back cache
-  2. GTC counter (200MHz) used for throughput measurement on A53, and PMU cycle counter (400MHz) on R5
-  3. sysbios load moduel used for load measurement
-  4. Pipeline PHY enabled, DDR mode enabled in DAC mode
-  5. Pipeline PHY disabled, DDR mode disabled in INDAC mode with ospi clock divider of 32
-  6. Read/write transfer size of 1M bytes
-  7. Write transfer size 1M bytes with DMA chunk size of 16 bytes in DAC DMA mode
-
-|
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------+
-| **Document**                      | **Location**                      |
-+-----------------------------------+-----------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\packages\ti |
-|                                   | \drv\spi\docs\doxygen\html\index. |
-|                                   | html                              |
-+-----------------------------------+-----------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\packages\ti |
-|                                   | \drv\spi\docs\ReleaseNotes_SPI_LL |
-|              git                  | D.pdf                             |
-+-----------------------------------+-----------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_RM.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_RM.rst
deleted file mode 100644
index 49f1ae81e..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_RM.rst
+++ /dev/null
@@ -1,208 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_RM
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The Resource Manager (RM) is delivered as part of Processor-SDK as a
-means for managing system resource contentions. RM has the ability to
-allocate system resources within a software architecture based on sets
-of allocation rules. Resources can be allocated to anything from a
-device core, to an OS task or process, to a specific software module.
-RM's resource management is defined by the RM configuration parameters
-and how RM is integrated within a software framework. The RM source code
-is device agnostic. The RM configuration parameters are device specific
-allowing RM to function on any processor capable of compiling and
-executing a C binary.
-
-.. rubric:: RM Instance Types
-   :name: rm-instance-types
-
-Resource Manager is an instance-based architecture. Integrating RM into
-a system consists of creating a set of RM instances, connecting these
-instances via message-passing mechanisms, and then using the instances
-to request resources for cores, processes, tasks, modules, etc. There
-are no restrictions on where a RM instance can be created as long as the
-means exist to connect the instance to other RM instances within the
-system.
-
-There are five instance types
-
-#. **Server**: Manages all defined system resources. Services resource
-   requests received from connected Client Delegates and Clients.
-#. **Client Delegate (CD)**: Acts as a low-request-latency proxy for the
-   RM Server, managing resources provided by the RM Server. Services
-   resource requests received from connected Clients.
-#. **Client**: Front-end for receiving/responding to resource requests
-   from application. Forwards resource requests to Server, or CD, for
-   servicing. Returns allocated resources to application once response
-   is received from Server or CD.
-#. **Shared Server**: Same as the standard Server except all resource
-   data structures are stored in shared memory allowing direct access
-   from Shared Client instances.
-#. **Shared Client**: Same as Client except has direct access to the
-   Server resource data structures via shared memory. Useful for low
-   latency requests but not as robust from a software architecture
-   perspective given shared memory MUST be available and used in order
-   for Shared Server-Clients to function.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: **Resource Configuration**
-   :name: resource-configuration
-
-The RM Server instance must be provided a resource list and allocation
-policy at initialization time. The resource list and allocation policy
-are specified in the open source flattened device tree format. Device
-specific resource list and allocation policy files are provided in
-``[PDK_INSTALL_PATH]/packages/ti/drv/rm/device/[SoC]/``.
-
-The Client Delegate and Client instances do not require a resource list
-and allocation policy at initialization.
-
-.. rubric:: **Transport Configuration**
-   :name: transport-configuration
-
-RM instances must be attached to one another using a message passing
-mechanism. This mechanism can be shared memory, software/hardware
-queues, sockets or any other method capable of sending and receiving
-data packets between endpoints on the SoC.
-
-An example transport implementation used by many PDK test applications
-is available in
-``[PDK_INSTALL_PATH]/packages/ti/drv/rm/test/rm_transport_setup.c``. The
-implementation uses an IPC shared memory transport to connect an RM
-Server to RM Clients on multiple DSP cores.
-
-APIs
-^^^^^
-
-RM instance init/delete/status API reference for application:
-
-::
-
-    #include <ti/drv/rm/rm.h>
-
-RM instance transport API reference for application:
-
-::
-
-    #include <ti/drv/rm/rm_transport.h>
-
-RM instance service request/response API reference for application:
-
-::
-
-    #include <ti/drv/rm/rm_services.h>
-
-RM Server interface API reference for application:
-
-::
-
-    #include <ti/drv/rm/rm_server_if.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  || Description          || Expected Results     |
-+=======================+=======================+=======================+
-| RM DSP BIOS Test      | | Unit Test           | | Application         |
-| application           |   application         |   successfully        |
-|                       |   exercising APIs and |   completes on two    |
-|                       |   the different       |   DSP cores.          |
-|                       |   service             |                       |
-|                       |   request/response    |                       |
-|                       |   mechanisms across   |                       |
-|                       |   the Server, Client  |                       |
-|                       |   Delegate, and       |                       |
-|                       |   Client instances.   |                       |
-+-----------------------+-----------------------+-----------------------+
-| RM Memory DSP BIOS    | | Unit Test           | | Application         |
-| Test application      |   application to test |   successfully        |
-|                       |   for memory leaks    |   completes with no   |
-|                       |   during resource     |   memory leaks on two |
-|                       |   request/free        |   DSP cores.          |
-|                       |   operations.         |                       |
-+-----------------------+-----------------------+-----------------------+
-| RM Shared DSP BIOS    | | Unit Test           | | Application         |
-| Test application      |   application         |   successfully        |
-|                       |   exercising Shared   |   completes with no   |
-|                       |   Server/Client APIs  |   memory leaks on two |
-|                       |   and resource        |   DSP cores.          |
-|                       |   allocation in a     |                       |
-|                       |   Shared              |                       |
-|                       |   Server/Client       |                       |
-|                       |   architecture.       |                       |
-+-----------------------+-----------------------+-----------------------+
-| RM DSP BIOS           | | Unit Test           | | Application         |
-| Multi-Threaded Test   |   application         |   successfully        |
-| application           |   verifying service   |   completes with no   |
-|                       |   request/response    |   memory leaks on a   |
-|                       |   mechanism in a      |   single DSP core.    |
-|                       |   multi-threaded      |                       |
-|                       |   architecture.       |                       |
-+-----------------------+-----------------------+-----------------------+
-| RM ARM Linux Test     | | Unit Test           | | Application         |
-| application           |   application         |   successfully        |
-|                       |   exercising APIs and |   completes when run  |
-|                       |   the different       |   from Linux          |
-|                       |   service             |   user-space.         |
-|                       |   request/response    |                       |
-|                       |   mechanisms across   |                       |
-|                       |   the Server, Client  |                       |
-|                       |   Delegate, and       |                       |
-|                       |   Client instances.   |                       |
-+-----------------------+-----------------------+-----------------------+
-| RM ARM Linux          | | Unit Test           | | Application         |
-| Multi-Threaded Test   |   application         |   successfully        |
-| application           |   verifying service   |   completes when run  |
-|                       |   request/response    |   from Linux          |
-|                       |   mechanism in a      |   user-space.         |
-|                       |   multi-threaded      |                       |
-|                       |   architecture.       |                       |
-+-----------------------+-----------------------+-----------------------+
-| Combined DSP BIOS &   | | Unit Test           | | Application         |
-| ARM Linux Test        |   application         |   successfully        |
-| application           |   verifying service   |   completes with no   |
-|                       |   request/response    |   memory leaks on two |
-|                       |   mechanism over a    |   DSP cores.          |
-|                       |   heterogeneous       |                       |
-|                       |   processor boundary. |                       |
-|                       |   RM Clients on two   |                       |
-|                       |   DSP cores request   |                       |
-|                       |   resources from an   |                       |
-|                       |   RM Server running   |                       |
-|                       |   in Linux            |                       |
-|                       |   user-space.         |                       |
-+-----------------------+-----------------------+-----------------------+
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\rm\\docs\\doxygen\\html\\index.h |
-|                                   | tml                                     |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\rm\\docs\\ReleaseNotes_RM.pdf    |
-+-----------------------------------+-----------------------------------------+
-| Resource Manager User Guide       | `Processor SDK Resource Manager`_       |
-+-----------------------------------+-----------------------------------------+
-
-.. _Processor SDK Resource Manager: http://processors.wiki.ti.com/index.php/Processor_SDK_Resource_Manager
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_SA.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_SA.rst
deleted file mode 100644
index 53bb55414..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_SA.rst
+++ /dev/null
@@ -1,120 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_SA
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The Security Accelerator (SA) also known as cp_ace (Adaptive
-Cryptographic Engine) is designed to provide packet security as part of
-IPSEC, SRTP, and 3GPP industry standards. The security accelerator low
-level driver (referred to as the module) provides APIs for the
-configuration and control of the security accelerator sub-system. The SA
-low level driver provides an abstraction layer between the application
-and the Security Accelerator Sub System (SASS). It provides both the
-system level interface and the channel-level interface with a set of
-APIs in the driver.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-Security accelerator library (ti.drv.sa) supports below modes
-
-**Protocol Specific Mode**: In this mode, standards such as Ipv4/Ipv6
-and 3gpp protocols are supported, where command labels are created based
-on the protocols.
-
-**Data Mode**: In this mode, user can implement a custom/proprietary
-protocol mode with the help of APIs provided by SA LLD
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The driver configures the SASS subsystem using SA_config_t (system
-configuration) and Channel Configuration (Sa_ChanConfig_t) structure.
-
-For details about individual fields of this structure and other APIs,
-see the Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\SA\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/SA/Salld.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+----------------------------------+----------------------------------+
-| Name                  | | Description         | | Expected Results    | | List of SOCs with              | | List of SOCs with              |
-|                       |                       |                       | Application Build Support as CCS | Applications Build Support Make  |
-+=======================+=======================+=======================+==================================+==================================+
-| SA_Example            | | CCS Project Example | | User observes the   | | K2HK, K2L, K2E, C6678          |    None                          |
-| application           |   demonstrating       |   output printed over |                                  |                                  |
-|                       |   *simple IPSec* use  |   the CCS console     |                                  |                                  |
-|                       |   case. Reference     |                       |                                  |                                  |
-|                       |   example for         |                       |                                  |                                  |
-|                       |   developers          |                       |                                  |                                  |
-+-----------------------+-----------------------+-----------------------+----------------------------------+----------------------------------+
-| SA_UnitTestApplication| | Unit Test           | | User observes the   | | K2HK, K2L, K2E, C6678, K2G     |    AM65XX                        |
-|                       |   application to test |   output printed over |                                  |                                  |
-|                       |   all APIs            |   the CCS console     |                                  |                                  |
-+-----------------------+-----------------------+-----------------------+----------------------------------+----------------------------------+
-
-**NOTE**
-: SA Unit Test applications are makefile based for AM65XX. Note that the application built, can be loaded on to CCS.
-
-Building SA Examples/Unit Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Setup the build environment `SetupBuildEnvironment <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#setup-environment>`__
-- Follow the steps `SDK example and test CCS Project Creation <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#pdk-example-and-test-project-creation>`__  for creating the CCS based example and test projects creation
-- Create make based test application executables following the link `Building the component and make based test application <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#rebuilding-components>`__. Once the build environment is set, issue the following commands:
-    -  cd <pdk>/packages/
-    -  To build: make sa
-    -  To clean: make sa_clean
-
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\sa\\docs\\doxygen\\html\\index.h |
-|                                   | tml                                     |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\sa\\docs\\ReleaseNotes_SA_LLD.   |
-|                                   | pdf                                     |
-+-----------------------------------+-----------------------------------------+
-
-.. note::
-
-   Although SASS supports 3GPP specific Ciphering and
-   Authentication algorithms such as Kasumi F8/F9 and Snow3G F8, those
-   algorithms are locked out in this standard SA LLD distribution. In order
-   to access 3GPP specific functionalities, one must obtain ETSI licensing
-   as described at
-   http://www.etsi.org/services/security-algorithms/cellular-algorithms and
-   then download the SASS 3GPP Enabler package from TI from the link
-   http://software-dl.ti.com/libs/sa_3gpp_enabler/latest/index_FDS.html
-
-
-Due to export control restrictions, the SA 3GPP Enabler is a seperate
-download from the rest of the PROCESSOR-SDK.
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_SCICLIENT.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_SCICLIENT.rst
deleted file mode 100644
index e1ddd18e2..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_SCICLIENT.rst
+++ /dev/null
@@ -1,492 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_SCICLIENT
-
-Overview
---------------
-
-
-Traditional Texas Instruments SoCs implement system control functions such as power management within operating systems on each of the processing units (ARM/DSP etc). However the traditional approach has had tremendous challenges to ensure system stability. Few of the challenges include:
-
-- Complex interactions between Operating Systems on heterogeneous SoCs for generic features.
-- Lack of centralized knowledge of system state.
-- Complex implementation challenges when implementing workarounds for SoC errata.
-- Equivalent SoC power or device management entitlement on all variations of Operating Systems.
-
-DMSC controls the power management of the device, hence is responsible for bringing the device out of
-reset, enforce clock and reset rules. DMSC power management functions are critical to bring device to low
-power modes, for example DeepSleep, and sense wake-up events to bring device back online to active
-state.
-There is one instance of DMSC in this family of devices - WKUP_DMSC0.
-
-Texas Instruments' System Control Interface defines the communication protocol between various processing entities to the System Control Entity on TI SoCs. This is a set of message formats and sequence of operations required to communicate and get system services processed from System Control entity in the SoC.
-
-More information regarding the TI-SCI is given `here <http://downloads.ti.com/tisci/esd/18_08_00/>`_ .
-
-The SCIClient is an interface to the TI-SCI protocol for RTOS and non-OS based applications. It exposes the core message details, valid module/clock IDs to the higher level software and abstracts the communication with SYSFW based on the TI-SCI protocol. These APIs can be called by power, resource and security RTOS drivers or any other non-OS or RTOS based higher level software to be able to communicate with DMSC for its services. The higher level software is expected to populate the necessary message core parameters.
-
-The firmware which runs on DMSC is called system-firmware(SYSFW) .The documentation for SYSFW can be found at docs/system-firmware-public-documentation/ .
-
-
-Terms and Abbreviation
-------------------------
-
-
-=====     =============================
-term      definition or explanation
-=====     =============================
-DMSC      Device Management and Security Controller
-SCI       System Control Interface
-SYSFW     System Firmware
-PM        Power Management
-RM        Resource Management
-=====     =============================
-
-
-Directory Structure
---------------------
-
-The directory structure of SCIClient is as follows:
-
-=================================  =============================
-docs/                               Contains SCIClient design documentation and System Firmware public documentation.
-include/                            This folder contains the files user needs to refer in order to communicate with SYSFW using `Sciclient_service`_ . The files in this folder define the request and response structures for communicating with SYSFW .
-src/                                Contains source(.c) files for the driver.
-soc/                                Contains SoC specific header files and firmware binary image. Refer to this folder for SoC sepcific parameters and board configuration. V0 - AM65xx, V1 - J721E.
-examples                            Contains examples for utilizing sciclient interfaces. For Sciclient shim layer examples kindly refer the PM, UDMA driver code.
-=================================  =============================
-
-Build and Run
-----------------
-
-This section assumes that you have PDK at PDK_INSTALL_DIR .
-
-::
-
-    PDK_ROOT_PATH = PDK_INSTALL_DIR/packages
-    PDK_BUILD_PATH = PDK_INSTALL_DIR/packages/ti/build
-    SCICLIENT_PATH = PDK_INSTALL_DIR/drv/sciclient
-
-
-Build targets
-^^^^^^^^^^^^^^^
-
-The driver provides targets for building library, unit tests and docs .
-The library and unit tests can be built from PDK_BUILD_PATH or SCICLIENT_PATH . The docs can only be built from SCICLIENT_PATH .
-
-==========================  =============================================================================================================================  =====================
-Target                      Command                                                                                                                        Description
-==========================  =============================================================================================================================  =====================
-Library                     make PDK_INSTALL_PATH=<your PDK_ROOT_PATH> BOARD=am65xx_evm  CORE=<mcu1_0(R5F) or mpu1_0(A53)> sciclient                       SCIClient library
-sciclient_ccs_init          make PDK_INSTALL_PATH=<your PDK_ROOT_PATH>  BOARD=am65xx_evm  CORE=<mcu1_0(R5F) or mpu1_0(A53)>  sciclient_ccs_init            SCIClient application that loads the firmware during ccs load.(No need to build this normally.)
-sciclient_firmware_boot     make PDK_INSTALL_PATH=<your PDK_ROOT_PATH>  BOARD=am65xx_evm  CORE=<mcu1_0(R5F) or mpu1_0(A53)>  sciclient_firmware_boot       SCIClient example application
-Design Doc                  make PDK_INSTALL_PATH=<your PDK_ROOT_PATH> designdoc                                                                           SCIClient design documentation
-==========================  =============================================================================================================================  =====================
-
-.. note:: For building the example "sciclient_firmware_boot" or "your
-   application" using SCIClient lib, make sure you have a section
-   "boardcfg_data" defined in your linker cmd file which resides in OC-MSRAM .
-
-The next sections will explain how to load the system firmware using sciclient.
-
-Load using a boot-media
-^^^^^^^^^^^^^^^^^^^^^^^^^
-Follow these steps to load the **sciclient_firmware_boot** application through a boot media:
-
-- Build the example: sciclient_firmware_boot_TestApp
-- The test case works with MMCSD boot mode where it loads the sysfw.bin file from the mmcsd card. Ensure to create a tiboot3.bin file from the sciclient application. Copy the SoC specific sysfw.bin in the SD card along with the tiboot3.bin file.
-- Refer the section `Boot-Modes <index_Foundational_Components.html#boot-modes>`_ for details on how to use a bootmedia.
-- You can also use the SBL to load the system firmware and initialize the SoC. Refer to the SBL user guide for more details.
-
-
-Load using CCS
-^^^^^^^^^^^^^^^^^^^^
-
-Follow these steps to load the **sciclient_ccs_init** application through CCS
-
-- Update the File SCICLIENT_PATH/sciclient/tools/ccsLoadDmsc/<soc>/launch.js for
-  the following variables to your PC location.
-
-Modify for AM65xx:
-
-.. code:: js
-
-    //Path to GEL files
-    gelFilePath = "<Your CCS Path>/ccs_base/emulation/gel/AM65xEVM/"; → GEL path location
-    // Path to the directory in which this file would be residing. CCS expects
-    // absolute paths to load the binaries.
-    thisJsFileDirectory = "PDK_INSTALL_DIR/packages/ti/drv/sciclient/tools/ccsLoadDmsc";
-
-Modify for J721E:
-
-.. code:: js
-
-    //PDK path. Edit this
-    pdkPath = "PDK_INSTALL_DIR";
-
-- Connect the Javascript to the CCXML file with the steps shown below: (Note: this step needs to be repeated if you switch workspaces or clean your workspace).The Javascript is run on re-launch of the ccxml. If you would like to run the Javascript without relaunch then you can look ahead to the section: "Re-running the script once ccxml is already launched." Click on Debug Configurations from the button as follows:
-
-.. image:: /images/sciclient_ccsLoad1.png
-    :height: 300
-    :width: 600
-
-- Select the CCXML file from the left-hand side and populate the path to the launch_am65xx.js file in the "Initialization Script" free form field and click on "Apply".
-
-.. image:: /images/sciclient_ccsLoad2.png
-    :height: 300
-    :width: 600
-
-- Once you Launch the ccxml the java script would automatically run and connect to R5F.
-
-
-.. rubric:: **Re-running the script once ccxml is already launched**
-
-In the CCS window open the "View → Scripting Console.."
-In the CCS Scripting Console type:
-
-.. code:: console
-
-    load("SCICLIENT_PATH\\tools\\ccsLoadDmsc\\am65xx\\launch.js")
-
-or
-
-.. code:: console
-
-    load("SCICLIENT_PATH\\tools\\ccsLoadDmsc\\j721e\\launch.js")
-
-This would give the following output on the scripting console
-
-For AM65xx:
-
-.. code:: console
-
-    js:> load("SCICLIENT_PATH\\tools\\ccsLoadDmsc\\am65xx\\launch.js")
-    Connecting to DMSC_Cortex_M3_0!
-    Loading DMSC Firmware...
-    DMSC Firmware Load Done...
-    DMSC Firmware run starting now...
-    Connecting to MCU Cortex_R5_0!
-
-For J721E:
-
-.. code:: console
-
-    js:> load("SCICLIENT_PATH\\tools\\ccsLoadDmsc\\j721e\\launch.js")
-    Connecting to DMSC_Cortex_M3_0!
-    Loading DMSC Firmware...
-    DMSC Firmware Load Done...
-    DMSC Firmware run starting now...
-    Connecting to MCU Cortex_R5_0!
-    Running the board configuration initialization from R5!
-    Running the DDR configuration... Wait till it completes!
-    Okay you are good to go.. Happy Debugging!
-
-Handling Two or more ccxml files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In case you need to connect two or more board to the same CCS session and use the launch script, please follow the steps below:
-
-- When you use 2 or more CCXML files with similar debugger (e.g. connect 2 boards XDS110 on-board debugger to the PC), CCS would enumerate the debuggers as below:
-
-.. code:: console
-
-    Texas Instruments XDS110 USB Debug Probe_0
-    Texas Instruments XDS110 USB Debug Probe_1
-
-Notice the suffix "_0" and "_1".
-- In order to use the same launch.js file with this, please create a second copy of the launch.js file. Update the first launch.js files as below:
-
-.. code:: js
-
-    function updateScriptVars()
-    {
-        //Open a debug session
-        dsMCU1_0 = debugServer.openSession( "*_0.*MCU_PULSAR_Cortex_R5_0" );
-        dsDMSC_0 = debugServer.openSession( "*_0.*DMSC_Cortex_M3_0" );
-    }
-
-Update the second launch.js as below:
-
-.. code:: js
-
-    function updateScriptVars()
-    {
-        //Open a debug session
-        dsMCU1_0 = debugServer.openSession( "*_1.*MCU_PULSAR_Cortex_R5_0" );
-        dsDMSC_0 = debugServer.openSession( "*_1.*DMSC_Cortex_M3_0" );
-    }
-
-Notice the addition of "\*_0" and "\*_1"
-
-System Firmware Logs Parse
---------------------------
-
-In many cases you may need to understand and debug if a System Firmware API fails due to incorrect parameters or some genuine issue in the firmware. In order to debug when the API is failing, you need to follow the steps below:
-
-- Enable logs in the system firmware by modifying the below structure:
-
-File: sciclient\soc\Vx\sciclient_defaultBoardcfg.c
-Structure: const struct tisci_boardcfg gBoardConfigLow
-Update the structure to have trace enabled:
-
-.. code:: c
-
-    /* This enables the trace for DMSC logging. Should be used only for
-     * debug.
-     */
-    .trace_dst_enables = (TISCI_BOARDCFG_TRACE_DST_UART0 |
-                          TISCI_BOARDCFG_TRACE_DST_ITM |
-                          TISCI_BOARDCFG_TRACE_DST_MEM),
-    .trace_src_enables = (TISCI_BOARDCFG_TRACE_SRC_PM |
-                          TISCI_BOARDCFG_TRACE_SRC_RM |
-                          TISCI_BOARDCFG_TRACE_SRC_SEC |
-                          TISCI_BOARDCFG_TRACE_SRC_BASE |
-                          TISCI_BOARDCFG_TRACE_SRC_USER |
-                          TISCI_BOARDCFG_TRACE_SRC_SUPR)
-
-- Capture the System firmware logs from the WKUP_USART0.
-- Get the parsed logs from **sciclient\tools\sysfw_trace_parser\sysfw_trace_parser.py**
-
-.. code:: console
-
-    usage: python ./sysfw_trace_parser.py [-h] (-l LOG_FILE | -d SERIAL_PORT)
-                                (-o OUTPUT_FILE | -O) [-t] [-r RULES_FILE]
-                                [-Pm]
-
-    System Firmware Log Parse utility URL: http://software-
-    dl.ti.com/tisci/esd/latest/4_trace/trace.html
-
-    Required arguments - Choose one of the inputs:
-    -l LOG_FILE, --log_file LOG_FILE
-                            Log File provided as input (default: None)
-    -d SERIAL_PORT, --serial_port SERIAL_PORT
-                            Provide Device as input: Requires pyserial package
-                            installed: See https://pyserial.readthedocs.io/
-                            (default: None)
-
-    Required arguments - Choose one of the outputs:
-    -o OUTPUT_FILE, --output_file OUTPUT_FILE
-                            Parse out the output to a file (default: None)
-    -O, --output_console  Log File to parse and report results to console
-                            (default: False)
-
-    optional arguments:
-    -h, --help            show this help message and exit
-    -t, --time_stamp_relative
-                            Add TimeStamp to output in relative milliseconds(this
-                            is approximation ONLY) (default: False)
-    -r RULES_FILE, --rules_file RULES_FILE
-                            Alternate Rules file (default: ./sysfw_trace_rules.json)
-    -Pm, --print_match_only
-                            Print just decoded data, (default: False)
-
-API descriptions
-------------------
-
-API reference for application:
-
-.. code:: c
-
-    #include <ti/drv/sciclient/sciclient.h>
-
-The driver is split into 2 parts:
-
-- `SCIClient Core`_ : This has APIs for loading SYSFW ,initialization,
-  de-initialization and SYSFW communication. These are defined in `sciclient.h`.
-
-- `SCIClient Shim Layer`_ : This thin layer abstracts the message requests and
-  responses sent to SYSW for `Power_management`_  ,  `Resource_management`_ and
-  `Processor_BOOT_API_Interface`_ which the user can use without worrying about
-  the request and response structures used.
-
-SCIClient Core
-^^^^^^^^^^^^^^^^^^^^^^^
-
-The following core APIs for SCIClient are declared in sciclient.h.
-
-.. rubric:: Firmware Load
-
-.. _Sciclient_loadFirmware:
-
-This API loads SYSFW.The image must be loaded through a boot media for this API
-to succeed (Refer `Build and Run`_). Hence, this is typically called by SBL.
-Load firmware call does not require `Sciclient_init`_ to be done before.
-
-.. note::
-
-    Defined in sciclient.h as Sciclient_loadFirmware.
-
-Typical usage
-
-.. code:: c
-
-    static const uint32_t gSciclient_firmware[BINARY_FILE_SIZE_IN_BYTES / 4U] =SCICLIENT_FIRMWARE;
-    .
-    .
-    .
-    Sciclient_loadFirmware(gSciclient_firmware);
-
-.. rubric:: SCIClient initialization
-
-.. _Sciclient_init:
-
-This API is called once for registering interrupts and creating semaphore
-handles to be able to talk to the firmware. The application should assume that
-the firmware is pre-loaded while calling this API. The firmware should have been
-loaded either via GEL or via the SBL (refer `Sciclient_loadFirmware`_ ) prior to
-the application calling this.
-
-The API **Sciclient_init** takes a pointer to *Sciclient_ConfigPrms_t* as input.
-
-- The parameter *opModeFlag* allows 2 operation modes for `Sciclient_service`_ :
-
-    +-----------------------+----------------------------------------------------------------+
-    | opModeFlag            | Description                                                    |
-    +=======================+================================================================+
-    | Polling based         |  Invoked using   SCICLIENT_SERVICE_OPERATION_MODE_POLLED       |
-    +-----------------------+----------------------------------------------------------------+
-    | Interrupt based       | Invoked using   SCICLIENT_SERVICE_OPERATION_MODE_INTERRUPT     |
-    +-----------------------+----------------------------------------------------------------+
-
-.. note:: Defined in sciclient.h as **Sciclient_init**.
-
-
-.. note::
-
-    - This API provides a software initialization for the driver. Any
-      application using SCIClient must call this API.
-
-    - SCICLIENT_SERVICE_OPERATION_MODE_INTERRUPT is not supported as of now.
-
-
-Typical usage
-
-.. code:: c
-
-    Sciclient_ConfigPrms_t        config =
-    {
-        SCICLIENT_SERVICE_OPERATION_MODE_POLLED,
-        NULL
-    };
-    Sciclient_init(&config);
-
-.. rubric:: SYSFW communication
-
-.. _Sciclient_service:
-
-This API allows communicating with the System firmware which can be called to
-perform various functions in the system. Core SCIClient function for
-transmitting payload and recieving the response. The caller is expected to
-allocate memory for the input request parameter **Sciclient_ReqPrm_t** . This
-involves setting the message type being communicated to the firmware, the
-response flags, populate the payload of the message based on the inputs in the
-files located at include/tisci/ . Since the payload in considered a stream of
-bytes in this API, the caller should also populate the size of this stream in
-reqPayloadSize. The timeout is used to determine for what amount of iterations
-the API would wait for their operation to complete.
-
-To make sure the response is captured correctly the caller should also allocate
-the space for **Sciclient_RespPrm_t** parameters. The caller should populate the
-pointer to the pRespPayload and the size respPayloadSize. The API would populate
-the response flags to indicate any firmware specific errors and also populate
-the memory pointed by pRespPayload till the size given in respPayloadSize.
-
-.. note::
-
-    Defined in sciclient.h as **Sciclient_service** .
-
-Typical usage
-
-.. code:: c
-
-    const Sciclient_ReqPrm_t      reqPrm =
-    {
-        TISCI_MSG_VERSION,
-        TISCI_MSG_FLAG_AOP,
-        NULL,
-        0,
-        SCICLIENT_SERVICE_WAIT_FOREVER
-    };
-
-    struct tisci_msg_version_resp response;
-    Sciclient_RespPrm_t           respPrm =
-    {
-        0,
-        (uint8_t *) &response,
-        sizeof (response)
-    };
-    status = Sciclient_init(&config);
-    status = Sciclient_service(&reqPrm, &respPrm);
-
-
-.. rubric:: SCIClient de-initialization
-
-.. _Sciclient_deinit:
-
-De-initialization of sciclient. This de-initialization is specific
-to the application. It only de-initializes the semaphores,
-interrupts etc. which are initialized using `Sciclient_init`_ . It does
-not de-initialize the system firmware.
-
-.. note::
-
-    Defined in sciclient.h as **Sciclient_deinit** .
-
-Typical usage
-
-.. code:: c
-
-    Sciclient_deinit();
-
-.. rubric:: Board configuration
-
-One time board configuration needs to be done from R5 for rm,pm and security to
-communicate with SYSFW. It is normally done by SBL, so user doesn't need to call
-these APIs.
-
-User needs to define a section ".boardcfg_data" in the linker file for the
-default configuration (NULL pointer to *Sciclient_BoardCfgPrms_t* is passed to
-the APIs), which needs to be present in OCMRAM. If user provides custom
-board_cfg, then the data must be present on OCMRAM.
-
-.. note::
-
-    Board configuration structure is defined in include/V0/sciclient_boardcfg.h
-    as Sciclient_BoardCfgPrms_t.
-
-Typical usage
-
-.. code:: c
-
-    status = Sciclient_boardCfg(NULL);
-    if (CSL_PASS == status)
-    {
-        status = Sciclient_boardCfgPm(NULL) +
-                Sciclient_boardCfgRm(NULL) +
-                Sciclient_boardCfgSec(NULL) ;
-    }
-
-SCIClient Shim Layer
-^^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: Power management
-
-.. _Power_management:
-
-The APIs in include/sciclient_pm.h provide declarations of SCIClient APIs for power management of the SOC .
-
-.. rubric:: Resource management
-
-.. _Resource_management:
-
-The APIs in include/sciclient_rm.h provide declarations of SCIClient APIs for resource management of the SOC .
-
-
-.. rubric:: Processor BOOT API Interface
-
-.. _Processor_BOOT_API_Interface:
-
-The APIs in include/sciclient_procboot.h provide declarations of SCIClient APIs for processor boot and control.
-
-APIs are divided into the following two sets
-
-- Book keeping APIs - Meant to control access to allow a reasonable usage scenario of processors.
-- Processor Control APIs - Meant to be the actual Processor Corecontrols.
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_SRIO.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_SRIO.rst
deleted file mode 100644
index 8d76baf5f..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_SRIO.rst
+++ /dev/null
@@ -1,245 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_SRIO
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-Driver enables the high-bandwidth system level interconnects. It is
-intended to offer Gigabyte per second performance levels for
-chip-to-chip and board-to-board communication.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-Following modes of operations are supported
-
-**Direct I/O**: The SRIO packet contains the specific address where the
-data should be stored or read in the destination device. This means that
-the source device must have detailed knowledge of the available memory
-space within the destination device.
-
-**Type 9**: A destination address is not specified. Instead the Stream
-ID is used to map the request to a specific memory region by the local
-(destination) device. TI IP additionally uses Class of Service (COS) as
-well to further classify the mapping of a request to a memory region.
-
-**Type 11**: A destination address is not specified, instead, a
-mailbox identifier is used within the SRIO packet. The mailbox is
-controlled and mapped to memory by the local (destination) device.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All board specific configurations eg:enabling and configuring the SRIO
-SERDES registers and SRIO lane configurations (communication rates,
-device IDs, etc) are required before calling any driver APIs. Template
-functions for configuring the SRIO IP and SERDES registers are provided
-in PDK_INSTALL_DIR\\packages\\ti\\drv\\srio\\device\\<device>\\src\\. A template
-function is provided for each soc that supports SRIO.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/srio/srio_drv.h>
-
-OSAL API reference for application:
-
-::
-
-    #include <ti/drv/srio/srio_osal.h>
-
-.. rubric:: Init SRIO
-   :name: init-srio
-
-::
-
-    Initialize QMSS and CPPI modules...
-
-::
-
-    ...
-    SrioDevice_init();
-    Srio_init ();
-    ...
-    /* Start the application Managed SRIO Driver. Refer example/test for appCfg fields */
-    hAppManagedSrioDrv = Srio_start (&appCfg);
-
-At this point SRIO driver is ready for data transfer on specific
-instance identified by handle.
-
-.. rubric:: Send/Receive APIs
-   :name: sendreceive-apis
-
-**Direct IO**:
-
-::
-
-    Srio_sockSend_DIO(Srio_SockHandle srioSock, Srio_DrvBuffer hBuffer, uint32_t size, Srio_SockAddrInfo* to);
-
-**Type 9**:
-
-::
-
-    Srio_sockSend_TYPE9   (Srio_SockHandle srioSock, Srio_DrvBuffer hBuffer, uint32_t size, Srio_SockAddrInfo* to);
-
-**Type 11**:
-
-::
-
-    Srio_sockSend_TYPE11  (Srio_SockHandle srioSock, Srio_DrvBuffer hBuffer, uint32_t size, Srio_SockAddrInfo* to);
-
-**Receive**:
-
-::
-
-    Srio_sockRecv         (Srio_SockHandle srioSock, Srio_DrvBuffer* hDrvBuffer,Srio_SockAddrInfo* from);
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+----------------------------+
-| Name                  || Description          | Expected Results           |
-+=======================+=======================+============================+
-| Loopback DIO ISR      ||  The example is a    | The application            |
-| Example Project       | demonstration of the  | will run through a         |
-|                       | SRIO driver running   | set of DIO tests.          |
-|                       | the SRIO IP Block in  | Upon successful            |
-|                       | loopback mode. The    | completion the             |
-|                       | example showcases the | following string           |
-|                       | use of SRIO DIO       | will be printed            |
-|                       | sockets using LSU     | "DIO with                  |
-|                       | interrupts to         | Interrupts example         |
-|                       | indicate the          | completed                  |
-|                       | completion of packet  | successfully."             |
-|                       | transfer.             |                            |
-|                       |                       |                            |
-|                       || It is shown how      |                            |
-|                       | multiple sockets      |                            |
-|                       | with different        |                            |
-|                       | Source IDs can post   |                            |
-|                       | transactions and      |                            |
-|                       | process the pending   |                            |
-|                       | interrupt raised by   |                            |
-|                       | SRIO device.          |                            |
-+-----------------------+-----------------------+----------------------------+
-| Multicore Loopback    || The example is a     | The application            |
-| Example Project       | demonstration of the  | will run through a         |
-|                       | SRIO driver while     | set of tests               |
-|                       | operating in a        | sending and                |
-|                       | Multicore environment | receiving data             |
-|                       | by running the SRIO   | between two cores          |
-|                       | IP Block in loopback  | over SRIO. Upon            |
-|                       | mode. The test case   | successful                 |
-|                       | here showcases the    | completion the             |
-|                       | SRIO Driver API being | following string           |
-|                       | multicore safe and    | will be printed            |
-|                       | using the SRIO IP     | "Multicore Test            |
-|                       | peripheral to         | Passed" from each          |
-|                       | exchange messages     | DSP core.                  |
-|                       | between different     |                            |
-|                       | cores running on the  |                            |
-|                       | same device.          |                            |
-|                       |                       |                            |
-|                       || In this test case    |                            |
-|                       | each core performs    |                            |
-|                       | the role of a         |                            |
-|                       | producer and          |                            |
-|                       | consumer. The test    |                            |
-|                       | starts with Core 1    |                            |
-|                       | sending data to       |                            |
-|                       | Core 2. Core 2        |                            |
-|                       | receives and          |                            |
-|                       | validates the data    |                            |
-|                       | and sends another     |                            |
-|                       | data message to       |                            |
-|                       | Core3; which          |                            |
-|                       | receives and          |                            |
-|                       | validates the data    |                            |
-|                       | and sends another     |                            |
-|                       | different data        |                            |
-|                       | message to Core 0.    |                            |
-|                       | Core 0 then sends a   |                            |
-|                       | message to Core 1     |                            |
-|                       | which is received     |                            |
-|                       | and validated.        |                            |
-+-----------------------+-----------------------+----------------------------+
-| Loopback Test         || Unit Test            | The application            |
-|                       | application to test   | will run through a         |
-|                       | all APIs              | set of tests to            |
-|                       |                       | verify all SRIO LLD        |
-|                       |                       | APIS. Upon                 |
-|                       |                       | successful                 |
-|                       |                       | completion the             |
-|                       |                       | following string           |
-|                       |                       | will be printed            |
-|                       |                       | "Unit Testing              |
-|                       |                       | completed                  |
-|                       |                       | successfully." from        |
-|                       |                       | each DSP core.             |
-+-----------------------+-----------------------+----------------------------+
-| SRIO Benchmarking     || The SRIO benchmarking| Review the SRIO            |
-| Test                  | example code is       | Benchmarking Example       |
-|                       | created to allow      | documentation located      |
-|                       | customers to run      | in                         |
-|                       | benchmarks on their   | PDK_INSTALL_DIR\\packa     |
-|                       | own TI EVMs with code | ges\\ti\\drv\\srio\\test\\ |
-|                       | that utilizes the     | tput_benchmarking\\doc     |
-|                       | SRIO LLD APIs. The    | s\\SRIO_Benchmarking_E     |
-|                       | benchmarking example  | xample_Code_Guide.doc      |
-|                       | code allows the user  | for more information       |
-|                       | to run core to core   | on the tests               |
-|                       | in loopback mode      | pass/fail criteria.        |
-|                       | (internal or          |                            |
-|                       | external) on a single |                            |
-|                       | EVM, or board to      |                            |
-|                       | board using the       |                            |
-|                       | external interface    |                            |
-|                       | between two EVMs.     |                            |
-|                       | This document’s       |                            |
-|                       | purpose is to explain |                            |
-|                       | how measurements are  |                            |
-|                       | obtained and how to   |                            |
-|                       | configure the example |                            |
-|                       | code for different    |                            |
-|                       | test scenarios. SRIO  |                            |
-|                       | physical connectivity |                            |
-|                       | or external SRIO      |                            |
-|                       | switch configuration  |                            |
-|                       | is beyond the scope   |                            |
-|                       | of this document.     |                            |
-+-----------------------+-----------------------+----------------------------+
-
-|
-
-Additional References
----------------------
-
-+-----------------------------------+----------------------------------------+
-| **Document**                      | **Location**                           |
-+-----------------------------------+----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\srio\\docs\\doxygen\\html\\index|
-|                                   | .html                                  |
-+-----------------------------------+----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\srio\\docs\\ReleaseNotes_SRIOD  |
-|                                   | river.pdf                              |
-+-----------------------------------+----------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_Serdes_Diag.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_Serdes_Diag.rst
deleted file mode 100644
index 20a9ee298..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_Serdes_Diag.rst
+++ /dev/null
@@ -1,161 +0,0 @@
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-This tool demonstrates how to configure and use the Serdes Diag APIs
-on KeyStone 3 device family. The DIAG APIs currently support R5F arch.
-There are 2 tests included in the package:
-
--  Serdes Diag BER Test
--  Serdes Diag EYE Test
-
--  **Serdes Diag BER Test:** The example finds out the optimal TX coefficients
-   (CM, C1, C2) by performing Bit Error Rate (BER) sweeps on the Serdes where the
-   EVM sends the transmit pattern (for example PRBS 31) and the EVM also detects
-   the receive sequence and performs BER calculations across the desired serdes
-   using the CPU. The sweep results are printed into a text file.
--  **Serdes Diag EYE Test** The example performs on chip eye measurement
-   allowing the user to see the eye opening of the receive data after
-   equalization. The EVM sends the transmit pattern (for example PRBS 31) and
-   detects the sequence and performs EYE measurements across the desired serdes
-   using the CPU. The results are printed into a text file.
-
-.. note::
-
-   Currently only internal loopback is supported on the EVM.
-
-|
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **Serdes Diag Configuration Structure**
-   :name: serdes_diag-configuration-structure
-
-serdes_diag_test_main.c contains the main function. It initializes all the
-serdes peripherals using the serdes_diag_test_init( ) API. The
-serdes_diag_test_phy_type should be specified in serdes_diag_platform.h
-in order to run the BER/EYE test for that specific SERDES.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/diag/serdes_diag/src/am65xx/serdes_diag_k3.h>
-
- Sample code for initiating Serdes Diag transaction:
-
-::
-
-    ...
-    /* Initiatize the serdes using serdes_diag_platform.h
-    */
-    serdes_diag_test_init();
-    ...
-    /* BER Test Initialization Parameters can be edited
-    inside this API */
-    Serdes_Example_BERTest();
-    OR
-    /* On Die Scope/Eye Scan Test Initialization Parameters
-    can be edited inside this API */
-    Serdes_Example_EYETest();
-    ...
-    ...
-
-
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-Refer Release Note for Serdes Diag support across different EVMs
-
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-|| Name                 || Description          ||  Expected Results    | SoC Supported       | Build Type          |
-+=======================+=======================+=======================+=====================+=====================+
-| serdes_diag_BER_app   || BER example          || Following prints will|    am65xx           | makefile            |
-|                       |                       |  come on console based|                     |                     |
-|                       |                       |  on pass/fail         |                     |                     |
-|                       |                       |  criteria:            |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || **Pass criteria:**   |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || The sweep results are|                     |                     |
-|                       |                       |  printed into a text  |                     |                     |
-|                       |                       |  file                 |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-| serdes_diag_EYE_app   || EYE example          || Following prints will|    am65xx           | makefile            |
-|                       |                       |  come on console based|                     |                     |
-|                       |                       |  on pass/fail         |                     |                     |
-|                       |                       |  criteria:            |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || **Pass criteria:**   |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || I2C Test: 100Kbps:   |                     |                     |
-|                       |                       |  PASS                 |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || I2C Test: 400Kbps:   |                     |                     |
-|                       |                       |  PASS                 |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || I2C Test: timeout    |                     |                     |
-|                       |                       |  test passed          |                     |                     |
-|                       |                       ||                      |                     |                     |
-|                       |                       || All tests have       |                     |                     |
-|                       |                       |  passed.              |                     |                     |
-+-----------------------+-----------------------+-----------------------+---------------------+---------------------+
-
-.. note::
-
-   Currently only R5F platform is supported with the above examples.
-
-Building Serdes Diag examples
-----------------------
-
--  Makefile based examples and dependent libraries can be built from the top level or module level Serdes Diag makefile, refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__  for details of how to setup the build environment. Once you have setup the build environment, issue the following commands:
-::
-
-   To build and clean libs/apps from top-level makefile:
-   cd <pdk>/packages
-   make serdes_diag
-   make serdes_diag_clean
-
-   To build and clean libs/apps from module-level makefile:
-   cd <pdk>/packages/ti/diag/serdes_diag
-   make all
-   make clean
-
-
--  CCS project based examples are built from CCS
-::
-
-   cd <pdk>/packages
-   ./pdkProjectCreate.sh [soc] [board] [endian] serdes_diag [project type] [processor] [SECUREMODE=<yes/no>]
-   Import and build CCS Project from  <pdk>/packages/MyExampleProjects/
-
-
-Additional References
----------------------
-
-+-----------------------+------------------------------------------+
-| **Document**          |  **Location**                            |
-+-----------------------+------------------------------------------+
-| API Reference Manual  | $(TI_PDK_INSTALL_DIR)\\packages\\ti      |
-|                       | \\diag\\serdes_diag\\docs\\doxygen\\html |
-|                       | \\index.html                             |
-+-----------------------+------------------------------------------+
-| Release Notes         | $(TI_PDK_INSTALL_DIR)\\packages\\ti      |
-|                       | \\diag\\serdes_diag\\docs\\Serdes_Diag_  |
-|                       | Release_Notes.pdf                        |
-+-----------------------+------------------------------------------+
-
-|
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_TSIP.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_TSIP.rst
deleted file mode 100644
index f262d010f..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_TSIP.rst
+++ /dev/null
@@ -1,93 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_TSIP
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The TSIP is a multi-link serial interface consisting of a maximum of
-eight transmit data signals (or links), eight receive data signals (or
-links), two frame sync input signals, and two serial clock inputs.
-Internally the TSIP offers multiple channels of timeslot data management
-and multi-channel DMA capability that allow individual timeslots to be
-selectively processed.
-
-The module can be configured to use the frame sync signals and the
-serial clocks as redundant sources for all transmit and receive data
-signals, or one frame sync and serial clock for transmit and the second
-frame sync and clock for receive. The standard serial data rate for each
-TSIP transmit and receive data signal is 8.192 Mbps. The standard frame
-sync is a one or more bit wide pulse that occurs once every 125 µs or a
-minimum of one serial clock period every 1024 serial clocks.
-
-At the standard rate and default configuration there are eight transmit
-and eight receive links that are active. Each serial interface link
-supports up to 128 8-bit timeslots. This corresponds to an H-MVIP or
-H.110 serial data rate interface. The serial interface clock frequency
-can be either 16.384 MHz (default) or 8.192 MHz. The data rate for the
-serial interface links can also be set to 16.384 Mbps or 32.768 Mbps.
-The maximum number of active serial links is reduced to four and two,
-respectively, in these configurations. The serial interface clock
-frequency can be either 32.768 MHz or 16.384 MHz for 16.384 Mbps serial
-links, and 65.536 MHz or 32.768 MHz for 32.768 Mbps serial links.
-Maximum occupation of the serial interface links for the entire TSIP is
-1024 transmit and receive timeslots in all configurations.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-TSIP configuration involves configurations for desired stagger phase of
-a TSIP timeout, using Tsip_configPhase() API. For details about
-individual fields of this structure, see the Doxygen help by opening
-PDK_INSTALL_DIR\\Packages\\ti\\drv\\TSIP\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/tsip/tsip.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | Expected Results      |
-+=======================+=======================+=======================+
-| tsip_Example          | | Example             | | User observes the   |
-| application           |   demonstrating       |   output printed over |
-|                       |   *sample tsip* test. |   the CCS console     |
-|                       |   Reference example   |                       |
-|                       |   for developers      |                       |
-+-----------------------+-----------------------+-----------------------+
-| tsip_UnitTestApplicat | | Unit Test           | | User observes the   |
-| ion                   |   application to test |   output printed over |
-|                       |   all APIs            |   the CCS console     |
-+-----------------------+-----------------------+-----------------------+
-
-Additional References
----------------------
-
-+-----------------------------------+-----------------------------------------+
-| **Document**                      | **Location**                            |
-+-----------------------------------+-----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\TSIP\\docs\\doxygen\\html\\index |
-|                                   | .html                                   |
-+-----------------------------------+-----------------------------------------+
-| Release Notes                     | $(TI_PDK_INSTALL_DIR)\\packages\\ti     |
-|                                   | \\drv\\TSIP\\docs\ReleaseNotes_TSIP.    |
-|                                   | pdf                                     |
-+-----------------------------------+-----------------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_UART.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_UART.rst
deleted file mode 100644
index aede27ed5..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_UART.rst
+++ /dev/null
@@ -1,282 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_UART
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-Driver enables UART's available on SOC for reading and writing to any
-peripherals on board. Additionally it supports simple APIs for
-Console/STDIO operations.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
-Following modes of operations are supported
-
-**UART_MODE_BLOCKING**: In this mode, read and write APIs, blocks on
-semaphore until required operation is complete. By default, UART driver
-operates in blocking mode. In this mode, code execution of a task blocks
-until UART transaction is complete. While transaction is in progress
-additional tasks pending requests will remain in blocked state waiting
-for semaphore.
-
-**UART_MODE_CALLBACK**: In this mode, read and write operation returns
-immediately. On trigger of hardware Interrupt (hwi) callback function
-gets triggered.
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All board specific configurations eg:enabling clock and pin-mux for UART
-pins are required before calling any driver APIs.By default Board_Init()
-API supports all initialization sequence for TI supported EVMs. In
-addition it initializes UART instance for Console/STDIO.Refer `Processor
-SDK RTOS Board Support <index_board.html#board-support>`__
-for additional details.Once board specific configuration is complete 
-UART_init() API can be called to initialize driver.
-
-.. rubric:: **UART Configuration Structure**
-   :name: uart-configuration-structure
-
-The UART_soc.c file binds driver with hardware attributes on the board
-through UART_config structure. This structure must be provided to UART
-driver. It must be initialized before the UART_init() function is called
-and cannot be changed afterwards. For details about individual fields of
-this structure, see the Doxygen help by opening
-PDK_INSTALL_DIR\packages\ti\drv\uart\docs\doxygen\html\index.html.
-
-APIs
-^^^^
-
-API reference for application:
-
-::
-
-    #include <ti/drv/uart/UART.h>
-
-STDIO API reference for application:
-
-::
-
-    #include <ti/drv/uart/UART_stdio.h>
-
-.. rubric:: Open UART
-   :name: open-uart
-
-There are three ways to open a UART instance:
-
-1. UART_open()
-
-::
-
-    ...
-    Board_init(boardCfg);
-    ...
-    UART_socGetInitCfg(UART_INSTANCE, &uart_cfg);
-    ...
-    UART_socSetInitCfg(UART_INSTANCE, &uart_cfg);
-    ...
-    UART_Params_init(&params);
-    ...
-    handle = UART_open(UART_INSTANCE, &params);
-
-At this point UART driver is ready for data transfer on specific
-instance identified by handle. Application can call UART_read/write
-API for read/write operation
-
-2. UART_stdioInit() using the default UART parameters
-
-::
-
-    ...
-    Board_init(boardCfg);
-    ...
-    UART_socGetInitCfg(UART_INSTANCE, &uart_cfg);
-    ...
-    UART_socSetInitCfg(UART_INSTANCE, &uart_cfg);
-    ...
-    UART_stdioInit(UART_INSTANCE);
-
-At this point UART driver is ready for data transfer on specific
-instance. Application can call UART_printf/scanFmt API for read/write
-operation
-
-3. UART_stdioInit2() using Application specified UART parameters
-
-::
-
-    ...
-    Board_init(boardCfg);
-    ...
-    UART_socGetInitCfg(UART_INSTANCE, &uart_cfg);
-    ...
-    UART_socSetInitCfg(UART_INSTANCE, &uart_cfg);
-    ...
-    UART_Params_init(&params);
-    ...
-    UART_stdioInit2(UART_INSTANCE, &params);
-
-At this point UART driver is ready for data transfer on specific
-instance. Application can call UART_printf/scanFmt API for read/write
-operation
-
-.. rubric:: Read/Write APIs
-   :name: readwrite-apis
-
-**Interrupt**:
-
-::
-
-    UART_read(handle,scanPrompt, sizeof(scanPrompt));/* Read API */
-    ...
-    UART_write(handle, bufferPrompt, sizeof(bufferPrompt));/* Write API */
-
-    Or
-
-    UART_transactionInit(&transaction);
-    transaction.buf = (void *)scanPrompt;
-    transaction.count = sizeof(scanPrompt);
-    UART_read2(uart, &transaction);
-    ...
-    UART_transactionInit(&transaction);
-    transaction.buf = (void *)bufferPrompt;
-    transaction.count = sizeof(bufferPrompt);
-    UART_write2(uart, &transaction);
-
-**Polling**:
-
-::
-
-    UART_readPolling(handle,scanPrompt, sizeof(scanPrompt));/* Read Polling mode API */
-    ...
-    UART_writePolling(handle, bufferPrompt, sizeof(bufferPrompt));/* Write Polling API */
-
-.. rubric:: DMA Usage :
-   :name: dma-usage
-
-UART driver supports DMA operations to transfer data between
-
--  Memory and RX FIFO for read transfer
--  Memory and TX FIFO for write transfer.
-
-DMA Driver is DMA family IP (EDMA and UDMA) and UART IP (V0 and V1) specific.
-Refer soc/dma/v#/UART_dma.c for these operations. Application need to
-create DMA handle and update the configuration before UART_init() API.
-
-::
-
-    uartInitCfg[UART_INSTANCE].edmaHandle = UartApp_edmaInit();/* For AM/K1/K2 devices */
-
-    or
-
-    uartInitCfg[UART_INSTANCE].udmaHandle = UartApp_udmaInit();/* For K3 devices */
-
-    UART_init();
-
-Refer “UART_BasicExample_[SOC]_[cpu]DMATestproject” or "UART_DMA_[evm]_[cpu]TestApp"
-for additional reference. Refer SDK Release Note for supported EVMs.
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-------------------------+---------------------+---------------------+---------------------+---------------------+
-|         Name            |    Description      |  Expected Results   | SoC Supported       | Build Type          |
-+=========================+=====================+=====================+=====================+=====================+
-| UART_Example            | Example             | Application prompts |    AM335x,          | CCS project         |
-| application             | demonstrating       | user to enter input |    AM437x,          |                     |
-|                         | *simple* UART use   | data in console.    |    AM571x,          |                     |
-|                         | case. Reference     |                     |    AM572x,          |                     |
-|                         | example for         | User can enter up   |    AM574x,          |                     |
-|                         | developers          | to 16 characters or |    k2g,             |                     |
-|                         |                     | terminate with      |    k2hk,k2l,k2e,k2l |                     |
-|                         |                     | enter               |    c6657,c6678      |                     |
-|                         |                     | key.Application     |    omapl137,        |                     |
-|                         |                     | echoes back         |    omapl138,        |                     |
-|                         |                     | characters.         |                     |                     |
-+-------------------------+---------------------+---------------------+---------------------+---------------------+
-| UART_TestApplication    | Unit Test           | User can enter up to| AM335x,AM437x,AM571x| CCS project         |
-|                         | application to test | 16 characters using | AM572x,AM574X       |                     |
-|                         | all APIs            | serial              | k2g,k2hk,k2l,k2e,k2l|                     |
-|                         |                     | console.Application | c6657,c6678         |                     |
-|                         |                     | echoes back         | omapl137,omapl138   |                     |
-|                         |                     |                     +---------------------+---------------------+
-|                         |                     |                     | am65xx,j721e        | makefile            |
-+-------------------------+---------------------+---------------------+---------------------+---------------------+
-| UART_DMATestApplication | Unit Test           | User can enter up to| AM335x,AM437x,AM571x| CCS project         |
-|                         | application with    | 16 characters using | AM572x,AM574X       |                     |
-|                         | DMA mode.           | serial              | k2g,k2hk,k2l,k2e,k2l|                     |
-|                         |                     | console.Application | c6657,c6678         |                     |
-|                         |                     | echoes back         | omapl137,omapl138   |                     |
-|                         |                     |                     +---------------------+---------------------+
-|                         |                     |                     | am65xx,j721e        | makefile            |
-+-------------------------+---------------------+---------------------+---------------------+---------------------+
-| UART_SMP_TestApplication| Unit Test           | User can enter up to| AM572x-EVM          | CCS project         |
-|                         | application to test | 16 characters using |                     |                     |
-|                         | all APIs in SMP mode| serial              |                     |                     |
-|                         | *(A15 & A53 cores)* | console.Application |                     |                     |
-|                         |                     | echoes back         |                     |                     |
-|                         |                     |                     +---------------------+---------------------+
-|                         |                     |                     | am65xx,j721e        | makefile            |
-+-------------------------+---------------------+---------------------+---------------------+---------------------+
-| UART_SMP_DMATestApplica | Unit Test           | User can enter up to| AM572x-EVM          | CCS project         |
-| tion                    | application         | 16 characters using |                     |                     |
-|                         | in SMP mode with DMA| serial              |                     |                     |
-|                         | enabled             | console.Application |                     |                     |
-|                         | *(A15 & A53 cores)* | echoes back         |                     |                     |
-|                         |                     |                     +---------------------+---------------------+
-|                         |                     |                     | am65xx,j721e        | makefile            |
-+-------------------------+---------------------+---------------------+---------------------+---------------------+
-
-Building UART examples
-----------------------
-
--  Makefile based examples and dependent libraries can be built from the top level or module level UART makefile, refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__  for details of how to setup the build environment. Once you have setup the build environment, issue the following commands:
-::
-
-   To build and clean libs/apps from top-level makefile:
-   cd <pdk>/packages
-   make uart
-   make uart_clean
-
-   To build and clean libs/apps from module-level makefile:
-   cd <pdk>/packages/ti/drv/uart
-   make all
-   make clean
-
-
--  RTSC CCS project based examples are built from CCS
-::
-
-   cd <pdk>/packages
-   ./pdkProjectCreate.sh [soc] [board] [endian] uart [project type] [processor] [SECUREMODE=<yes/no>]
-   Import and build CCS Project from  <pdk>/packages/MyExampleProjects/
-
-
-Additional References
----------------------
-
-+----------------------+-----------------------------------+
-|     **Document**     |           **Location**            |
-+----------------------+-----------------------------------+
-| API Reference Manual | $(TI_PDK_INSTALL_DIR)/packages/ti |
-|                      | /drv/gpio/docs/doxygen/html/index |
-|                      | .html                             |
-+----------------------+-----------------------------------+
-| Release Notes        | $(TI_PDK_INSTALL_DIR)/packages/ti |
-|                      | /drv/gpio/docs/ReleaseNotes_UART  |
-|                      | _LLD.pdf                          |
-+----------------------+-----------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_UDMA.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_UDMA.rst
deleted file mode 100644
index 20c99a59e..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_UDMA.rst
+++ /dev/null
@@ -1,216 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_UDMA
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-The DMA architecture specifies the data structures used by standard communications
-modules to facilitate direct memory access (DMA) and to provide a consistent application programming
-interface (API) to the host software in multi-core devices. The data structures and the API used to
-manipulate them will be jointly referred to as NAVSS.
-For more information on NAVSS DMA architecture, refer to the device Technical Reference Manual
-
-The UDMA driver provides API to program the DMA portion of the NAVSS subsystem
-to setup and initiate transfers. Below are the high level features supported by the driver
-
--  Both Main and MCU NAVSS instances
--  Supports all DMA operations from both instances from all the cores in the SOC
--  UDMAP block copy using native NAVSS channels
--  DRU block copy using direct TR submission to DRU register
--  DRU block copy using indirect (PSIL) TR submission to UDMA external channels
--  PDMA module to initiate transfers to/from PDMA peripherals like UART, McASP, McSPI, ADC, MCAN
--  DMA transfer to/from from native PSIL peripherals like EMAC, CPSW, SA2UL
--  Event and interrupt management like DMA completion, channel chaining, interrupt sharing using IA
--  Resources management across instances and cores for UDMAP DMA channels,RX flow, External UTC channel (DRU), interrupt aggregators (IA), interrupt routers (IR),global events, ring accelerators (RA)
--  Interaction with DMSC RM module via SCICLIENT for all non-RealTime (NRT) configuration
--  Supports both TI-RTOS and baremetal
-
-**Notes**
-
--  UDMA driver doesn't manage/allocate the descriptor and RA memory.The caller need to allocate and provide the required memory.
--  UDMA driver doesn't use any global variables. All the required object memory like channel, driver instance, event etc should be allocated by the caller
-
-This document has detailed API description that user can use
-to make use of the UDMA driver.
-
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **UDMA Configuration Structure**
-   :name: udma-configuration-structure
-
-For details about individual fields of UDMA library structure, see the
-Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\udma\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-The UDMA driver API can be broadly divided into the following categories
-
--  UDMAP native channel API
--  DRU (External UTC) channel API
--  PDMA channel operations
--  Event and interrupt API
--  Ring API
-
-In addition to above drivers the UDMA package also includes many sample
-examples which show how to use the drivers in different ways. Many of
-these sample examples use a common set of APIs which a user may find
-useful to refer to for use in their final application.
-
-API reference for application:
-
-::
-
-    #include <ti/drv/udma/udma.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | | Description         | | Expected Results    |
-+=======================+=======================+=======================+
-| UDMA ADC RX           | | This performs PDMA  | | The application     |
-| application           |   RX data capture     |   checks the ADC      |
-|                       |   from ADC. ADC is    |   channel ID and      |
-|                       |   configured in       |   prints pass on      |
-|                       |   single shot mode    |   successful          |
-|                       |   and captures        |   completion          |
-|                       |   APP_ADC_NUM_CH      |                       |
-|                       |   channel of ADC      |                       |
-|                       |   data. The FIFO is   |                       |
-|                       |   configured to       |                       |
-|                       |   generate a DMA      |                       |
-|                       |   trigger after       |                       |
-|                       |   all channel data    |                       |
-|                       |   is captured         |                       |
-+-----------------------+-----------------------+-----------------------+
-| UDMA Chaining         | | UDMA chaining       | | The application     |
-| application           |   sample application  |   checks the          |
-|                       |   performing a chain  |   destination buffer  |
-|                       |   of block copy using |   with source buffer  |
-|                       |   channel global      |   and prints pass on  |
-|                       |   trigger: CH0 -> CH1 |   successful          |
-|                       |   -> ... -> CHx.      |   completion          |
-|                       |   The first channel   |                       |
-|                       |   doesn't user a      |                       |
-|                       |   global trigger and  |                       |
-|                       |   each channel        |                       |
-|                       |   triggers the next   |                       |
-|                       |   channel's global    |                       |
-|                       |   trigger through     |                       |
-|                       |   the channel's TR    |                       |
-|                       |   event register.     |                       |
-|                       |   A channel's source  |                       |
-|                       |   buffer is previous  |                       |
-|                       |   channel destination |                       |
-|                       |   buffer. This        |                       |
-|                       |   ensures that        |                       |
-|                       |   chaining trigger    |                       |
-|                       |   worked in a         |                       |
-|                       |   synchronized manner |                       |
-|                       |   when the memory     |                       |
-|                       |   compare matches     |                       |
-+-----------------------+-----------------------+-----------------------+
-| UDMA CRC              | | This performs       | | The application     |
-| application           |   UDMA CRC operation  |   checks the          |
-|                       |                       |   calculated CRC      |
-|                       |                       |   value with          |
-|                       |                       |   pre-calculated CRC  |
-|                       |                       |   value and prints    |
-|                       |                       |   pass on successful  |
-|                       |                       |   completion          |
-|                       |                       |                       |
-|                       |                       |                       |
-|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-| UDMA Direct TR DRU    | | UDMA DRU memcpy     | | The application     |
-| application           |   sample application  |   checks the          |
-|                       |   performing block    |   destination buffer  |
-|                       |   copy using direct   |   with source buffer  |
-|                       |   TR submission via   |   and prints pass on  |
-|                       |   DRU registers       |   successful          |
-|                       |                       |   completion          |
-+-----------------------+-----------------------+-----------------------+
-| UDMA In-Direct TR DRU | | UDMA DRU memory     | | The application     |
-| application           |   copy sample         |   checks the          |
-|                       |   application         |   destination buffer  |
-|                       |   performing block    |   with source buffer  |
-|                       |   copy using Type 15  |   and prints pass on  |
-|                       |   Transfer Record     |   successful          |
-|                       |   (TR15) using        |   completion          |
-|                       |   Transfer Record     |                       |
-|                       |   Packet Descriptor   |                       |
-|                       |   (TRPD)              |                       |
-|                       |   for developers.     |                       |
-+-----------------------+-----------------------+-----------------------+
-| UDMA Blockcopy        | | UDMA memory copy    | | The application     |
-| application           |   sample              |   checks the          |
-|                       |   application         |   destination buffer  |
-|                       |   performing block    |   with source buffer  |
-|                       |   copy using Type 15  |   and prints pass on  |
-|                       |   Transfer Record     |   successful          |
-|                       |   (TR15) using        |   completion          |
-|                       |   Transfer Record     |                       |
-|                       |   Packet Descriptor   |                       |
-|                       |   (TRPD)              |                       |
-+-----------------------+-----------------------+-----------------------+
-
-
-
-
-
-
-Additional References
----------------------
-
-+-----------------------------------+------------------------------------------------------------+
-| **Document**                      | **Location**                                               |
-+-----------------------------------+------------------------------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti                        |
-|                                   | \\drv\\udma\\docs\\doxygen\\html\\                         |
-|                                   | index.html                                                 |
-+-----------------------------------+------------------------------------------------------------+
-| Migration Guide: EDMA to UDMA     | $(TI_PDK_INSTALL_DIR)\\packages\\ti\\drv\\udma\\docs\\     |
-|                                   | Migrating_Applications_from_EDMA_to_UDMA_using_TI-RTOS.pdf |
-|                                   |                                                            |
-+-----------------------------------+------------------------------------------------------------+
-
-Building UDMA examples
-----------------------
-
--  UDMA examples and dependent libraries are built from the top level udma
-   makefile
--  cd <pdk>/packages/ti/drv/udma
--  To build: make -s PDK_INSTALL_PATH=<pdk>/packages
--  To clean: make -s clean PDK_INSTALL_PATH=<pdk>/packages
-
-UDMA examples
--------------
-
-.. rubric::  *Description*
-   :name: description
-
-UDMA examples demonstrates the key features of the driver.
-
-|
-
-.. rubric::  **Running the UDMA examples**
-   :name: running-the-udma-examples
-
-**CCS connection**:
-
--  Load the System firmware as specified in SCICLIENT documentation
--  Load the generated executable file in CCS
--  Run the application.
--  The application print will be displayed on the CCS and UART console. The UART console used depends on the core in which the application is run.
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_USB.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_USB.rst
deleted file mode 100644
index 714eb296b..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_USB.rst
+++ /dev/null
@@ -1,500 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_USB
-
-Overview
---------
-
-Driver Overview
-^^^^^^^^^^^^^^^
-
-PDK USB driver (USB LLD) provides the following USB class/functions
-while isolating application from the complexity of low level USB and USB
-class protocols:
-
--  USB device Mass Storage Class
--  USB host Mass Storage Class
--  USB device Audio Class
--  USB generic bulk device class
-
-In rest of the page AM437x EVM is being refered as an example. Please
-check Release Notes for list of supported EVMs for driver.
-
-.. rubric:: Modes of Operation
-   :name: modes-of-operation
-
--  **USB device Mass Storage Class**
-
-   -  **USB device Mass Storage Class with RAM DISK**
-
-In this mode, a user-selected USB instance of the EVM will be working in
-device mode and will behave like a USB thumb drive. It uses part of the
-EVM DDR memory and exposes it as a physical storage for another USB host
-application. After the host PC enumerates this EVM-thumb drive, the PC
-will see a USB storage device. This EVM-thumb drive is not yet formatted
-with any file system and requires user to format it before use.
-
-.. Image:: /images/USB_MSC_device.PNG
-
-The following screen shots show what one would expect when running the
-device mode demo application and plugging in a USB cable from the EVM
-USB port #0 to a PC running Windows
-
-Printout from demo application:
-
-.. Image:: /images/Device_mode_printout.png
-
-The MSC device is detected in Windows, and a FAT formatted USB drive
-named "PDK-USBDEV" should be seen in the "Window Explorer". The content
-of the drive is just a readme.txt file. This USB drive can be
-manipulated like any other removable USB drive.
-
-.. Image:: /images/Windows_pdk_usb.png
-
-Windows might show a message saying it should be scanned and fixed. We
-can just ignore it and just continue without scanning.
-
-|
-
-   -  **USB device Mass Storage Class with MMCSD card**
-
-This example acts like a USB - MMCSD card reader. The example exposes
-the EVM's MMCSD card to the Host PC via USB MSC. The Host PC can
-manipulate files on the attached MMCSD card on the EVM. This is how it looks.
-Its code is similar to that of the USB device MSC example but with the call back
-functions calling MMCSD API's instead of RamDisk APIs
-
-.. Image:: /images/Usb_device_mmcsd.PNG
-
-|
-
--  **USB host Mass Storage Class**
-
-In this mode, the USB instance will act as a USB host communicating with
-a USB device that supports Mass Storage Class function (USB thumb drive
-or a small USB hard drive). The demo example code utilizes a shell
-interface via the EVM via UART for interaction with the example. The
-shell provides some basic commands to manipulate the content of the
-attached USB disk drive.
-
-.. Image:: /images/USB_MSC_host.PNG
-
-|
-
-Screenshot of a MSC host mode example running in RTOS after plugging in
-a USB thumb drive into USB port #1
-
-.. Image:: /images/Host_shell_screen_shot.png
-
-|
-
--  **USB device Audio Class**
-
-In this mode, USB instance of the EVM will be working in device mode and
-will behave like a USB headset with MIC. It uses audio codec on the EVM
-for running playback and record initiated by the USB host. McASP module
-will be used to transfer the data between USB device and audio codec on
-the board. EVM will appear as a new USB audio device on the host PC.
-Changing the default audio device on the host PC to EVM USB device will
-allow the playback and record operations between EVM and USB host. This
-mode of operation is currently supported on AM335X GP EVM, OMAP-L137 EVM
-and OMAP-L138 LCDK.
-
-|
-.. Image:: /images/Am335x_usb_ac_bd.jpg
-
-|
-
--  **USB generic bulk device class**
-
-In this mode, a user-selected USB instance of the EVM will be working in
-device mode. The mentioned USB device will show up in the host PC as a generic
-USB bulk device with one single interface containing a bulk IN and a bulk OUT
-endpoints. The configuration and interface descriptors published by the device
-contain vendor-specific class identifiers, so an application on the host will
-have to communicate with the device using either a custom driver or a subsystem
-such as WinUSB or libusb-win32 on Windows (or just libusb on Linux) to read and
-write to the device.
-
-
-   -  **Running USB bulk device demo application**
-
-The bulk demo application requires a host PC with USB host plugged to the USB device
-port on the EVM. Depending on the platform, the USB device port might be USB port #0
-or #1.
-
-.. Image:: /images/USB_MSC_device.PNG
-
-Please refer to PDK user guide for how to generate USB example projects. Once the demo
-application is loaded and run, the EVM UART console shows the following:
-
-.. Image:: /images/usb_dev_bulk_console.png
-
-A Python host PC example application is provided in
-ti/drv/usb/example/usb_dev/bulk/usb_dev_bulk_host_application.py
-
-|
-
-The example Python script requires PyUSB to run. On Linux host, proper UDEV rule is
-also required in order to access the USB bulk device as non-sudo user.  The script
-itself also lists the requirements to run it as well as what command options available.
-The example UDEV rule is also placed in the same place where the Python script is located.
-It does the following:
-
-- The Python script looks for the USB device with the example PID:VID,
-- Sends an ASCII text string to the USB bulk demo application running on the EVM
-- Expects the same text string with reversed case letter returned back, and also
-- Verifies the received data with the data that it has sent and report the test result.
-
-A screen shot of what the Python test script outputs
-
-.. Image:: /images/usb_dev_bulk_host_tool_output.png
-
-The USB bulk demo application configures the USB endpoints as high speed endpoints with 512B packet size.
-
-|
-|
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
--  **Data Structures**:
-
-   -  **tUSBDMSCDevice**: Defined in usbdmsc.h. It is used in USB device
-      mode application. This structure must be filled with the intended
-      vendor and product ID as well as other product information and
-      also the function pointers to functions that handle the disk
-      functions (open/read/write/close, etc.). These product information
-      will show up in the device and interface USB descriptors that are
-      used during device enumeration. This device MSC class data is then
-      assigned to the field usbClassData of the USB_Params bellow.
-   -  **USB params**: USB_Params structure is declared in usb_drv.h.
-      This structure must be provided to the USB driver. It must be
-      initialized before the USB_open() function is called.
-   -  **USB APIs**: main USB LLD and USB MSC API’s are declared in
-      usb_drv.h and usbdmsc.h and usbhmsc.h provided in the root USB LLD
-      directory.
-
-|
-
--  **General USB LLD expectations**:
-
-The USB LLD will setup appropriate USB clock and power domains for the
-particular SOC being in used as part of its “device specific peripheral”
-functions.
-
-After the USB_open() is called, the driver expects the application code
-to sets up USB interrupts with the interrupt handler being the USB LLD
-provided interrupt handler. Then the application have to call the USB
-LLD provided API USB_irqConfig() which enables USB module’s interrupts.
-In device mode, both USB core and USB misc interrupts are used in the
-USB device MSC application. In host mode, the USB host MSC only uses USB
-core interrupts.
-
-After these steps, application code then can expect to have USB
-enumeration done and start USB transfer through the provided APIs.
-
-Then handle reset function is called for the reconnecting of usb ,
-and Usb_close() is called to disconnect the handle and it is called in
-USB device bulk application.
-
-API Call Flow
-^^^^^^^^^^^^^
-
--  **USB Device MSC**
-
-The example application code uses the USB library, configures it as a
-USB device with MSC function. The example also provides functional codes
-that access a RAM disk (included from the Utils library in the included
-Starterware). The LLD calls these MSC back-ends functions to access the
-RAM disk. User can replace these functions with other functions that
-access other types of media or devices (MMCSD for example). The RAM disk
-image provided in the example demo application is not currently
-formatted. Thus the once enumerated, the PC will require the USB disc to
-be formatted before use.
-
-Below diagram is the sequence of API calls that starts the USB device
-MSC application. All USB events are handled internally in the LLD and in
-the interrupt context.
-
-.. Image:: /images/USB_MSC_device_API_flow.PNG
-
-User provided disk functions will be called from the LLD to handle the
-actual physical disk access. The overview of USB Device MSC example
-application:
-
-.. Image:: /images/USB_MSC_device_example_blocks.PNG
-
-The content of the file: usb_msc_structs.c can be replaced with customer
-USB device information (PID/VID, device names, etc.)
-
--  **USB Host MSC**
-
-The LLD also provides a USB host MSC example. The USB LLD is acting as a
-USB host, waiting for a USB thumb drive/memory stick to be plugged in. A
-console with a simple shell command is also provided so that the demo
-example can display and manipulate content of the USB device.
-
-The following is how the USB host MSC example demo is organized:
-
-.. Image:: /images/USB_MSC_host_example_blocks.PNG
-
-The following is the sequence of the APIs that were used:
-
-.. Image:: /images/USB_MSC_host_API_flow.PNG
-
-|
-
--  **USB Device Audio**
-
-The example application code uses the USB library, configures it as a
-USB device with Audio class function. USB LLD along with the application
-enumerates as the USB audio class device and allows accessing the audio
-ports on the EVM from USB host. It supports audio playback and record
-operations.
-
-Below diagram is the sequence of API calls that starts the USB device
-audio application. All USB events are handled internally in the LLD and
-in the interrupt context.
-
-.. Image:: /images/USB_Audio_class_flowchart.jpg
-
-
-|
-
--  **USB Device Bulk**
-
-Sequence of API calls as long as what the example application looks like are
-described bellow
-
-.. Image:: /images/usb_device_generic_bulk_example_application.png
-
-- Main APIs that are used to read/write from and to the USB bulk device are USBD_bulkRead() and USBD_bulkWrite().
-These two functions will block the caller until they finish their operation.
-
-- The main application should wait for about 500ms after the USB host sends the SetConfig request to make sure that the enumeration is completely finished before calling USBD_bulkRead/Write functions
-
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-Examples are CCS projects. Generated with pdkProjectCreate scripts.
-Please refer  `Processor SDK RTOS Getting Started Guide <index_overview.html#pdk-example-and-test-project-creation>`__
-for how to create and build examples projects
-
-+-----------------------+-----------------------+-----------------------+
-| Example Name          | EVM's supported       |                       |
-|                       |                       | Notes                 |
-+=======================+=======================+=======================+
-| **USB_DevMsc_mmcsd**  | AM335GP EVM,          | eMMC is used on AM572 |
-|                       | BeagleBoneBlack,      | and BealgeBoneBlack   |
-|                       | AM572 EVM,            | examples              |
-|                       |                       | This example can be   |
-|                       |                       | used to format eMMC,  |
-|                       |                       | just like any other   |
-|                       |                       | USB storage device    |
-+-----------------------+-----------------------+-----------------------+
-| **USB_DevMsc_mmcsd**  | AM572xIDK,            | SD card is used as    |
-|                       | AM574IDK,             | storage media for     |
-|                       | AM571IDK              | USB MSC application   |
-|                       |                       | Insert a SD card into |
-|                       |                       | the board while       |
-|                       |                       | running the example.  |
-+-----------------------+-----------------------+-----------------------+
-| **USB_DevMsc**        | AM335GP, AM437xGP,    | OMAPL13 LCDK host and |
-|                       | OMAP137EVM,           | device examples share |
-|                       | OMAPL138LCDK,         | the same USB port.    |
-|                       | AM57xIDK, AM572 EVM,  |                       |
-|                       | K2G EVM, DRA7xx EVM,  |                       |
-|                       | AM65x EVM/IDK         |                       |
-|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-|  **USB_HostMsc**      | AM335GP, AM437xGP,    | OMAPL13 LCDK host and |
-|                       | OMAP136EVM,           | device examples share |
-|                       | OMAPL137LCDK,         | the same USB port.    |
-|                       | AM57xIDK, K2G EVM,    | Need OTG cable for    |
-|                       | DRA7xx EVM,           | EVM with OTG port to  |
-|                       | AM65x EVM/IDK         | work in host mode.    |
-|                       |                       |                       |
-|                       |                       | USB3.0 host supported |
-|                       |                       | on AM572IDK.          |
-+-----------------------+-----------------------+-----------------------+
-| **USB_DevAudio**      | AM335xGP,OMAPL137     | Refer to Hardware     |
-|                       | EVM,OMAPL138 LCDK     | Setup and How to Run  |
-|                       |                       | the Demo sections     |
-|                       |                       | below                 |
-+-----------------------+-----------------------+-----------------------+
-| **USB_DevBulk**       | AM335xGP, AM437xGP,   | Verifies USB device   |
-|                       | AM572xIDK, AM571xIDK, | operation in bulk mode|
-|                       | AM574xIDK, K2GEVM,    | Host trasactions are  |
-|                       | OMAPL137EVM,          | invoked using Python  |
-|                       | OMAP138LCDK,          | scripts provided as   |
-|                       | AM654x EVM/IDK        | part of the example.  |
-|                       |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-
-
-
-Test Application
-^^^^^^^^^^^^^^^^
-
-USB test applications are built using makefile. Some of the test application are
-RTOS/BIOS apps, other are bare metal apps. They are replica of the USB examples but built by
-makefile instead of CCS projects.
-
-Refer to the `Processor SDK RTOS Getting Started Guide <index_overview.html#setup-environment>`__
-for details  of how to setup the build environment. Once you have setup the build environment,
-issue the following commands:
-
-- cd <pdk>/packages/
-
-- To build: make usb
-
-- To clean: make usb_clean
-
-- Test applications are then under (TI_PDK_INSTALL_DIR)/packages/ti/binary/
-
-+-----------------------------------+-----------------------+-------+---------------------------------+
-| Test App Name                     | EVM's supported       | Bare  |                                 |
-|                                   |                       | metal | Notes                           |
-+===================================+=======================+=======+=================================+
-| **USB_Baremetal_DevMsc_TestApp**  |  AM65xx EVM/IDK       |  yes  | Equivalent to DevMsc example    |
-+-----------------------------------+-----------------------+-------+---------------------------------+
-| **USB_Baremetal_HostMsc_TestApp** |   AM654x EVM/IDK      |  yes  | Same function as HostMsc example|
-+-----------------------------------+-----------------------+-------+---------------------------------+
-| **USB_HostMsc_TestApp**           |   AM654x EVM/IDK      |  no   | Same as HostMsc example         |
-+-----------------------------------+-----------------------+-------+---------------------------------+
-| **USB_DevMsc_TestApp**            |   AM654x EVM/IDK      |  no   | Same as DevMsc example          |
-+-----------------------------------+-----------------------+-------+---------------------------------+
-| **USB_DevBulk_TestApp**           |   AM654x EVM/IDK      |  no   | Same as DevBulk example         |
-+-----------------------------------+-----------------------+-------+---------------------------------+
-|                                   |                       |       | Same as USB DevMsc example.     |
-|                                   |                       |       |                                 |
-| **usb_d_msc_<platform>**          | AM335xGP,AM437xEVM    |       | Build by going to               |
-|                                   | OMAPL137 EVM          |  yes  | example/usb_dev/msc/            |
-|                                   | OMAPL138 LCDK         |       | build/<platform>                |
-|                                   |                       |       |                                 |
-+-----------------------------------+-----------------------+-------+---------------------------------+
-|                                   |                       |       |                                 |
-|                                   |                       |       | Same as USB HostMsc example     |
-|                                   |                       |       |                                 |
-| **usb_h_msc_<platform>**          | AM335xGP,AM437xEVM    |       | Build by going to               |
-|                                   | OMAPL137 EVM          |  yes  | example/usb_dev/msc/            |
-|                                   | OMAPL138 LCDK         |       | build/<platform>                |
-|                                   |                       |       |                                 |
-+-----------------------------------+-----------------------+-------+---------------------------------+
-
-
-Both examples and test applications can be loaded and run on their intended EVM via
-  	-  CCS JTAG connector, or
-  	-  Via SBL: the "app" file under CCS project's debug directory (<PDK_INSTALL_PATH/MyExampleProjects/<ExampleProjectDirectory>/Debug>) is SBL loadable file of the built project.
-   	--  Project Memory layout must be considered and following SBL guideline so that examples can run safely via SBL. Please refer to `SBL Component <index_Foundational_Components.html#boot>`__   for more detail
-
-
-
-Benchmark tool
---------------
-
-USB host MSC
-^^^^^^^^^^^^
-    - To measure the USB host MSC throughput, a new command (bm) is added into the USB host mode example (or test application).
-    - This command is to run with a good known fast USB thumb drive attached to the USB host port.
-    - The throughput measurement result varies greatly depends on which USB device is plugged in and which filesystem is used
-    - The USB drive needs to be formated as FAT32 (since the USB host example only supports FAT filesystem) and has at least 100MB free space. Fast blank USB thumb drive is recomended.
-    - The command, when run, writes a 100MB file into the thumb drive and measures the time it takes to do so. It then reads back this 100MB file with time measurement to find the read throughput.
-    - The write and read are done in block size of 100KB, 256KB, 1MB, and 5MB. It prints throughput measurements for each of these blocks.
-    - This command is only supported in AM65xx at the moment.
-    - Syntax:
-
-::
-
-            bm <test_file_name>
-
-
-USB device MSC
-^^^^^^^^^^^^^^
-    - To measure USB device MSC throughtput a simple linux shell script usb_dev_msc_perf.sh is provided in PDK/packages/ti/drv/usb/example/usb_dev/msc/
-    - This script assumes the USB Dev MSC drive (PDK-USBDEV) is already mounted on the Linux host PC (under /media/$USER/PDK-USBDEV) when it runs
-    - It uses "dd" command to report the thoughput
-    - Tested on Ubuntu 16.04. Different version of Linux might mount the MSC drive at different place. Please adjust the script accordingly.
-    - The script writes a file to the PDK-USBDEV drive with a number of blocksize. By default it creates a 15MB test file by writing 150 blocks of 100K each (which would fit inside the 16MB RAM disk provided by the USB Dev MSC.)
-    - User is free to change the block size and number of blocks for the test. However it doens't check if the end result file would fit the PDK-USBDEV drive or not.
-    - Syntax:
-
-::
-
-         usb_dev_msc_perf.sh [<blocksize> <count>]
-
-
-
-Hardware Setup
---------------
-
-This section provides the specific HW setup required to run the USB
-examples.
-
-|
-
--  **USB Device Audio**
-
-USB audio class demo requires additional setup for running playback and
-record operations. Below sections provide the setup details for each
-platform supported.
-
-|
-
-**AM335x GP EVM**
-
-.. Image:: /images/Am335x_usb_ac_setup.jpg
-
-**OMAPL137 EVM**
-
-.. Image:: /images/Omapl137_usb_ac_setup.jpg
-
-**OMAPL138 LCDK**
-
-.. Image:: /images/Omapl138_usb_ac_setup.jpg
-
-**How to Run the Demo**
-
--  Follow this link `Processor SDK RTOS Setup CCS <How_to_Guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__
-   to get target configuration setup correctly.
--  Use CCS to import the USB_DevAudio_<board>_<core>ExampleProject under
-   pdk_<platform>_<version>/packages/MyExampleProjects.
--  Build the imported project. the OUT file will be at
-   pdk_<platform>_<version>/packages/MyExampleProjects/USB_DevAudio_<board>_<core>ExampleProject/Debug.
--  Make the HW connections as shown in `Hardware
-   Setup <index_device_drv.html#hardware-setup>`__ section
--  Launch the target configuration for the EVM from CCS 7.x.
--  Connect to ARM or DSP core as applicable.
--  Load the
-   pdk_<platform>_<version>/packages/MyExampleProjects/USB_DevAudio_<board>_<core>ExampleProject/Debug/USB_DevAudio_<board>_armExampleProject.out.
--  Run the program (loaded previously) by pressing F8
--  The CCS ConsoleIO will display the following:
-
-.. Image:: /images/CCS_console_output.png
-
--  Right click on the "Speaker Icon" on the USB Host (right side of the
-   toolbar), then select "Playback devices"
--  Wait until the "Speakers USB Audio Device" shows up in the "Sound"
-   dialog
-
-.. Image:: /images/Sound.png
-
--  Select the "Speakers USB Audio Device" in the "Sound" dialog, then
-   click the "Configure"
-.. Image:: /images/Speaker_setup.png
-
--  Click the "Test" in "Speaker Setup", you should hear the testing tone
-   in the headphone connected to the EVM
-
-.. note::
-
-   'board' can be evmAM335x, evmOMAPL137 or lcdkOMAPL138
-
-   'core' can be arm or c674x
-
diff --git a/source/rtos/PDK_Platform_Software/Device_Drivers/_VPS_Drivers.rst b/source/rtos/PDK_Platform_Software/Device_Drivers/_VPS_Drivers.rst
deleted file mode 100644
index d43503607..000000000
--- a/source/rtos/PDK_Platform_Software/Device_Drivers/_VPS_Drivers.rst
+++ /dev/null
@@ -1,389 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_VPS_DRIVERS
-
-Overview
---------
-
-Introduction
-^^^^^^^^^^^^
-
-VPS (Video Processing SubSystem) video Drivers allow users to make use
-of all video hardware features like 1080P capture, HDMI/LCD/SDTV
-display, deinterlacing, scaling. A user can use the drivers in many
-different ways like multi-channel capture, memory to memory processing,
-display and so on. This document has detailed API description that
-user's can use to make use of the VPS drivers.
-
-VPS consists of following modules
-
--  Video Input Port (VIP) - for video capture functions for the device
--  Video Processing Engine (VPE)- for video operations such as color
-   space convertion, deinterlacing, scaling and chroma upsampling
-   features.
--  Display SubSystem (DSS) - for LCD outputs on three parallel
-   interfaces (DPI1, DPI2, and DPI3) and HDMI
-
-User Interface
---------------
-
-Driver Configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All board specific configurations eg:enabling clock and pin-mux for
-UART/display/vip pins are required before calling any driver APIs. The
-board specific configurations are implemented under
-<pdk>/ti/drv/vps/src/boards/src folder.
-
-.. rubric::  **VPS Configuration Structure**
-   :name: vps-configuration-structure
-
-For details about individual fields of VPS library structure, see the
-Doxygen help by opening
-PDK_INSTALL_DIR\\packages\\ti\\drv\\vps\\docs\\doxygen\\html\\index.html.
-
-APIs
-^^^^^
-
-The VPS driver API can be broadly divided into the following categories
-
--  FVID2 API - API used to create, control and use the different VPS
-   drivers
--  VPS (Video Processing Sub-system) API - API for all video drivers
--  VPS Control Driver API
--  VPS Capture API - API for video capture drivers
--  VPS VIP Capture API - API specific to VIP capture driver
--  VPS DSSWB Capture API - API specific to DSS WB capture driver
--  VPS Display API - API for video display drivers
--  VPS Display Controller API - API for controlling and configuring
-   VENCs in the display subsystem
--  VPS Memory to Memory (M2M) API - API for memory to memory drivers
--  M2M VPE API - API specific to VPE M2M driver
--  External Device API - API for controlling external video devices like
-   video decoders, video encoders, video filters, IO expanders,
-   Ultra-sonic sensors
--  Platform Specific API - API for platform/board specific control, like
-   setting pin muxes, clocks etc
--  Board Specific API - API for board specific features.
-
-In addition to above drivers the VPS package also includes many sample
-examples which show how to use the drivers in different ways. Many of
-these sample examples use a common set of APIs which a user may find
-useful to refer to for use in their final application.
-
-API reference for application:
-
-::
-
-    #include <ti/drv/vps/include/vps_<func>.h>
-
-Application
-------------
-
-Examples
-^^^^^^^^
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | | Description         | | Expected Results    |
-+=======================+=======================+=======================+
-| Display Dss           | | Example             | | Application prompts |
-| application           |   demonstrating       |   user to select the  |
-|                       |   *simple* display    |   test case input in  |
-|                       |   yuyv or bgr frames  |   CCS console.        |
-|                       |   to the LCD use      |                       |
-|                       |   case. Reference     |                       |
-|                       |   example for         |                       |
-|                       |   developers          |                       |
-+-----------------------+-----------------------+-----------------------+
-| Display Dss           | | Example             | | Application prompts |
-| application (Bare     |   demonstrating       |   user to select the  |
-| Metal)                |   *simple* display    |   test case input in  |
-|                       |   yuyv or bgr frames  |   CCS console.        |
-|                       |   to the LCD use case |                       |
-|                       |   for bare metal use  |                       |
-|                       |   cases. Reference    |                       |
-|                       |   bare metal example  |                       |
-|                       |   for developers      |                       |
-+-----------------------+-----------------------+-----------------------+
-| Display Dss WB        | | Example             | | Application prompts |
-| application           |   demonstrating       |   user to select the  |
-|                       |   *simple* display    |   test case input in  |
-|                       |   Write Back (WB)     |   CCS console.        |
-|                       |   yuyv or bgr frames  |                       |
-|                       |   to the LCD use      |                       |
-|                       |   case. Reference     |                       |
-|                       |   example for         |                       |
-|                       |   developers          |                       |
-+-----------------------+-----------------------+-----------------------+
-| Loopback application  | | Example             | | Application prompts |
-| (Capture and Display  |   demonstrating       |   user to select the  |
-| application)          |   *simple* capture    |   test case input in  |
-|                       |   and display yuyv    |   CCS console, please |
-|                       |   frames from camera  |   select ov2659       |
-|                       |   to the LCD use      |   camera for idkAM57x |
-|                       |   case. Reference     |   and OV1063x for     |
-|                       |   example for         |   evmAM572x test      |
-|                       |   developers          |   cases.              |
-+-----------------------+-----------------------+-----------------------+
-| Loopback application  | | Example             | | Application prompts |
-| Bare metal(Capture    |   demonstrating       |   user to select the  |
-| and Display           |   *simple* capture    |   test case input in  |
-| application)          |   and display yuyv    |   CCS console, please |
-|                       |   frames from camera  |   select ov2659       |
-|                       |   to the LCD use case |   camera for idkAM57x |
-|                       |   for bare metal.     |   and OV1063x for     |
-|                       |   Bare Metal          |   evmAM572x test      |
-|                       |   reference example   |   cases.              |
-|                       |   for developers      |                       |
-+-----------------------+-----------------------+-----------------------+
-
-.. note::
-
-   ::
-
-        * Starting from Processor SDK 4.2 release, idkAM574x support is added for VPS.
-        * Starting from Processor SDK 4.2 release, oV1063x camera part support is added for AM572x - GP evm (older Aptina MT9T11 camera is never supported).
-        * Starting from Processor SDK 3.2 release, osd101t2587 lcd panel is supported (new part) along with osd101t2045 lcd panel (old part) on idkAM572x
-          and idkAM571x boards for all display subsystem examples.
-        * The bare metal examples are added starting from Processor SDK 4.0 release
-        * Some of the clocks such as 32KHz Sync clock are directly tied to A15 core and need that core to be running. Hence while testing the code on other cores
-          such as DSP/IPU, please make sure to disconnect the ARM core after connecting the ARM core & running the GEL files to enable the other cores and before
-          loading the executable on that core.
-
-
-Additional References
----------------------
-
-+-----------------------------------+----------------------------------------+
-| **Document**                      | **Location**                           |
-+-----------------------------------+----------------------------------------+
-| API Reference Manual              | $(TI_PDK_INSTALL_DIR)\\packages\\ti    |
-|                                   | \\drv\\vps\\docs\\doxygen\\html\\index.|
-|                                   | html                                   |
-+-----------------------------------+----------------------------------------+
-
-Building VPS examples
----------------------
-
--  VPS examples and dependent libraries are built from the top level pdk
-   makefile after the environment setup is done using the
-   pdksetupenv.sh(bat) file.
--  cd <pdk>/packages
--  pdksetupenv.bat (sh)
--  make vps  : to build vps examples under **<pdk>/ti/packages/binary**
-   folder
--  make vps_clean : to clean the vps and vps examples.
-
-VPS examples
-------------
-
-Display DSS Example
-^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  *Description*
-   :name: description
-
-The example exploits the DISPC (Display Controller) and LCD/HDMI outputs
-available in the SoC. When run, the test outputs multiple options to
-select between to demonstrate the various capacity of the display
-subsystem. There is also option to select "Auto Run", when selected runs
-all the tests in sequential manner. The example works on outputing a
-pre-loaded video frames of YUV422I and BGR888 formats to DP1, DP2 and
-DP3 parallel interfaces and also to HDMI output observed on TV set, from
-VID1, VID2, VID3 and GFX pipelines. The example also demonstrates
-displaying videos combined from GFX and other VID pipelines to DPI1 LCD
-output. The example is also enhanced to show the display controler
-scaling features. Test that exploits the scalar unit to show all
-possible allowed scaling. Maximum scaling ratio supported is the ratio
-of the dss functional clock / pixel clk. Please refer to section
-"11.2.4.10.4.2 DISPC Scaling limitations" of AM57x Technical Reference
-manual for minimum ratio allowed when using the scalar unit.
-
-|
-
-.. rubric::  **Running the Display DSS example**
-   :name: running-the-display-dss-example
-
-**Configuring Display**:
-
--  Make sure the LCD panel is connected to the base EVM before running
-   the example binary.
--  Make sure the HDMI is connected to TV from the EVM for HDMI display
-   options.
--  For AM571x IDK EVM, installing a shunt on header J51 to short those
-   pins
-
-**CCS connection**:
-
--  Load the generated executable file in CCS
--  Run the application, Select any of the option and load the buffer as
-   suggested.
--  Content will be displayed on the LCD panel or HDMI TV connected to
-   EVM for test options
-
-.. note::
-
-   -  Test Input files for Display Sample application will be in
-      "<pdk>\drv\vps\docs\test_inputs\dss_input_files.rar"
-
-The rar file can be unrar-ed to get the test files using utilities such
-as http://www.7-zip.org Please download the latest version of 7-zip from
-this website. The command to unrar is: 7z x {file_to_unrar}
-
-When the test program expects the yuyv422 file, please load
-**display_yuyv422_prog_packed_1920_1080.tigf** file and when the test
-program expects the bgr888 file, please load
-**display_gbr888_prog_packed_1920_1080.tigf** file. Each video has 4
-frames. Below shows the first frame. If GP EVM is used, only the left
-upper corner of the video is displayed as it only has an 800x480 LCD.
-
-.. Image:: /images/488px-Yuyv422.png
-.. Image:: /images/488px-Gbr888.png
-
-The test runs bunch of test cases as shown in the test example menu.
-
-**Warning** : Due to A15 MMU protection, memory load while CPU is
-running is not possible. Hence below workaround needs to be done for
-loading the test files.
-
-#. Power up the board
-#. Connect to A15 Core
-#. Load both tigf files into memory
-#. Do a CPU reset on A15
-#. Load example code for core type
-#. Run example code
-
-Display DSS WB example
-^^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric::  *Description*
-   :name: description-1
-
-The WB pipeline allows the use of the hardware processing available
-inside the DISPC, such as color space conversion, rescaling, and
-compositing to perform memory-to-memory transfer with data processing or
-capturing a displayed frame.
-
-.. rubric::  *Running Display DSS WB example*
-   :name: running-display-dss-wb-example
-
-The test connection and procedure for this example is very much same as
-the running the Display DSS example. In this example, the display output
-that is sent to the output is captured and sent to the WriteBack
-pipeline.
-
-.. rubric::  **Loopback (Capture and Display) example**
-   :name: loopback-capture-and-display-example
-
-.. rubric::  *Description*
-   :name: description-2
-
-This is the capture and display example that demonstrates the VIP
-captures functions for the devices. VIP incorporates a multi-channel raw
-video parser, various video processing blocks, and a flexible Video Port
-Direct Memory Access (VPDMA)engine to store incoming video in various
-formats. This example demonstrates the video capture of 720P, YUY422
-format from the camera sensor (OV2659 for idkAM57x and OV1063x for
-evmAM572x) to DPI1 LCD output.
-
-.. rubric::  *Running Loopback example*
-   :name: running-loopback-example
-
--  Make sure OV sensor and LCD Panel is connected to to the board before
-   running the binary.
-
-**CCS connection**:
-
-#. Power up the board
-#. Connect to the Core
-#. Run the application, Select any of the option.
-#. Captured Content will be displayed on the LCD panel connected to EVM
-
-|
-
-FAQ
----
-
-.. rubric::  How to reduce the VPS test examples build time using
-   makefile?
-   :name: how-to-reduce-the-vps-test-examples-build-time-using-makefile
-
-Please refer to `Rebuilding The PDK <index_how_to_guides.html#rebuild-drivers-from-pdk-directory>`__
-on how to invoke the build for specific core and specific platform, to save the
-build time.
-
-.. rubric::  How to create a CCS project other than VPS loopback
-   example?
-   :name: how-to-create-a-ccs-project-other-than-vps-loopback-example
-
-To create a CCS project for other VPS examples, please use the existing
-text file under
-PDK_INSTALL_PATH\packages\ti\drv\vps\examples\ccsprojects\am57xx\bios as
-a template:
-
--  Copy the .txt with desired processor then rename it to a new test
-   project name accord to CCS project create convention, see
-   `PDK Example and Test Project Creation <index_how_to_guides.html#pdk-example-and-test-project-creation>`__
--  Update the linked source files and include paths
--  The common configuration file and build options can be kept
--  Update pre-defined symbol -D<soc_name> to match your SOC, like
-   -DSOC_AM571x, -DSOC_AM572x or -DSOC_AM574x
--  Update the configuration .bld file "-b
-   ${PDK_INSTALL_PATH}/ti/build/<soc>/config_<soc>_<core>.bld" to match
-   your soc
--  In rtsc.setConfiguroOptions, add -DBOARD=<board_name>, which can be
-   idkAM571x, idkAM572x, evmAM572x or idkAM574x
--  Save the file and re-run pdkProjectCreate to create the new added CCS
-   project
-
-Below is example for vps_dssExample_evmAM572x_armExampleProject.txt:
-
-``-ccs.linkFile "PDK_INSTALL_PATH/ti/drv/vps/examples/dss/displayDss/src/DisplayDss_main.c"``
-
--ccs.linkFile
-"PDK_INSTALL_PATH/ti/drv/vps/examples/ccsprojects/common/bios/utils/bspCommonBIOS_a15.cfg"
-
--ccs.setCompilerOptions "-c -mcpu=cortex-a15 -mtune=cortex-a15 -marm
--mfloat-abi=hard -DMAKEFILE_BUILD -DNDEBUG -DTRACE_ENABLE
--DASSERT_ENABLE -DVPS_VIP_BUILD -DVPS_VPE_BUILD -DVPS_DSS_BUILD
--UVPS_ISS_BUILD -UVPS_SIMCOP_BUILD -UVPS_ISS_ISP_DEF -DVPS_VIP1_BUILD
--DVPS_VIP2_BUILD -DVPS_VIP3_BUILD -DVPS_CAPT_BUILD -DVPS_DISP_BUILD
--DSOC_AM572x -Dxdc_target_types__=gnu/targets/arm/std.h
--Dxdc_target_name__=A15F -g -gstrict-dwarf -gdwarf-3 -Wimplicit -Wall
--Wunused -Wunknown-pragmas -ffunction-sections -fdata-sections -MMD -MP
--I${PDK_INSTALL_PATH}/ti/drv/vps
--I${PDK_INSTALL_PATH}/ti/drv/vps/examples/dss/displayDss/src"
--rtsc.enableRtsc
-
--ccs.setLinkerOptions " -lrdimon -lgcc -lm -lnosys -nostartfiles -static
--Wl,--gc-sections
--L$(BIOS_INSTALL_PATH)/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu
-" -rtsc.setConfiguroOptions "-b
-${PDK_INSTALL_PATH}/ti/build/am572x/config_am572x_a15.bld
--DBOARD=evmAM572x"
-
-.. rubric::  Can I load any jpeg file into the memory to display through
-   DSS?
-   :name: can-i-load-any-jpeg-file-into-the-memory-to-display-through-dss
-
-The display uses video, not static image as input. There is no JPEG
-decoder so it will not work.
-
-.. rubric::  In DSS example, two input video files are loaded for
-   testing, what is their format and how to play them?
-   :name: in-dss-example-two-input-video-files-are-loaded-for-testing-what-is-their-format-and-how-to-play-them
-
-The two files are with .tigf extension. Tigf is a local convention that
-TI development team followed. The file name (before the extension) shows
-what you are attempting to decode: e.g., 24 bit RGB or yuyv422 video
-file with 1920x1080 resolutions. To play them:
-
--  In Linux, use avplay with syntax: avplay -video_size <wxh>
-   -pixel_format <format> -f rawvideo <video file>, where wxh is
-   1902x1080 and pixel_format is rgb24 or yuyv422
-
--  In Windows, use yuv player from:
-   https://sourceforge.net/projects/raw-yuvplayer/
-
-|
diff --git a/source/rtos/PDK_Platform_Software/IPC/_GateMP_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_GateMP_Module.rst
deleted file mode 100644
index 0b9fe6c1a..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_GateMP_Module.rst
+++ /dev/null
@@ -1,183 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/GateMP_Module
-
-.. |gpmCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-
-.. |gmpRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_gate_m_p_8h.html
-
-.. |gmpRun_Img2| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_gate_m_p_8h.html
-
-|
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |gpmCfg_Img1| | |gmpRun_Img1| |
-   +---------------+---------------+
-
-A GateMP instance can be used to enforce both local and remote context protection.
-That is, entering a GateMP can prevent preemption by another thread/process running on the
-same processor and simultaneously prevent a remote processor from entering the same gate.
-GateMP's are typically used to protect reads/writes to a shared resource, such as shared memory.
-
-.. note::
-  Initial IPC 3.x releases only supported GateMP on BIOS. It was introduced on QNX in IPC 3.10, and on Linux/Android in 3.21.
-
-Creating a GateMP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-As with other IPC modules, GateMP instances can only be created dynamically.
-
-Before creating the GateMP instance, you initialize a GateMP_Params structure and set fields in the structure to the desired values.
-You then use the GateMP_create() function to dynamically create a GateMP instance.
-
-When you create a gate, shared memory is initialized, but the GateMP object is created in local memory. Only the gate information resides in shared memory.
-
-The following code creates a GateMP object:
-
-::
-
-  GateMP_Params gparams;
-  GateMP_Handle gateHandle;
-
-  GateMP_Params_init(&gparams);
-  gparams.localProtect = GateMP_LocalProtect_THREAD;
-  gparams.remoteProtect = GateMP_RemoteProtect_SYSTEM;
-  gparams.name = "myGate";
-  gparams.regionId = 1;
-  gateHandle = GateMP_create(&gparams, NULL);
-
-A gate can be configured to implement remote processor protection in various ways.
-This is done via the params.remoteProtect configuration property.
-The options for params.remoteProtect are as follows:
-
-- GateMP_RemoteProtect_NONE. Creates only the local gate specified by the localProtect property.
-- GateMP_RemoteProtect_SYSTEM. Uses the default device-specific gate protection mechanism for your device.
-  Internally, GateMP automatically uses device-specific implementations of multi-processor mutexes implemented via a variety of hardware mechanisms.
-  Devices typically support a single type of system gate, so this is usually the correct configuration setting for params.remoteProtect.
-- GateMP_RemoteProtect_CUSTOM1 and GateMP_RemoteProtect_CUSTOM2 (BIOS-only). Some devices support multiple types of system gates.
-  If you know that GateMP has multiple implementations of gates for your device, you can use one of these options.
-
-Several gate implementations used internally for remote protection are provided in the ti.sdo.ipc.gates package.
-
-A gate can be configured to implement local protection at various levels.
-This is done via the params.localProtect configuration property (BIOS-only).
-The options for params.localProtect are as follows:
-
-- GateMP_LocalProtect_NONE. Uses the XDCtools GateNull implementation, which does not offer any local context protection.
-  For example, you might use this option for a single-threaded local application that still needs remote protection.
-- GateMP_LocalProtect_INTERRUPT. Uses the SYS/BIOS GateHwi implementation, which disables hardware interrupts.
-- GateMP_LocalProtect_TASKLET. Uses the SYS/BIOS GateSwi implementation, which disables software interrupts.
-- GateMP_LocalProtect_THREAD. Uses the SYS/BIOS GateMutexPri implementation, which is based on Semaphores.
-  This option may use a different gate than the following option on some operating systems. When using SYS/BIOS, they are equivalent.
-- GateMP_LocalProtect_PROCESS. Uses the SYS/BIOS GateMutexPri implementation, which is based on Semaphores.
-
-This property is currently ignored (as of IPC 3.23) on non-BIOS OSes.
-A thread-level mutex is used for local protection independent of this property setting.
-
-Other fields you are required to set in the GateMP_Params structure are:
-
-- name. The name of the GateMP instance.
-- regionId. The ID of the SharedRegion to use for shared memory used by this GateMP instance (BIOS-only).
-
-|gmpRun_Img2| The latest version of the GateMP module run-time API documentation is available
-`online <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_gate_m_p_8h.html>`_
-
-Opening a GateMP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-Once an instance is created on a processor, the gate can be opened on another processor to obtain a local handle to the same instance.
-
-The GateMP module uses a NameServer instance to allow a remote processor to address the local GateMP instance using
-a user-configurable string value as an identifier rather than a potentially dynamic address value.
-
-::
-
-  status = GateMP_open("myGate", &gateHandle);
-  if (status < 0) {
-      System_printf("GateMP_open failed\n");
-  }
-
-Closing a GateMP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-GateMP_close() frees a GateMP object stored in local memory.
-
-GateMP_close() should never be called on an instance whose creator has been deleted.
-
-Deleting a GateMP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-GateMP_delete() frees a GateMP object stored in local memory and flags the shared memory to indicate that the gate is no longer initialized.
-
-A thread may not use GateMP_delete() if it acquired the handle to the gate using GateMP_open(). Such threads should call GateMP_close() instead.
-
-Entering a GateMP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Either the GateMP creator or opener may call GateMP_enter() to enter a gate.
-While it is necessary for the opener to wait for a gate to be created to enter a created gate,
-it isn't necessary for a creator to wait for a gate to be opened before entering it.
-
-GateMP_enter() enters the caller's local gate. The local gate (if supplied) blocks if entered on the local processor.
-If entered by the remote processor, GateMP_enter() spins until the remote processor has left the gate.
-
-No matter what the params.localProtection configuration property is set to, after GateMP_enter() returns,
-the caller has exclusive access to the data protected by this gate.
-
-A thread may reenter a gate without blocking or failing.
-
-GateMP_enter() returns a "key" that is used by GateMP_leave() to leave this gate;
-this value is used to restore thread preemption to the state that existed just prior to entering this gate.
-
-::
-
-  IArg key;
-
-  /* Enter the gate */
-  key = GateMP_enter(gateHandle);
-
-Leaving a GateMP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-GateMP_leave() may only called by a thread that has previously entered this gate via GateMP_enter().
-
-After this method returns, the caller must not access the data structure
-protected by this gate (unless the caller has entered the gate more than once and other calls to leave remain to balance the number of previous calls to enter).
-
-::
-
-  IArg key;
-
-  /* Leave the gate */
-  GateMP_leave(gateHandle, key);
-
-Querying a GateMP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-GateMP_query() returns TRUE if a gate has a given quality, and FALSE otherwise, including cases when the gate does not recognize the constant describing the quality. The qualities you can query are:
-
-- GateMP_Q_BLOCKING. If GateMP_Q__BLOCKING is FALSE, the gate never blocks.
-- GateMP_Q_PREEMPTING. If GateMP_Q_PREEMPTING is FALSE, the gate does not allow other threads to preempt the thread that has already entered the gate.
-
-NameServer Interaction
-^^^^^^^^^^^^^^^^^^^^^^^^
-The GateMP module uses a ti.sdo.utils.NameServer instance to store instance information when an instance is created and the name parameter is non-NULL.
-The length of this name is limited to 16 characters (by default) including the null terminator ('\0').
-This length can be increased by configuring the GateMP.maxNameLen module configuration property.
-If a name is supplied, it must be unique for all GateMP instances.
-
-Other modules can use GateMP instances to protect access to their shared memory resources.
-For example, the NameServer name tables are protected by setting the "gate" property of the ti.sdo.utils.NameServer module.
-
-These examples set the "gate" property for various modules:
-
-::
-
-  heapBufMPParams.gate  = GateMP_getDefaultRemote();
-  listMPParams.gate     = gateHandle;
-
-Sample Runtime Program Flow (Dynamic)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The following diagram shows the program flow for a two-processor (or two-thread) application.
-This application creates a Gate dynamically.
-
-.. Image:: /images/IpcUG_ipc_2_6_1.png
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_HeapMP_Modules.rst b/source/rtos/PDK_Platform_Software/IPC/_HeapMP_Modules.rst
deleted file mode 100644
index fce21326f..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_HeapMP_Modules.rst
+++ /dev/null
@@ -1,196 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/HeapMP_Modules
-
-.. |hmpCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |hmpCfg_Img2| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |hmpCfg_Img3| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |hmpRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_heap_buf_m_p_8h.html
-
-.. |hmpRun_Img2| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_heap_mem_m_p_8h.html
-
-.. |hmpRun_Img3| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_heap_multi_buf_m_p_8h.html
-
-|
-
-   +---------------+---------------+--------------+
-   |     API Reference Links                      |
-   +===============+===============+==============+
-   | |hmpCfg_Img1| | |hmpRun_Img1| | HeapBuf      |
-   +---------------+---------------+--------------+
-   | |hmpCfg_Img2| | |hmpRun_Img2| | HeapMem      |
-   +---------------+---------------+--------------+
-   | |hmpCfg_Img3| | |hmpRun_Img3| | HeapMultiBuf |
-   +---------------+---------------+--------------+
-
-
-The ti.sdo.ipc.heaps package provides three implementations of
-the `xdc.runtime.IHeap interface <http://rtsc.eclipse.org/docs-tip/Using_xdc.runtime_Memory>`_.
-
-- **HeapBufMP.** Fixed-size memory manager. All buffers allocated from a HeapBufMP instance are of the same size.
-  There can be multiple instances of HeapBufMP that manage different sizes.
-  The ti.sdo.ipc.heaps.HeapBufMP module is modeled after SYS/BIOS 6's HeapBuf module (ti.sysbios.heaps.HeapBuf).
-- **HeapMultiBufMP.** Each instance supports up to 8 different fixed sizes of buffers.
-  When an allocation request is made, the HeapMultiBufMP instance searches the different buckets to find the smallest one that satisfies the request.
-  If that bucket is empty, the allocation fails. The ti.sdo.ipc.heaps.HeapMultiBufMP module is modeled after SYS/BIOS 6's HeapMultiBuf module (ti.sysbios.heaps.HeapMultiBuf).
-- **HeapMemMP.** Variable-size memory manager. HeapMemMP manages a single buffer in shared memory from which blocks of user-specified length are allocated and freed.
-  The ti.sdo.ipc.heaps.HeapMemMP module is modeled after SYS/BIOS 6's HeapMem module (ti.sysbios.heaps.HeapMem).
-
-The main addition to these modules is the use of shared memory and the management of multi-processor exclusion.
-
-The SharedRegion modules, and therefore the MessageQ module and other IPC modules that use SharedRegion, use a HeapMemMP instance internally.
-
-The following subsections use "Heap*MP" to refer to the HeapBufMP, HeapMultiBufMP, and HeapMemMP modules.
-
-.. note::
-  These Heap*MP Modules are only available on SYS/BIOS-based cores, they are not available when running an HLOS (e.g. Linux).
-  As an HLOS shared memory solution, many Linux SDKs are recommending/providing CMEM.
-  There are limitations (e.g. you cannot alloc on HLOS and free on RTOS), but these are in line with using the HLOS as a master (owning all resources) and
-  RTOS as a slave (using resources provided by the master).
-
-Configuring a Heap*MP Module
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In addition to configuring Heap*MP instances, you can set module-wide configuration properties.
-For example, the maxNameLen property lets you set the maximum length of heap names.
-The track[Max]Allocs module configuration property enables/disables tracking memory allocation statistics.
-
-A Heap*MP instance uses a NameServer instance to manage name/value pairs.
-
-The Heap*MP modules make the following assumptions:
-
-- The SharedRegion module handles address translation between a virtual shared address space and the local processor's address space.
-  If the memory address spaces are identical across all processors, or if a single processor is being used,
-  no address translation is required and the SharedRegion module must be appropriately configured.
-- Both processors must have the same endianness.
-
-Creating a Heap*MP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Heaps can be created dynamically. You use the Heap*MP_create() functions to dynamically create Heap*MP instances.
-As with other IPC modules, before creating a Heap*MP instance, you initialize a Heap*MP_Params structure and set fields in
-the structure to the desired values. When you create a heap, the shared memory is initialized and the Heap*MP object is created in local memory.
-Only the actual buffers and some shared information reside in shared memory.
-
-The following code example initializes a HeapBufMP_Params structure and sets fields in it.
-It then creates and registers an instance of the HeapBufMP module.
-
-::
-
-  /* Create the heap that will be used to allocate messages. */
-  HeapBufMP_Params_init(&heapBufMPParams);
-  heapBufMPParams.regionId      = 0;        /* use default region */
-  heapBufMPParams.name          = "myHeap";
-  heapBufMPParams.align         = 256;
-  heapBufMPParams.numBlocks     = 40;
-  heapBufMPParams.blockSize     = 1024;
-  heapBufMPParams.gate          = NULL;     /* use system gate */
-  heapHandle = HeapBufMP_create(&heapBufMPParams);
-  if (heapHandle == NULL) {
-      System_abort("HeapBufMP_create failed\n");
-  }
-
-  /* Register this heap with MessageQ */
-  MessageQ_registerHeap(HeapBufMP_Handle_upCast(heapHandle), HEAPID);
-
-The parameters for the various Heap*MP implementations vary. For example, when you create a HeapBufMP instance,
-you can configure the following parameters after initializing the HeapBufMP_Params structure:
-
-- **regionId.** The index corresponding to the shared region from which shared memory will be allocated.
-- **name.** A name of the heap instance for NameServer (optional).
-- **align.** Requested alignment for each block.
-- **numBlocks.** Number of fixed size blocks.
-- **blockSize.** Size of the blocks in this instance.
-- **gate.** A multiprocessor gate for context protection.
-- **exact.** Only allocate a block if the requested size is an exact match. Default is false.
-
-Of these parameters, the ones that are common to all three Heap*MP implementations are gate, name and regionId.
-
-Opening a Heap*MP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Once a Heap*MP instance is created on a processor, the heap can be opened on another processor to obtain a local handle to the same shared instance.
-In order for a remote processor to obtain a handle to a Heap*MP that has been created, the remote processor needs to open it using Heap*MP_open().
-
-The Heap*MP modules use a NameServer instance to allow a remote processor to address the local Heap*MP instance using a user-configurable string value as an identifier.
-The Heap*MP name is the sole parameter needed to identify an instance.
-
-The heap must be created before it can be opened. An open call matches the call's version number with the creator's version number in order to ensure compatibility.
-For example:
-
-HeapBufMP_Handle heapHandle;
-...
-
-::
-
-  /* Open heap created by other processor. Loop until open. */
-  do {
-      status = HeapBufMP_open("myHeap", &heapHandle);
-  }
-  while (status < 0);
-
-  /* Register this heap with MessageQ */
-  MessageQ_registerHeap(HeapBufMP_Handle_upCast(heapHandle), HEAPID);
-
-Closing a Heap*MP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Heap*MP_close() frees an opened Heap*MP instance stored in local memory. Heap*MP_close() may only be used to finalize instances that were opened with Heap*MP_open() by this thread. For example:
-
-::
-
-  HeapBufMP_close(&heapHandle);
-
-Never call Heap*MP_close() if some other thread has already called Heap*MP_delete().
-
-Deleting a Heap*MP Instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The Heap*MP creator thread can use Heap*MP_delete() to free a Heap*MP object stored in local memory and to flag the shared memory to indicate that the heap is no longer initialized.
-Heap*MP_delete() may not be used to finalize a heap using a handle acquired using Heap*MP_open()--Heap*MP_close() should be used by such threads instead.
-
-Allocating Memory from the Heap
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The HeapBufMP_alloc() function obtains the first buffer off the heap's freeList.
-
-The HeapMultiBufMP_alloc() function searches through the buckets to find the smallest size that honors the requested size.
-It obtains the first block on that bucket.
-
-If the "exact" field in the Heap*BufMP_Params structure was true when the heap was created, the alloc only returns the block if the blockSize for a bucket is the exact size requested.
-If no exact size is found, an allocation error is returned.
-
-The HeapMemMP_alloc() function allocates a block of memory of the requested size from the heap.
-
-For all of these allocation functions, the cache coherency of the message is managed by the SharedRegion module that manages the shared memory region used for the heap.
-
-Freeing Memory to the Heap
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The HeapBufMP_free() function returns an allocated buffer to its heap.
-
-The HeapMultiBufMP_free() function searches through the buckets to determine on which bucket the block should be returned.
-This is determined by the same algorithm as the HeapMultiBufMP_alloc() function, namely the smallest blockSize that the block can fit into.
-
-If the "exact" field in the Heap*BufMP_Params structure was true when the heap was created, and the size of the block to free does not match any bucket's blockSize, an assert is raised.
-
-The HeapMemMP_free() function returns the allocated block of memory to its heap.
-
-For all of these deallocation functions, cache coherency is managed by the corresponding Heap*MP module.
-
-Querying Heap Statistics
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Both heap modules support use of the xdc.runtime.Memory module's Memory_getStats() and Memory_query() functions on the heap.
-
-In addition, the Heap*MP modules provide the Heap*MP_getStats(), Heap*MP_getExtendedStats(), and Heap*MP_isBlocking() functions to enable you to gather information about a heap.
-
-By default, allocation tracking is often disabled in shared-heap modules for performance reasons.
-You can set the HeapBufMP.trackAllocs and HeapMultiBufMP.trackMaxAllocs configuration properties to true in order to turn on allocation tracking for their respective modules.
-Refer to the CDOC documentation for further information.
-
-Sample Runtime Program Flow
-The following diagram shows the program flow for a two-processor (or two-thread) application.
-This application creates a Heap*MP instance dynamically.
-
-.. Image:: /images/Heapmp_bigfig.png
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_3.x.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_3.x.rst
deleted file mode 100644
index 93a73c8af..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_3.x.rst
+++ /dev/null
@@ -1,94 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_3.x
-
-Introduction
--------------
-
-This page contains details about the IPC 3.x product, TI's solution for
-interprocessor communication between cores on homogenous and
-heterogeneous devices.
-
-IPC 3.x is an evolution of the IPC product, so it helps to understand
-the scope of previous generations.
-
--  `The IPC
-   product <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/index.html>`__
-   defines `several
-   interfaces <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/index.html>`__
-   to facilitate multiprocessor communication.
--  The IPC 1.x product includes implementations of those interfaces for
-   the SYS/BIOS RTOS. It supports communicating between cores running
-   SYS/BIOS, as well to HLOS processors running SysLink 2.x.
--  The SysLink 2.x provides services to control slave processors (e.g. load, start,
-   stop). It also provides an implementation of the IPC interfaces for
-   High Level OSs (HLOS) like Linux and QNX. SysLink 2.x supports
-   communicating with slave processors running SYS/BIOS and IPC 1.x.
-
-IPC 3.x merges the IPC 1.x and SysLink 2.x products, creating a single
-product that defines multiprocessor communication APIs and provides
-implementations for several OS's, including SYS/BIOS and HLOS's.
-
-.. note::
-  The SysLink name is being retired. The SysLink 2.x product will not
-  be supported on existing devices, and development has stopped and
-  support for new devices will not be added.
-
-
-Changes
------------
-
-The key changes between IPC 1.x/SysLink 2.x and IPC 3.x is the HLOS
-implementation. This table summarizes the IPC 1.x/SysLink 2.x supported APIs against
-those provided in IPC 3.x.
-
-+-----------------------+-----------------------+-----------------------+
-| Feature               | IPC 1.x/SysLink 2.x   | IPC 3.x               |
-+=======================+=======================+=======================+
-| Slave loading         | ProcMgr               | Slaves are loaded on  |
-|                       |                       | demand, currently     |
-|                       |                       | without a user API    |
-+-----------------------+-----------------------+-----------------------+
-| Low-level primitives  | Notify, Heap*MP,      | Available for         |
-|                       | Gate*MP,              | BIOS-to-BIOS          |
-|                       | SharedRegion,         | communication, only   |
-|                       | NameServer            | GateMP available on   |
-|                       |                       | HLOS                  |
-+-----------------------+-----------------------+-----------------------+
-| Messaging             | MessageQ              | MessageQ              |
-+-----------------------+-----------------------+-----------------------+
-| Higher level data     | RingIO, FrameQ        | None, though IPC      |
-| passing               |                       | provides primitives   |
-|                       |                       | to enable higher      |
-|                       |                       | level frameworks      |
-+-----------------------+-----------------------+-----------------------+
-
-BIOS
-^^^^^^^
-
-For BIOS-to-BIOS communication, the same features available in IPC 1.x
-are available in IPC 3.x.
-
-Linux
-^^^^^^^
-
-On Linux, IPC 3.x is built upon services available (and evolving!) in
-the mainline Linux kernel (3.4+). These core services include remoteproc
-and rpmsg.
-
-Above those Linux services, a few key services from the IPC API (e.g.
-MessageQ) are provided in user mode.
-
-QNX
-^^^^^^^
-
-On QNX, IPC 3.x provides feature parity to Linux. The QNX OS doesn't
-inherently provide primitives like Linux's 'remoteproc' and 'rpmsg', so
-IPC 3.x also includes a loader and rpmsg-compatible communication
-infrastructure. This rpmsg-compatible MessageQ implementation enables
-the same BIOS-side image to communicate with either Linux or QNX on the
-HLOS.
-
-Development
--------------
-
-IPC 3.x development is being managed at https://git.ti.com/ipc.
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_3.x_FAQ.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_3.x_FAQ.rst
deleted file mode 100644
index 713078ba6..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_3.x_FAQ.rst
+++ /dev/null
@@ -1,539 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_3.x_FAQ
-
-
-I have a question that's not answered here, what now?
------------------------------------------------------
-
--  There are lots of knowledgeable experts on the `TI E2E Support Forums <http://e2e.ti.com/>`__ - posts
-   welcome!
--  Have you tried `Google <http://www.google.com>`__? IPC's been around
-   a while, and Google has lots of details about it.
-
-Does IPC 3.x support SMP BIOS?
---------------------------------
-
-`SMP BIOS is described here <http://processors.wiki.ti.com/index.php/SMP/BIOS>`__. It is currently
-only available for dual-core ARM M-class devices, sometimes called
-"Benelli" or "Ducati".
-
-Specifically where IPC 3.x is concerned, SMP BIOS is only applicable to
-the following cores/devices:
-
--  IPU on OMAP54XX
--  IPU1 (and IPU2, if present) on DRA7XX (e.g. Vayu)
-
-The answer to this question depends on whether you are developing an
-HLOS-based or BIOS-based system.
-
-+-----------------------------------+-----------------------------------+
-| HLOS-Based                        | BIOS-Based                        |
-| (e.g. Linux, QNX, Android on the  | (i.e. BIOS on the Cortex-A)       |
-| Cortex-A)                         |                                   |
-+===================================+===================================+
-| IPC 3.x **only** supports SMP     | IPC 3.x supports either SMP BIOS  |
-| BIOS on the IPU(s).               | or non-SMP BIOS. Note that        |
-| In an HLOS-based system, the      | specifically on DRA7XX's          |
-| IPU(s) are loaded and managed as  | **IPU2**, IPC 3.x only supports   |
-| slaves (not peers).               | SMP BIOS (to reduce the number of |
-|                                   | core-to-core permutations and     |
-| When managing the IPU as a slave, | thus reduce the number of         |
-| issues like power management,     | mailboxes required).              |
-| loading/resetting, and error      | In a BIOS-based environment, the  |
-| recovery are key features.        | IPU(s) are treated as peers (not  |
-| Because the 2 cores in a single   | slaves), and as such some of the  |
-| IPU can't easily be seen as truly | concerns about power management,  |
-| independent (e.g. they share a    | loading, error recovery are no    |
-| power domain), treating them as   | longer an issue.                  |
-| one slave (running SMP BIOS) is   |                                   |
-| simpler and more natural.         | Note that the MultiProc           |
-|                                   | configuration used on all cores   |
-|                                   | reflects your SMP-or-not-SMP      |
-|                                   | decision. When using non-SMP      |
-|                                   | BIOS, you must include "IPU1-0"   |
-|                                   | and "IPU1-1" (rather than "IPU1"  |
-|                                   | used when running SMP BIOS) in    |
-|                                   | your MultiProc configuration. See |
-|                                   | the ex11_ping example provided    |
-|                                   | with the IPC product for an       |
-|                                   | example that supports either      |
-|                                   | "IPU1" or "IPU1-0 and IPU1-1".    |
-+-----------------------------------+-----------------------------------+
-
-Finally, there are a few notable benefits to using SMP BIOS. Many are
-described in the `SMP/BIOS <http://processors.wiki.ti.com/index.php/SMP/BIOS>`__ article, but two are
-highlighted here:
-
--  **Free load balancing** - SMP BIOS schedules tasks to run on the
-   less-loaded core to balance IPU usage. Without SMP BIOS, when one of
-   the cores became heavily loaded, users had to repartition the
-   resources; often this meant moving tasks/code from one core to the
-   other, which can affect memory maps, build/config scripts, etc.
--  **Simpler system integration** - there's one fewer core to manage the
-   memory map and resource allocation for. Without SMP BIOS, the single
-   unicache needed to understand AMMU and cache needs for both cores,
-   and often confusing and error-prone integration issue.
-
-Build Questions
------------------
-
-BIOS-side Build
-^^^^^^^^^^^^^^^^
-
-How do I change the Memory Map?
-""""""""""""""""""""""""""""""""""
-
-Standard techniques for changing the memory map of any BIOS executable
-generally apply (e.g. `creating your own custom
-platform <http://rtsc.eclipse.org/docs-tip/Demo_of_the_RTSC_Platform_Wizard_in_CCSv4>`__,
-`creating an instance of an existing
-platform <http://rtsc.eclipse.org/docs-tip/Using_Targets_and_Platforms>`__,
-etc). However when building an executable which is loaded by an HLOS,
-you also need to ensure the resource table is aligned with the memory
-map. The `IPC Resource
-customTable <index_Foundational_Components.html#resource-custom-table>`__ article describes
-how to override the default resource table, which among other things,
-includes the memory map.
-
-Obviously be sure to also ensure changes to the memory map don't collide
-with memory usage on other cores.
-
-Why are the peripherals mapped to 0x6XXX:XXXX virtual memory for IPU (Cortex-M4) test images?
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The ARM Cortex-M4 memory map includes a bit-banding region of memory
-from 0x4000:0000 to 0x400F:FFFF and 0x4200:0000 to 0x43FF:FFFF. Here is
-a Cortex-M4 memory map picture from ARM:
-
-::
-
-      http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDBIJJE.html
-
-Many Vayu components running on the IPUs, including IPC, must access
-peripherals physically located in this bit-banding region. As a result,
-these accesses must be performed indirectly using a virtual memory
-address, mapped using the IPU's AMMU.
-
-Many of the components aligned on mapping this memory using one Large
-AMMU page that maps 512M of physical memory beginning at 0x4000:0000 to
-virtual memory beginning at 0x6000:0000. Then the components (by
-default) access the peripherals using the 0x6XXX:XXXX address space.
-
--  IPC specifics:
-
-IPC follows the convention of, by default, accessing memory physically
-located at 0x4XXX:XXXX using virtual memory at 0x6XXX:XXXX. You can see
-an example of this here - note the mailbox addresses configured here are
-in the 06XXX:XXXX range:
-
-::
-
-       http://git.ti.com/cgit/cgit.cgi/ipc/ipcdev.git/tree/packages/ti/sdo/ipc/family/vayu/InterruptIpu.xs
-
-In that same file, you can see that these addresses are configurable,
-and the default 0x6XXX:XXXX addresses are only used if other addresses
-haven't already been configured by the system integrator (e.g. in a .cfg
-script). Users can override these default mailbox addresses using the
-ti.sdo.ipc.family.vayu.InterruptIpu module's mailboxBaseAddr[] array,
-documented here:
-
-http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/ti/sdo/ipc/family/vayu/InterruptIpu.html#metamailbox.Base.Addr
-
-Linux Build
-^^^^^^^^^^^^^
-
-For details on the Linux build process see the `IPC Install Guide for
-Linux <index_Foundational_Components.html#linux-install-guide>`__.
-
-Try Cleaning First
-"""""""""""""""""""
-
-Sometimes the generated autotools makefiles can get confused, especially
-if your often switching from one platform to another, between static and
-dynamic libraries, etc. And sometimes simply cleaning and retrying can
-help.
-
-"make clean" does a 'light' cleaning, leaving the autotools-generated
-config files so you can just retry 'make':
-
-::
-
-    # make clean
-    #
-    # make
-
-"make distclean" does a more aggressive clean, requiring you to re-run
-the config before running 'make':
-
-::
-
-    # make distclean
-    #
-    # make -f ipc-linux.mak
-    # make
-
-QNX Build
-^^^^^^^^^^^
-
-For details on the QNX build process see the `IPC Install Guide for
-QNX <index_Foundational_Components.html#qnx-install-guide>`__.
-
-How do I change the Memory Map?
-""""""""""""""""""""""""""""""""
-
-For the standpoint of the QNX OS, it owns all external memory by
-default. When the 'ipc' resource manager is launched and the slave cores
-are loaded, the resource table in each slave executable is read and
-interpreted. All resource entries of type CARVEOUT are automatically
-allocated from QNX-owned memory. Similarly, the first DEVMEM entry
-always corresponds to the vring memory used by MessageQ and rpmsg_rpc,
-and is also automatically allocated from QNX-owned memory, regardless of
-which physical memory address is specified in the resource table entry.
-If any other DEVMEM resource entry resides in external memory, QNX would
-need to be told to not use that particular range. This is usually done
-using the '-r' flag in the startup command in the 'build' file of the
-QNX IFS (refer to your QNX BSP documentation for more details):
-
-::
-
-      startup-dra74x-vayu-evm -r0xBA300000,0x5A00000 -v -n852,668 -W -G
-
-For example, the above '-r' flag would reserve 0x5A00000 bytes starting
-at physical address 0xBA300000 from being used by the QNX OS on the
-DRA74x. This technique is often used for the memory range used by
-shmemallocator (resource table entry PHYS_MEM_IOBUFS) and/or by
-SharedRegions. After modifying the startup flags, rebuild the QNX IFS
-and use the new one to boot your board.
-
-How do I configure the memory used by shmemallocator?
-""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-shmemallocator stands for "Shared Memory Allocator". It is a utility
-that is built alongside the core IPC driver whenever the IPC product is
-built. The user can optionally use this utility to allocate contiguous
-shared memory for exchanging data between the host and the slave cores.
-The memory it allocates from is defined in
-<IPC_INSTALL_DIR>\qnx\src\ipc3x_dev\sharedmemallocator\resmgr\SharedMemoryAllocator.c
-thru some #define statements:
-
-::
-
-    #define SH_MEM_BLOCK1_START 0xBA300000
-    #define SH_MEM_BLOCK1_SIZE  0x5A00000
-
-Typically, even though the code base (as of IPC 3.35) supports up to two
-blocks, only block 1 is used when allocating memory using the function
-SHM_alloc(), as shown in the IPC examples. When adjusting this block, It
-is important that the memory matches a corresponding DEVMEM entry
-(PHYS_MEM_IOBUFS) in the resource table so that this memory is mapped to
-the slave core's MMU, and that the memory is reserved in the QNX IFS
-startup command as per `"How do I change the Memory
-Map?" <index_Foundational_Components.html#how-do-i-change-the-memory-map>`__.
-
-Runtime Troubleshooting
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Linux spurious "msg received with no recepient"
-""""""""""""""""""""""""""""""""""""""""""""""""
-
-When a Linux-loaded slave communicates to the Linux host, it sends a msg
-using an rpmsg "channel". Sometimes there's no one listening on that
-channel, for example if there are no host-side IPC applications running.
-When a host-side application calls Ipc_start(), these channels start to
-be monitored, but until then, no one's listening.
-
-When, for example, a slave does a NameServer lookup, this query is often
-sent to all cores in the system. If there's no host-side application
-running, there's no one listening for these msgs, and when the
-underlying rpmsg driver detects an arriving msg that no one's listening
-for, it issues a dev_warn() call to report this, drops the message, and
-moves along.
-
-These warnings are often benign, and sometimes just reflect chatter
-between the various slaves. Perhaps the dev_warn() should be changed to
-a dev_dbg().
-
-And yes, that's a typo - 'recepient' is really spelled 'recipient'.
-Submit a patch and get your initials into the Linux kernel.  :)
-
-Disabling auto-recovery
-""""""""""""""""""""""""
-
-When the HLOS detects a fault on a slave (e.g. an MMU fault), it reloads
-and restarts the slave. Sometimes, especially when debugging slave-side
-errors, it's useful to disable this feature so the state of the crashed
-slave isn't reset and can be examined.
-
-Linux
-''''''
-
-You can disable recovery of a given remote processor using remoteproc's
-debugfs features. First, find the slave you want to disable (e.g.
-``cat /debug/remoteproc/remoteproc0/name``) and then echo "disabled" to
-the "recovery" file.
-
-For example, if "remoteproc0" is the core you want to disable:
-
-::
-
-    target# echo "disabled" > /debug/remoteproc/remoteproc0/recovery
-
-QNX
-''''
-
-Starting in IPC 3.22, you can simply throw the '-d' option when
-launching the ipc resource manager to disable the recovery mechanism.
-
-If you are using IPC 3.21 or older, there are a couple of tricks to
-prevent the slaves from being automatically reloaded and restarted:
-
--  If you have the QNX Momentics IDE installed, you can set a breakpoint
-   on the entry of ipc_recover() in
-   <IPC_INSTALL_DIR>/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/syslink_main.c.
-   This function is the callback that is invoked when an MMU fault
-   occurs to perform the reload. Halting the host at that point would
-   prevent it from reloading the DSP, and gives you time to inspect the
-   DSP memory. This is nice because it does not necessitate a rebuild of
-   IPC.
-
--  If you do not have access to the QNX debugger, you can rebuild IPC
-   after commenting out the lines in ipc_recover(), and use the modified
-   IPC resource manager binary for debugging. That would prevent it from
-   reloading the DSP.
-
-When should Ipc_start() be called?
-------------------------------------
-
-On a slave core, Ipc_start() should be called only if there is a need to
-initialize the SharedRegion module and/or to perform slave-to-slave IPC
-communication. In other words, if communication strictly happens between
-host and slave(s), and SharedRegions are not defined, then there is no
-need to call Ipc_start() on the slave. In fact, if SR0 (SharedRegion 0)
-is not defined on a slave core, do not call Ipc_start() on that slave
-core. The call would fail when it tries to look for SR0.
-
-For an example that shows a call to Ipc_start() on the slave cores,
-refer to the ex41_forwardmsg example, which showcases both host-to-slave
-and slave-to-slave communication paths. Specifically, this line in
-Dsp1.cfg and Ipu1.cfg adds a call to Ipc_start() within BIOS_start():
-
-::
-
-    BIOS.addUserStartupFunction('&IpcMgr_callIpcStart');
-
-On the host core, Ipc_start() always needs to be called to initialize
-IPC. Given host-side IPC code does not use SharedRegion, the function is
-strictly used to perform initialization for other IPC modules.
-
-Linux Ipc_start() Failures
-----------------------------
-
-LAD reports NameServer_setup: connect failed: 22, Invalid argument
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Internally, LAD tries to connect to sockets created by the rpmsg_proto
-kernel driver. This connection can fail for several reasons, so this is
-a common "general" error code. Some examples that generate this error
-condition are below.
-
--  Failure to load the slave image. If the a slave executable fails to
-   load, the sockets to communicate with it are not created. Make sure
-   the slaves you need to communicate with are already loaded.
--  Failure to provide the correct KERNEL_INSTALL_DIR when building the
-   user-side IPC libraries. Some customers reported this error when
-   using Linux 3.9+ kernels (where the AF_MAX value in socket.h has
-   increased). This created a mismatch in what AF_RPMSG was set to in
-   user libs and the kernel, and the connect call failed. The solution
-   was to require users set KERNEL_INSTALL_DIR when building the
-   user-space libraries so IPC can interrogate the kernel version and
-   set AF_RPMSG appropriately.
--  Failure to configure the slave image correctly. Internally, the
-   slave-side MessageQ transport (TransportRpmsg) broadcasts its
-   availability to the Linux host. If this broadcast doesn't occur
-   (e.g., b/c the slave wasn't configured with TransportRpmsg), the
-   socket connection will fail with error 22.
--  General slave-to-host interrupt failure. Some devices (e.g. DRA7XX)
-   have interrupt crossbars that must be configured correctly as part of
-   system boot (e.g. uboot). If these crossbars aren't initialized
-   correctly, the slave-side broadcast that TransportRpmsg is available
-   won't be received, the underlying socket connection won't be
-   available, and the first sign of failure will be LAD trying to
-   connect to the socket.
-
-LAD reports LAD_connect() failed: 4
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This is a LAD_IOFAILURE = 4. The HOST OS-side application was unable to
-communicate with LAD due to an OS_level I/O failure.
-
-This is typically caused by LAD directory permissions.
-
--  In Linux **/tmp/LAD**
--  In Android **/data/lad/LAD**
-
-The application was attempting to create or read from LAD's response
-FIFO but was unable to by the application.
-
-LAD must be started as root(su). IPC user applications communicating
-with LAD, can be executed in **user** mode but need to ensure LAD is
-stared with the correct permission.
-
--  **%** lad_dra7xx -l log.txt -p 777
-
-You can also run both LAD and user application as root(su), thus not
-requiring permission to be properly set when starting LAD.
-
-LAD reports \_GateMP_TI_dGate not found
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When the -g option is thrown, the LAD log may show an error about not
-finding the symbol \_GateMP_TI_dGate:
-
-::
-
-    [22.583839] NameServer_getRemote: value for GateMP:_GateMP_TI_dGate not found.
-    [22.583852] GateMP_attach: failed to open default gate on procId 4
-    [22.583862]     status = -5
-    [22.583871] DONE
-
-This is because LAD is looking for the default GateMP instance, and did
-not find it. On the DRA7xx, verify
-
-#. SharedRegion 0 is defined on DSP1. GateMP implementation on the host
-   requires use of SharedRegion
-#. DSP1 is the owner of SharedRegion 0
-#. Ipc_start() is called on DSP1. This ensures the default GateMP
-   instance is created.
-
-|
-
-HLOS loading failures
------------------------
-
-BIOS-side VirtQueue assertions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The slave loads ok, but communication fails, and in the slave trace
-output you find the following assert (line number and timestamp may
-vary):
-
-::
-
-    [      0.000] [t=0x00d090ce] ti.ipc.family.vayu.VirtQueue: ERROR: "VirtQueue.c", line 296:
-    [      0.000] ti.ipc.family.vayu.VirtQueue: "VirtQueue.c", line 296:
-    [      0.000] xdc.runtime.Error.raise: terminating execution
-
-This error often indicates a mismatch in VRING addresses between the
-HLOS side and the slave. Often this is because a `custom resource
-table <index_Foundational_Components.html#resource-custom-table>`__ was provided and the
-VRING addresses specified don't match the HLOS-side addresses.
-
-QNX IPC driver takes a long time to load the slave executable(s) when '-g' is thrown
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The '-g' option to the IPC driver is used to enable optional support for
-GateMP on the host processor. During the setup of GateMP module, it
-polls the slave processors for the default gate instance, which is
-created by the owner of SharedRegion 0. If none of the cores loaded has
-created the default gate, the driver will continue polling and
-eventually timeout after 2 seconds, which means the loading procedure
-may be delayed by 2 seconds as a consequence. To better suit a given
-application, one can adjust the polling interval and the timeout
-duration in the file
-<IPC_INSTALL_DIR>/qnx/src/ipc3x_dev/ti/syslink/ipc/hlos/knl/GateMP_daemon.c
-(this code excerpt may look slightly different depending on the version
-of IPC you are looking at, but the idea is the same):
-
-.. code-block:: c
-
-    // Timeout duration is SETUP_TIMEOUT * polling interval
-    #define SETUP_TIMEOUT         2
-
-    Int GateMP_setup(Int32 * sr0ProcId)
-    {
-    ...
-       UInt              timeout = SETUP_TIMEOUT;
-    ...
-       if (status == GateMP_S_SUCCESS) {
-           /* The default gate creator is the owner of SR0 */
-           while (((status = GateMP_openDefaultGate(&GateMP_module->defaultGate,
-               &procId)) == GateMP_E_NOTFOUND) && (timeout > 0)) {
-               sleep(1);  // polling interval
-               timeout--;
-           }
-    ...
-    }
-
-In the case where the owner of SharedRegion 0 is not being loaded by the
-IPC driver, reducing the timeout duration (SETUP_TIMEOUT) may be useful
-to reduce the delay that results when the driver cannot find the default
-gate.
-
-In the case where the owner of SharedRegion 0 is indeed loaded by the
-IPC driver, using usleep() instead of sleep() to reduce the polling
-interval can be beneficial in cases where the initial poll happens
-before the slave core (owner of SR0) has even got to the point in its
-initialization to create the default gate. A faster polling rate would
-ensure that a second or a third poll is performed more quickly thereby
-giving a chance for the driver to move on. On the other hand, reducing
-the polling interval too much may cause the driver to swamp the slave
-cores with gate lookup requests, counterproductively slowing down the
-loading process. As a rule of thumb, it is recommended to keep the
-polling interval above 1 ms in modern platforms at the time of writing.
-
-|
-
-Disabling runtime auto-suspend
---------------------------------
-
-When the HLOS detects that there has been no communication with the
-slave for a defined amount of time and the slave is idled and in standby
-state, then it can initiate suspend of the slave. Sometimes, the slave
-may be performing some tasks that don't require communication with the
-HLOS and does not wish to enter suspend. Or, it may be useful to
-temporarily disable auto-suspend while debugging some errors.
-
-Linux
-^^^^^^^
-
-The runtime suspend feature can be enabled or disabled by writing 'auto'
-or 'on' to the device's 'control' power field. The default is enabled.
-First, find the slave you want to disable (e.g.
-``cat /debug/remoteproc/remoteproc0/name``) and then echo "on" to the
-device's "control" power field.
-
-For example, if "remoteproc0" is the core you want to disable:
-
-::
-
-    target# echo "on" > /sys/bus/platform/devices/58820000.ipu/power/control
-
-SYS/BIOS
-^^^^^^^^^
-
-Alternatively, the slave can choose to deny the runtime suspend request,
-preventing suspend. To prevent the slave from suspending, add the
-`IpcPower_hibernateLock() <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_ipc_power_8h.html#aef7ede8453ad5a6a52623188c412f2fc>`__
-call to the slave software. When you wish to allow suspend again, call
-`IpcPower_hibernateUnlock() <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_ipc_power_8h.html#a2aa7348faba4bccb24da503fed3274f9>`__.
-As long as the lock is held, the slave will deny all suspend requests
-from the HLOS.
-
-::
-
-    IpcPower_hibernateLock();
-    ...
-    // Perform tasks
-    ...
-    IpcPower_hibernateUnlock();
-
-In this case, it is not necessary to also disable auto-suspend from the
-HLOS.
-
-QNX
-^^^^
-
-Runtime auto-suspend is not supported in QNX.
-
-|
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_BenchMarking.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_BenchMarking.rst
deleted file mode 100644
index 25f8ccea3..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_BenchMarking.rst
+++ /dev/null
@@ -1,347 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_BenchMarking
-
-
-RTOS IPC Benchmark applications in SDK
---------------------------------------
-
-Processor SDK RTOS includes a ping_benchmark_example under processor_sdk_rtos_<platform>_<version>/demos/ipc-examples/ping_benchmark_example.
-This example shows multiple cores running RTOS communicating with each other through the IPC MessageQ API.
-The example measures and displays the round trip delay numbers for the IPC. Note the main example sends multiple messages from each of the cores, with all the cores sending messages simultaneously.
-The example can be built with option to just R5F0 as the originator and all the other cores just respond back with reply.
-
-Build
-^^^^^^^
-The example can be built by running the top level make from the processor_sdk_rtos_<platform>_<version> directory.
-
-Linux Host
-""""""""""
-::
-
-	cd processor_sdk_rtos_<platform>_<version>
-	make sdk_ipc_examples_all
-
-Windows Host
-""""""""""""
-
-cd processor_sdk_rtos_<platform>_<version>
-setupenv.bat
-gmake sdk_ipc_examples_all
-
-Once the build commands are executed, the binaries will be in their respective directories as follows.
-
-AM65X:
-
-::
-
-	Host A53: ./demos/ipc-examples/ping_benchmark_example/hosta53/bin/am65xx_evm/release/server_host.xa53fg
-	R5F-0:    ./demos/ipc-examples/ping_benchmark_example/r5f-0/bin/am65xx_evm/release/server_r5f-0.xer5f
-	R5F-1:    ./demos/ipc-examples/ping_benchmark_example/r5f-1/bin/am65xx_evm/release/server_r5f-1.xer5f
-
-
-And also the R5F0 only as sender images are here:
-
-::
-
-	Host A53: ./demos/ipc-examples/ping_benchmark_example/hosta53/bin/am65xx_evm/app_r5f0_only/release/server_host.xa53fg
-	R5F-0:    ./demos/ipc-examples/ping_benchmark_example/r5f-0/bin/am65xx_evm/app_r5f0_only/release/server_r5f-0.xer5f
-	R5F-1:    ./demos/ipc-examples/ping_benchmark_example/r5f-1/bin/am65xx_evm/app_r5f0_only/release/server_r5f-1.xer5f
-
-
-Also the SBL bootable images can be created by using the following commands
-
-Linux Host:
-
-::
-
-	make sdk_ipc_examples_app
-	make sdk_ipc_examples_app_r5f0_only
-
-Windows host:
-
-::
-	gmake sdk_ipc_examples_app
-	gmake sdk_ipc_examples_app_r5f0_only
-
-The application images will be located under:
-
-::
-
-	demos/ipc-examples/ping_benchmark_example/output.appimage
-	demos/ipc-examples/ping_benchmark_example/am65xx_evm/app_r5f0_only/output.appimage
-
-Run
-^^^^
-
-Pre-requisites: Bootable SD card loaded with SBL.
-
-AM65x
-""""""""""
-
-Load the app from this directory into the SD card with filename "app" and load into the EVM to boot.
-(Note: Make sure the UART port is connected to the terminal to observe the application prints)
-
-On running the application the benchmark data will be displayed on the UART port.
-
-For the main application the benchmark data will be displayed on UART port0:
-
-::
-
-	 Overhead:34
-
-	 Payload Size: 176
-
-	 Proc id 0, Delta count: 3829025
-
-	 Proc id 0 to Proc Id 0: Average Roundtrip time is: 19 us
-
-	 Proc id 1, Delta count: 8920087
-
-	 Proc id 0 to Proc Id 1: Average Roundtrip time is: 44 us
-
-	 Proc id 2, Delta count: 7091251
-
-	 Proc id 0 to Proc Id 2: Average Roundtrip time is: 35 us
-
-	 AppHost_run: Test Passed
-
-	 MainHost_appTskFxn: Test Passed
-
-
-For the R5F0 app only build, the benchmark data will be displayed on UART port1:
-
-::
-
-	 Overhead:144
-
-	 Payload Size: 176
-
-	 Proc id 0, Delta count: 8460883
-
-	 Proc id 1 to Proc Id 0: Average Roundtrip time is: 42 us
-
-	 Proc id 1, Delta count: 1046906
-
-	 Proc id 1 to Proc Id 1: Average Roundtrip time is: 5 us
-
-	 Proc id 2, Delta count: 6297313
-
-	 Proc id 1 to Proc Id 2: Average Roundtrip time is: 31 us
-
-	 AppR5f_0_run: Test Passed
-
-Linux Benchmark test: MessageQBench
------------------------------------
-
-The application utilizes the IPC 3.x stack to communicate from the main
-processor to the slave core via the MessageQ interface. The application
-measures the time taken to accomplish this. The MessageQBench binaries
-are included in the Linux file system and they are located in:
-
-|   Linux Application: /usr/bin/MessageQBench
-|   DSP binary:        /lib/firmware/ipc/ti_platforms_[platform]_core0/messageq_single.xe66
-|
-
-The MessageQBench can be built following the instruction described in
-the below Build section or using high level build in Linux Processor
-SDK as described in `IPC Quick Start Guide
-<http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/
-Foundational_Components_IPC.html#ipc-quick-start-guide>`__
-
-Build
-^^^^^^^
-
-This section outlines the build process for the MessageQBench
-application.
-
-Linux
-"""""""
-
-To build the application, follow the `Linux IPC Install
-Guide <index_Foundational_Components.html#linux-install-guide>`__ to configure and build the
-Linux-side applications for your device. You'll also need to build the
-corresponding BIOS side of IPC as indicated in the guide.
-
-QNX
-"""""
-
-To build the application, follow the `QNX IPC Install
-Guide <index_Foundational_Components.html#qnx-install-guide>`__ to configure and build the
-QNX-side test applications for your device. You'll also need to build
-the corresponding BIOS side of IPC as indicated in the guide.
-
-Android
-"""""""""
-
-The IPC development sources should be included in the Android Filesystem
-(AFS) indicated by the manifest provided in your AFS distribution. The
-sources are located in $(AFS_ROOT)/hardware/ti/ipc directory.
-
-To build the IPC applications, follow the same procedure to build the
-entire AFS. If you want to specifically build the IPC content, you can
-issue the following command to build the needed IPC libraries and
-application from the top your AFS installation (must configure and pick
-the correct :command:`lunch` target for your device).
-
-::
-
-    $buildhost make -j messageQApp \
-                         messageQBench \
-                         messageQMulti \
-                         nameServerApp \
-                         ping_rpmsg \
-                         lad_dra7xx \
-                         libmmrpc
-
-To build the corresponding SysBios side of IPC follow the `IPC Install
-Guide <index_Foundational_Components.html#linux-install-guide>`__.
-
-Run
-^^^^^
-
-This section illustrates the steps to run the MessageQBench application.
-
-Linux/Android
-"""""""""""""""
-
-The built IPC libraries and applications must be copied (installed) onto
-the devices filesystem. The LAD Daemon must be running and application's
-corresponding slave-side binary must be loaded via the remoteproc kernel
-module. The slave-side binary (messageq_single.x<suffix>), is located in
-the $(IPC_ROOT)/packages/ti/ipc/tests/bin/<device> directory.
-
-|
-| Detailed information regarding this can be found in the **Installing
-  Tests** and **IPC Daemons and Drivers** section of the `IPC Install
-  Guide <index_Foundational_Components.html#linux-install-guide>`__.
-
-|
-
-.. note::
-  Android users - The Android binaries (lad_dra7xx and messageQBench) will
-  be located in the $(AFS_ROOT)/out/target/product/<device>/system/binary
-  directory. There are also dependent libraries (libtiipc.so,
-  libtiipcutils.so, and libtiipcutils_lad.so) in the
-  $(AFS_ROOT)/out/target/product/<device>/system/lib directory. These
-  files need to be copied to your device filesystem for execution.
-
-|
-| Once the LAD daemon is running and the slave core binary has been
-  loaded. You can execute the following to run the application:
-
-::
-
-    target# /usr/bin/MessageQBench
-
-The application will exchange 1000 messages with a payload of 8 by
-default with an average round trip time per message. The following is
-the usage parameters for the application.
-
-::
-
-    Usage: ./bin/MessageQBench [<numLoops>] [<payloadSize>] [<ProcId>]
-           Defaults: numLoops: 1000; payloadSize: 8, ProcId: 1
-
-QNX
-"""""
-
-The built IPC libraries and test applications must be copied (installed)
-onto the devices filesystem. The IPC resource manager must be running
-and the application's corresponding slave-side binary must be loaded
-using the resource manager. The slave-side binary
-(messageq_single.x<suffix>), is located in the
-$(IPC_ROOT)/packages/ti/ipc/tests/bin/<device> directory.
-
-|
-| Detailed information regarding this can be found in the **Installing
-  Tests in QNX**, **IPC resource manager** and **Running Test
-  Applications** sections of the `IPC Install
-  Guide <index_Foundational_Components.html#qnx-install-guide>`__.
-
-Once the IPC resource manager is running and the slave core binary has
-been loaded. You can execute the following to run the application:
-
-::
-
-    target#  tests/MessageQBench 1000 8 <slave core procId>
-
-The application will exchange 1000 messages with a payload of 8 with the
-core identified by 'procId' and show an average round trip time per
-message. The following shows the usage parameters for the application.
-
-::
-
-    Syntax:
-      MessageQBench [<numLoops>] [<payloadSize>] [<procId>]
-
-
-IPC Performance
-----------------
-
-The performance numbers in this section are gathered using Processor SDK
-5.2 release.
-
-IPC Average Round Trip Time
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The average round trip time is measured using MessageQBench which calculates
-the time for sending 1000 messages from the main processor to slave core and
-divided by the number of messages sent (1000).
-
-Average Round Trip Time (ARTT) for K2H/E/G and OMAP-L138 EVMs
-
-.. csv-table::
-    :header: "PLSDK 5.2","K2H","K2E","K2G","OMAP-L138"
-
-    "CPU Speed","1.2GHz","1.4GHz","1GHz","456MHz"
-    "ARTT (us)","115","68","81","904"
-    "ARTT @ 1GHz (us)","121","94","81","N/A"
-
-Table: IPC Average Round Trip Time (ARTT)
-
-.. note::
-   The MessageQBench is a user space application which needs to call into
-   kernel space and involves linux context switch, process priority, and
-   multiple copies during the delivery of a message. Each message may show
-   different latency deviated from the average round trip time.
-
-
-Throughput
-^^^^^^^^^^^^^^
-
-Throughput benchmark uses a max transmit window of 130 outstanding messages
-to get the maximum throughput. Beyond the max transit window of 130, there
-won't be enough resource to allocate additional messages before the
-resource is returned by the outstanding messages. In this case, the
-benchmark application will fail to run. Different payload sizes from 8 bytes
-to max of 448 bytes are measured for each direction, and the numbers apply to
-either direction. The throughput are measured with ARM/DSP running at 1 GHz.
-
-Throughput for K2H/E/G and OMAP-L138 EVMs
-
-.. csv-table::
-    :header: "Payload (Bytes)","K2H (MB/s)","K2E (MB/s)","K2G (MB/s)","OMAP-L138 (MB/s)"
-
-    "8","0.234","0.442","0.265","0.065"
-    "16","0.362","0.681","0.333","0.099"
-    "32","0.599","1.078","0.548","0.163"
-    "64","1.073","1.928","1.101","0.286"
-    "128","1.833","3.57","2.116","0.524"
-    "256","3.288","6.693","5.855","0.988"
-    "448(Max)","5.038","11.056","18.967","1.676"
-
-Table: IPC Throughput
-
-IPC Throughput CPU Utilization
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The CPU utilization is measured using max payload size of 448 bytes with
-transmit window of 130 messages.
-
-.. csv-table::
-    :header: "","K2H (1.2GHz)","K2E (1.4GHz)","K2H (1GHz)","K2E (1GHz)","K2G","OMAP-L138"
-
-    "CPU Utilization","42%","47%","44%","49%","89.5%","100%"
-
-Table: IPC Throughput CPU Utilization
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_FAQ_for_Keystone_Devices.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_FAQ_for_Keystone_Devices.rst
deleted file mode 100644
index 954903f92..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_FAQ_for_Keystone_Devices.rst
+++ /dev/null
@@ -1,446 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_FAQ_for_Keystone_Devices
-
-Overview
-^^^^^^^^^^
-
-This wiki article is a collection of frequently asked questions (FAQ) on
-IPC on Keystone family of devices , along with some useful collateral
-and software reference links. 
-
-|
-
-Guide on building and running the IPC examples of Processor SDK
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-| This guide will give step by step instruction on how to bring up the
-  target EVMs and how to run the run the IPC examples of processor SDK
-  on target EVM.
-
-| Download the guide from :download:`Keystone II IPC Examples </files/Guide_Keystone_II_IPC_examples_.zip>`
-
-| This guide will have steps on
-| 1. Flashing the u-boot and boot u-boot.
-| 2. Flashing the UBIFS image ( Linux and root filesystem ) into NAND
-  and boot Linux.
-| 3. Building the IPC package.
-| 4. Building and running the IPC examples ( ex02_MessageQ,
-  ex44_compute, ex45_host and ex46_graph ) on target EVM.
-| 5. Real-time debugging on the DSP side programs using CCS.
-
-|
-
-Keystone IPC Frequently Asked Questions (FAQ)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. rubric:: Q: Where do I look for the list of IPC API reference
-   document?
-   :name: q-where-do-i-look-for-the-list-of-ipc-api-reference-document
-
-**Ans:**
-
-Please visit :
-http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/index.html
-
-The IPC product contains the following APIs:
-
-::
-
-    •GateMP (BIOS, Linux, QNX)
-    •HeapBufMP (BIOS)
-    •HeapMemMP (BIOS)
-    •HeapMultiBufMP (BIOS)
-    •Ipc (BIOS, Linux, QNX)
-    •ListMP (BIOS)
-    •MessageQ (BIOS, Linux, QNX)
-    •MultiProc (BIOS, Linux, QNX)
-    •NameServer (BIOS, Linux, QNX)
-    •Notify (BIOS)
-    •SharedRegion (BIOS)
-    •IpcPower (BIOS)
-
-Some environments also provide a "Multimedia RPC" interface. Currently
-this is limited to OMAP5 and DRA7XX devices running an HLOS.
-
-::
-
-    •MmRpc (Linux, QNX)
-    •MmServiceMgr (BIOS)
-
-.. rubric:: Q: How to re-build the IPC package and its libraries?
-   :name: q-how-to-re-build-the-ipc-package-and-its-libraries
-
-**Ans:**
-
-Actually, the user guide which comes along with the IPC package ( under
-docs folder) is sufficient to build the IPC package. However, we have
-extracted below steps from user guide. For building IPC package, you can
-use either Cygwin/Command-line utility in windows machine or Linux
-machine. This cannot be built through CCS.
-
-| 1. Install the mcsdk_bios_3_xx_xx_xx which will install the IPC
-  package version, ipc_3_xx_xx_xx
-| 2. Go to the directory where the IPC package is installed.
-| 3. Open the products.mak file and make sure the following parameters
-  are set appropriately.
-
-| For example:- ( For ipc-linux build )
-
-::
-
-           PLATFORM = TCI6638
-           DESTDIR = /opt/ti/ipc_3_xx_xx_xx/ipc_3_xx_xx_xx_lib
-
-::
-
-           XDC_INSTALL_DIR = /opt/ti/xdctools_3_xx_xx_xx
-           BIOS_INSTALL_DIR = /opt/ti/bios_6_xx_xx_xx
-           ti.targets.elf.C66 = /opt/ti/ccsv5/tools/compiler/C6000_7.4.5
-
-| 4. $cd /opt/ti/ ipc_3_xx_xx_xx
-| 5. $make distclean
-| 6. $make –f ipc-linux.mak config
-| 7. $make
-| 8. $make install
-
-|
-
-.. rubric:: Q: Is there any simple example to demonstrate IPC methods
-   like message Q or notify for Keystone-II ?
-   :name: q-is-there-any-simple-example-to-demonstrate-ipc-methods-like-message-q-or-notify-for-keystone-ii
-
-**Ans:**
-
-| Please look at the ex44_compute.zip
-  in :~/ti/ipc_3_3x_xx_xx/examples/TCI6638_linux_elf
-
-::
-
-          ~/ti/ipc_3_3x_xx_xx/examples$ ls
-          C6472_bios_elf C6A8149_bios_elf DRA7XX_android_elf DRA7XX_linux_elf makefile TCI6638_linux_elf
-          TI814X_bios_elf C6678_bios_elf dosrc.bat DRA7XX_bios_elf DRA7XX_qnx_elf OMAPL138_linux_elf TDA3XX_bios_elf
-
-Please refer the readme.txt to run and build the example according to
-the target used. For K2, use the cluster ID as 0 instead of 18.
-
-#. perl patchExec.pl 0 compute_dspN.xe66 compute_dspN_patched.xe66
-#. lad_tci6638 -r 8 -n 9 -b 0 -l log.txt
-
-|
-
-.. rubric:: Q: For Keystone II, is there any CCS based examples to
-   demonstrate a simple communication between ARM-DSP?
-   :name: q-for-keystone-ii-is-there-any-ccs-based-examples-to-demonstrate-a-simple-communication-between-arm-dsp
-
-**Ans:**
-
-No. We have only Image Processing Demo.
-
-In MCSDK 3.x, the ARM core only runs Linux kernel and User Space
-applications. There isn't any Linux application example using CCS and if
-any, it will be using Linux commands.
-
-.. rubric:: Q: In IPC packages, there are lot of test example(sample.c)
-   code given in the path: "~\ipc_3_3x_xx_xx\packages\ti\ipc\tests". But
-   there is only command line option to build the whole IPC package. No
-   option available to build the test examples individually. This is
-   time consuming to build the whole IPC package. Customers were asking
-   for CCS based environment to build and test as individual example for
-   both DSP and ARM side.
-   :name: q-in-ipc-packages-there-are-lot-of-test-examplesample.c-code-given-in-the-path-ipc_3_3x_xx_xxpackagestiipctests.-but-there-is-only-command-line-option-to-build-the-whole-ipc-package.-no-option-available-to-build-the-test-examples-individually.-this-is-time-consuming-to-build-the-whole-ipc-package.-customers-were-asking-for-ccs-based-environment-to-build-and-test-as-individual-example-for-both-dsp-and-arm-side.
-
-**Ans:**
-
-The IPC package has been developed to work on multiple platforms like
-Linux, Android, QNX and TI-RTOS(SYS/BIOS) so the command line build is
-selected which is common across all these platforms and we do not have
-CCS based projects for these examples.
-
-|
-
-.. rubric:: Q: For keystone-II devices, where do I find the source code
-   of the image processing demo and how to I re-build them? Using ARM
-   core as a master, DSP cores as slaves.
-   :name: q-for-keystone-ii-devices-where-do-i-find-the-source-code-of-the-image-processing-demo-and-how-to-i-re-build-them-using-arm-core-as-a-master-dsp-cores-as-slaves.
-
-**Ans:**
-
-Tested version : "mcsdk_bios_3_00_03_15". The Image processing demo was
-tested multiple times with this version and it works fine.
-
-The image processing demo source code can be found in below path.
-
-**PATH:** C:\ti\mcsdk_bios_3_0x_0x_0x\demos\image_processing\ipc (master,
-slave and common directories)
-
-**Building Slave Code:**
-The project can be imported into CCS and can be rebuilt.
-
-*For K2E:*
-“~\mcsdk_bios_3_0x_0x_0x\demos\image_processing\ipc\evm66ak2e\slave”
-
-*For K2K:*
-“~\mcsdk_bios_3_0x_0x_0x\demos\image_processing\ipc\evmtci6638k2k\slave”
-
-*For K2L:*
-“~\mcsdk_bios_3_0x_0x_0x\demos\image_processing\ipc\evmtci6630k2l\slave”
-
-**Building Master Code:**
-
-This can be built in the linux environment using the makefile provided
-at
-
-(~\mcsdk_bios_3_0x_0x_0x\demos\image_processing\ipc\evm66ak2x\master\make
-) which in turn uses the makefile located at
-~\mcsdk_bios_3_0x_0x_0x\demos\image_processing\ipc\master\src
-
-|
-
-.. rubric:: Q: How to import the slave code of Image processing demo and
-   how do I build it?
-   :name: qhow-to-import-the-slave-code-of-image-processing-demo-and-how-do-i-build-it
-
-**Ans:**
-
-Refer the screenshot below in which the correct path should be provided
-to pick up the project and its sources. Note that the option for “Copy
-projects into work space" should be unchecked.
-
-.. Image:: /images/ImportPjt.jpg
-
-|
-
-In the project explorer screen, check whether you are able to see the
-folders, slave --> src --> \*.c files.... Right click on the project and
-give build.
-
-.. Image:: /images/Sourcefilepjt.jpg
-
-.. rubric:: Q: After building the slave code of the Image processing
-   demo using CCS, where it needs to be replaced in the linux file
-   system?
-   :name: q-after-building-the-slave-code-of-the-image-processing-demo-using-ccs-where-it-needs-to-be-replaced-in-the-linux-file-system
-
-**Ans:**
-
-Take the binary file, image_processing_evmtci66xxk2x_slave.out and
-replace it in the path target Linux filesystem,
-“/usr/share/matrix-gui-2.0/apps/demo_imageproc/bin/"
-
-.. rubric:: Q:  While building the ARM(master) side code of Image
-   processing demo, I see a compilation error message about Std.h as
-   below when I make it with or without BUILD_LOCAL=true.
-   :name: q-while-building-the-armmaster-side-code-of-image-processing-demo-i-see-a-compilation-error-message-about-std.h-as-below-when-i-make-it-with-or-without-build_localtrue.
-
-| *Error:*
-| ***user@ubuntu:~/ti/mcsdk_bios_3_0x_0x_0x/demos/image_processing/ipc/evm66ak2x/master$***
-  make
-
-| *make[1]: Entering directory
-  \`/home/user/ti/mcsdk_bios_3_0x_0x_0x/demos/image_processing/ipc/master/src'
-  mcip_mem_mgmt.c:53:24: fatal error: ti/ipc/Std.h: No such file or
-  directory #include <ti/ipc/Std.h> Compilation terminated.*
-
-| **Ans:**
-| There is an error in the Makefile. Make file needs to be updated for
-  including the appropriate search path for "Std.h". You will find it at
-  "../ti/ipc_3_3x_0x_0x/linux/include
-
-Update the Makefile located at
-"mcsdk_bios_3_0x_0x_0x\demos\image_processing\ipc\master\src\makefile"
-as below,
-
-| *For example:*
-
-::
-
-         IPC_INSTALL_DIR := /opt/ti/ipc_3_xx_0x_0x
-         CFLAGS  := -Wall -I$(COMMON_INC) -I$(MASTER_INC) -I$(IPC_INSTALL_DIR)/linux/include -I$(IPC_INSTALL_DIR)/packages -D_GNU_SOURCE
-
-.. rubric:: Q: While building the ARM(master) side code of Image
-   processing demo, I see a linker error message like below.
-   :name: q-while-building-the-armmaster-side-code-of-image-processing-demo-i-see-a-linker-error-message-like-below.
-
-| *Error:*
-| */usr/bin/ld: skipping incompatible
-  /opt/ti/ipc_3_35_01_07/examples/TCI6638_linux_elf
-  /ex44_compute_bkp/lib//libtitransportrpmsg.a when searching for
-  -ltitransportrpmsg
-  /usr/bin/ld: cannot find –ltitransportrpmsg*
-| usr/bin/ld: cannot find -ltiipcutils
-| collect2: error: ld returned 1 exit status
-| make: \**\* [../../master/image_processing_master.out] Error 1
-| root@e2e:/opt/ti/mcsdk_bios_3_0x_xx_xx/demos/image_processing/ipc/master/src#\ *
-  *
-
-| **Ans:**
-| For these errors, please make sure you already built the Whole IPC
-  package and installed the libraries such as transportrpmsg in a
-  destination directory. This destination directory should be given in
-  the makefile to find those libraries.
-
-| For example, in the makefile located at
-  mcsdk_bios_3_0x_xx_xx\demos\image_processing\ipc\master\src\makefile
-
-::
-
-        IPC_INSTALL_DIR := /opt/ti/ipc_3_3x_xx_xx
-
-        #The location where the libraries are installed after building the IPC package
-        SIPC_LINUX_DIR := /opt/ti/ipc_3_3x_xx_xx/IPC_Linux_libraries
-
-::
-
-        CROSS_COMPILE ?= arm-linux-gnueabihf-
-        CC            := $(CROSS_COMPILE)gcc
-        CFLAGS        := -Wall -I$(COMMON_INC) -I$(MASTER_INC) -I$(IPC_INSTALL_DIR)/linux/include -I$(IPC_INSTALL_DIR)/packages -D_GNU_SOURCE
-        LFLAGS        := -lpthread -L$(SIPC_LINUX_DIR)/ -ltitransportrpmsg -L$(SIPC_LINUX_DIR)/ -ltiipc -L$(SIPC_LINUX_DIR)/ -ltiipcutils
-
-|
-
-.. rubric:: Q: The Image processing demo does not work on the version of
-   MCSDK, V3.0x.xx.x on both the K2H and K2E EVMs. The earlier version
-   of MCSDK works on both the EVMs. Will it be fixed on next version?
-   :name: q-the-image-processing-demo-does-not-work-on-the-version-of-mcsdk-v3.0x.xx.x-on-both-the-k2h-and-k2e-evms.-the-earlier-version-of-mcsdk-works-on-both-the-evms.-will-it-be-fixed-on-next-version
-
-**Ans:**
-
-| Make sure the u-boot environments is set as below to work on MCSDK
-  3.x.
-
-::
-
-             u-boot# env default –f –a
-             u-boot# setenv mem_reserve 1536M
-             u-boot# saveenv
-
-|
-
-.. rubric:: Q: How to build and run the qmssIpcBenchmark on C6678 EVM?
-   :name: q-how-to-build-and-run-the-qmssipcbenchmark-on-c6678-evm
-
-**Ans:**
-
-**Hardware set up:**
-
-::
-
-      Set the boot mode dip switch to no boot/EMIF16 mode, Connect power and emulator to C6678 EVM.
-
-**Software setup:**
-1. After power ON the EVM, create and launch the target configuration
-file(.ccxml) for CCS debugging.
-
-2. Group Core 0 and Core 1 in CCS.
-
-3. Connect to both cores via the group.
-
-4. Load the evmc66xxl.gel to initialize the DDR. The GEL can be found in
-the "CCS install
-dir"\ccsv5\ccs_base_x.x.x.xxxxx\emulation\boards\evmc66xxl\gel
-directory. Once loaded execute the default setup script on each core. In
-the CCS menu go to Scripts->EVMC6678L Init
-Functions->Global_Default_Setup.
-
-5. Highlighting the Group in the CCS Debug window, load
-transport\ipc\examples\qmssIpcBenchmark\Debug\qmssIpcBenchmark_c66xx.out
-on each core
-
-6. Highlighting the Group in CCS Debug window, run the program in CCS on
-both cores simultaneously, qmssIpcBenchmark_c66xx will send messageQ
-messages between the cores via the QMSS transport. The messages will be
-used to measure the transport's performance. The test will be complete
-after the throughput (msg/s) has been calculated.
-
-.. Image:: /images/Qmss_IPC.png
-
-.. rubric:: Q: How can I build the qmssIpcbenchmark of pdk_C6678_1_1_2_x
-   pdk_C6678_1_1_2_x with release build configuration ?
-   :name: q-how-can-i-build-the-qmssipcbenchmark-of-pdk_c6678_1_1_2_x-pdk_c6678_1_1_2_x-with-release-build-configuration
-
-**Ans:**
-
-| Actually the option, "-mo -o3 -q -k -eo.o" works for building the
-  IPC-QMSS transport library in release mode and the option "-mo -g -q -k -eo.o"
-  works for building the IPC-QMSS transport library in debug mode.
-| But the common.bld script of IPC doesnot create a "release" folder. By
-  default it always creates the "debug" folder and dumps all the
-  binaries.
-| By tweaking the common.bld, release folder can be made and hence the
-  the IPC - qmssIpcBenchmark project can be built in release mode.
-| **How to change the Common.bld:**
-| 1. Go to C:\ti\ipc_3_00_xx_xx\packages\ti\sdo\ipc\build\Common.bld (
-  Note: Go to the IPC version you use for building the transport
-  library. Here, it refers to IPC version : 3.00.4.29)
-| 2. Modify
-| Line No:88 profiles[0] = "release";
-| Line No: 99 var libPath = "lib/ipc/release/";
-| 3. Build with option : -mo -o3 -q -k -eo.o in config.bld of transport
-  library located at
-  "..\ti\pdk_C6678_1_1_2_x\packages\ti\transport\ipc\qmss\transports"
-| 4. Now build qmssIpcBenchmark project.
-| Screenshot of the successful release build of qmssIpcBenchmark
-  project.
-.. Image:: /images/QMSSIPC_project1.png
-
-|
-
-.. rubric:: Q: How to re-build the IPC - QMSS transport library and
-   generate “ti.transport.ipc.qmss.transports.ae66” ?
-   :name: q-how-to-re-build-the-ipc---qmss-transport-library-and-generate-ti.transport.ipc.qmss.transports.ae66
-
-**Ans:**
-
-After installing PDK, go to path
-“~\ti\pdk_C6678_1_1_2_x\packages\ti\transport\ipc\qmss\transports”
-
-1. [Optional - Required for debug single stepping] Modify the transports
-config.bld file C66LE/BE.ccOpts.prefix to remove optimization and add
-symbolic debug
-
-::
-
-      From: "-mo -o3 -q -k -eo.o"
-      To: "-mo -g -q -k -eo.o"
-
-2. From a command prompt navigate to the
-pdk\packages\ti\transport\ipc\(qmss or srio) directory 3 Configure the
-XDCPATH environment variable with the BIOS and IPC install locations:
-
-::
-
-      set XDCPATH=c:\ti\bios_w_xx_yy_zz\packages\
-      set XDCPATH=%XDCPATH%;c:\ti\ipc_w_xx_yy_zz\packages\
-
-4 Configure the XDCCGROOT environment variable with the compiler install
-path (Using CGT 7.2.4 installed as part of CCS as an example)
-
-::
-
-      set XDCCGROOT=c:\ti\ccsv5\tools\compiler\c6000_7.2.4
-
-5 Add the XDC Tools to your system PATH
-
-::
-
-      set PATH=%PATH%;c:\ti\xdctools_w_xx_yy_zz\
-
-6 Clean the transport
-
-::
-
-      >xdc clean -PR .
-
-7 Build the transport
-
-::
-
-      >xdc -PR .
-
-If we try this option, we should be able to build in releasemode. Note:
-To allow single-step debug of the IPC and BIOS source rebuild the
-example projects with the following command added to the example's .cfg
-file BIOS.libType = BIOS.LibType_Debug; <--- here.
-
-.. Image:: /images/Qmss_transports.png
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_GateMP_Support_for_UIO_and_Misc_Driver.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_GateMP_Support_for_UIO_and_Misc_Driver.rst
deleted file mode 100644
index 15641faac..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_GateMP_Support_for_UIO_and_Misc_Driver.rst
+++ /dev/null
@@ -1,110 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_GateMP_Support_for_UIO_and_Misc_Driver
-
-Introduction
-^^^^^^^^^^^^^^^
-
-Starting in IPC 3.42, the GateMP module added support for accessing
-device memory without using /dev/mem. Instead of accessing /dev/mem, a
-uio driver for Shared Region 0 access and a misc driver to expose a
-hwspinlock user interface can be used. These drivers are added in the
-Android SDK and GLSDK kernels. This feature was added because in some
-environments, /dev/mem may not be accessible to the LAD.
-
-.. note::
-   There is no change to how LAD is launched in this case, and if the uio
-   and misc driver are not available in the kernel, it will fall back to
-   using /dev/mem.
-
-
-.. note::
-   This applies only to Linux/Android IPC.
-
-Config
-^^^^^^^
-
-Enable the uio and misc drivers in the kernel by enabling the following
-config options:
-
-CONFIG_HWSPINLOCK_USER=y
-CONFIG_UIO=y
-CONFIG_UIO_PDRV_GENIRQ=y
-Update your dts file to define the hwspinlocks being used by the misc
-driver. Must start from hwspinlock "0" and go up sequentially:
-
-::
-
-    gatemp {
-            compatible = "hwspinlock-user";
-            hwlocks = <&hwspinlock 0>,
-                      <&hwspinlock 1>,
-                      <&hwspinlock 2>,
-                      <&hwspinlock 3>,
-                      <&hwspinlock 4>,
-                      <&hwspinlock 5>,
-                      <&hwspinlock 6>,
-                      <&hwspinlock 7>,
-                      <&hwspinlock 8>,
-                      <&hwspinlock 9>;
-    };
-
-The hwspinlock configuration in the dts file MUST match the BIOS-side
-IPC HWSpinlock configuration. Configuration the BIOS-side IPC module by
-adding the following to your cfg file (where <N> is equal to the number
-of spinlocks in the dts listing):
-
-::
-
-     var HWSpinlock = xdc.useModule(‘ti.sdo.ipc.gates.GateHWSpinlock’);
-     HWSpinlock.numLocks = <N>;
-
-Update your dts file to add the UIO-based node for Shared Region 0
-(modify address and size so that it matches the Shared Region 0
-definition in the remote core image):
-
-Kernel 3.14-based releases:
-
-::
-
-    sr0 {
-            compatible = "generic-uio";
-            reg = <0xbfd00000 0x100000>;
-    };
-
-Kernel 4.4-based releases:
-
-::
-
-    sr0 {
-            compatible = "generic-uio";
-            reg = <0x0 0xbfb00000 0x0 0x100000>;
-    };
-
-.. note::
-   Make sure that the "compatible" property in the sr0 dts node matches the
-   UIO’s of_id string defined in the kernel command line.
-
-Append the following to the kernel's CONFIG_CMDLINE:
-
-::
-
-    uio_pdrv_genirq.of_id=generic-uio
-
-For example:
-
-::
-
-    CONFIG_CMDLINE="root=/dev/mmcblk0p2 rw console=ttyS0,119200 androidboot.console=ttyS0 init=/init rootfstype=ext4 rootwait drm.rnodes=1 snd.slots_reserved=1,1 androidboot.selinux=permissive androidboot.hardware=jacinto6evmboard uio_pdrv_genirq.of_id=generic-uio"
-
-.. note::
-   Changes for the command line are already present in the Android 6AM.1.0
-   release. For GLSDK, the command line comes from the bootargs set in the
-   uenv.txt file in the boot partition.
-
-Also, specific owner/group must be set for the following files:
-
--  /dev/uio0
--  /dev/hwspinlock
--  **Android:** /data/lad, /data/lad/LAD
--  **Linux:** /tmp/LAD
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_BIOS.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_BIOS.rst
deleted file mode 100644
index 9b1cb358a..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_BIOS.rst
+++ /dev/null
@@ -1,140 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Install_Guide_BIOS
-
-Introduction
-^^^^^^^^^^^^^
-
-Inter/Intra Processor Communication (IPC) is a product designed to
-enable communication between processors in a multi-processor
-environment. Features of IPC include message passing, multi-processor
-gates, shared memory primitives, and more.
-
-IPC is designed for use with processors running SYS/BIOS applications.
-This is typically an ARM or DSP. IPC includes support for High Level
-Operating Systems (HLOS) like Linux, as well as the SYS/BIOS RTOS. The
-breadth of IPC features supported in an HLOS environment is reduced in
-an effort to simplify the product.
-
-Install
-^^^^^^^^^
-
-IPC is often distributed and installed within a larger SDK. In those
-cases, no installation is required.
-
-Outside of an SDK, `IPC can be downloaded
-here <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/index.html>`__,
-and is released as a zip file. To install, simply extract the file.
-
-::
-
-    buildhost$ unzip ipc_<version>.zip
-
-This will extract the IPC product in a directory with its product name
-and version information (e.g. **c:/ti/ipc_<version>**)
-
-.. note::
-  -  This document assumes the IPC install path to be the user's home
-     directory on a Linux host machine (**/home/<user>**) or the user's
-     main drive on a Windows host machine (**C:\\**). The variable
-     **IPC_INSTALL_DIR** will be used throughout the document. If IPC was
-     installed at a different location, make appropriate changes to
-     commands.
-  -  Some customers find value in archiving the released sources in a
-     configuration management system. This can help in identifying any
-     changes made to the original sources - often useful when updating to
-     newer releases.
-
-Build
-^^^^^^^
-
-The IPC product often comes with prebuilt libraries, so rebuilding them
-isn't necessary. The IPC product downloads contain prebuilt libraries,
-and when provided with an SDK, IPC is typically rebuilt to contain only
-libraries appropriate for the SDK.
-
-However, if you want to rebuild its libraries, IPC provides GNU
-makefile(s) at the base of the product. This section describes the steps
-required to rebuild the IPC libraries.
-
-.. note::
-  GNU make version 3.81 or greater is required. The XDC tools (provided
-  with most SDKs and CCS distributions) includes a pre-compiled version of
-  GNU make 3.81 in $(XDC_INSTALL_DIR)/gmake.
-
-products.mak
-""""""""""""""
-
-IPC contains a **products.mak** file at the root of the product that
-specifies the necessary paths and options to build IPC for the various
-OS support.
-
-Edit **products.mak** and set the following variables:
-
-.. note::
-   Please make sure the complete path is specified. (e.g) Don't use ~ in the path specified.
-
--  **XDC_INSTALL_DIR** - Path to TI's XDCTools installation
--  **BIOS_INSTALL_DIR** - Path to TI's SYS/BIOS installation
--  **ti.targets.<device target and file format>** - Path to TI toolchain
-   for the device.
-
-   -  Set only the variables to the targets your device supports to
-      minimize build time.
-
--  **gnu.targets.arm.<device target and file format>** - Path to GNU
-   toolchain for the device.
-
-   -  Set only the variables to the targets your device supports to
-      minimize build time.
-
--  **PLATFORM** - (Optional) platform for which to build executables
-
-   -  Introduced in IPC 3.10. Prior releases build executables for
-      **all** platforms based on that targets/toolchains set above
-   -  If not set, only libraries will be built (not executables)
-
-.. note::
-  The versions used during validation can be found in the IPC Release
-  Notes provided in the product.
-
-ipc-bios.mak
-"""""""""""""
-
-IPC is built with a GNU makefile. After editing **products.mak**, issue
-the following command:
-
-::
-
-    <buildhost> make -f ipc-bios.mak all
-
-Based on the number of targets you're building for, this may take some
-time.
-
-Examples
-^^^^^^^^^^
-
-The IPC product contains an examples/archive directory with
-device-specific examples. Once identifying your device, the examples can
-be unzipped anywhere on your build host. Typically once unzipped, the
-user edits the example's individual **products.mak** file and simply
-invokes **make**.
-
-.. note::
-  A common place to unzip the examples is into the
-  **IPC_INSTALL_DIR/examples/** directory. Each example's **products.mak**
-  file is smart enough to look up two directories (in this case, into
-  **IPC_INSTALL_DIR**) for a master **products.mak** file, and if found it
-  uses those variables. This technique enables users to set the dependency
-  variables in one place, namely **IPC_INSTALL_DIR/products.mak**.
-
-Each example contains a **readme.txt** with example-specific details.
-
-See Also
-^^^^^^^^^^
-
--  `IPC 3.x <index_Foundational_Components.html#ipc-3-x>`__
--  `IPC Users Guide <index_Foundational_Components.html#ipc-user-guide>`__
--  `IPC 3.x FAQ <index_Foundational_Components.html#ipc-faq>`__
--  `IPC Install Guide Linux <index_Foundational_Components.html#linux-install-guide>`__
--  `IPC Install Guide QNX <index_Foundational_Components.html#qnx-install-guide>`__
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_Linux.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_Linux.rst
deleted file mode 100644
index a462ddbe6..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_Linux.rst
+++ /dev/null
@@ -1,512 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Install_Guide_Linux
-
-Introduction
-^^^^^^^^^^^^^
-
-Inter/Intra Processor Communication (IPC) is a product designed to
-enable communication between processors in a multi-processor
-environment. Features of IPC include message passing, multi-processor
-gates, shared memory primitives, and more.
-
-IPC is designed for use with processors running SYS/BIOS applications.
-This is typically an ARM or DSP. IPC includes support for High Level
-Operating Systems (HLOS) like Linux, as well as the SYS/BIOS RTOS. The
-breadth of IPC features supported in an HLOS environment is reduced in
-an effort to simplify the product.
-
-Install
-^^^^^^^^
-
-IPC is often distributed and installed within a larger SDK. In those
-cases, no installation is required.
-
-Outside of an SDK, `IPC can be downloaded
-here <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/index.html>`__,
-and is released as a zip file. To install, simply extract the file.
-
-::
-
-    buildhost$ unzip ipc_<version>.zip
-
-This will extract the IPC product in a directory with its product name
-and version information (e.g. **c:/ti/ipc_<version>**)
-
-.. note::
-
-  -  This document assumes the IPC install path to be the user's home
-     directory on a Linux host machine (**/home/<user>**) or the user's
-     main drive on a Windows host machine (**C:\\**). The variable
-     **IPC_INSTALL_DIR** will be used throughout the document. If IPC was
-     installed at a different location, make appropriate changes to
-     commands.
-  -  Some customers find value in archiving the released sources in a
-     configuration management system. This can help in identifying any
-     changes made to the original sources - often useful when updating to
-     newer releases.
-
-Build
-^^^^^^^^
-
-The IPC product often comes with prebuilt SYS/BIOS-side libraries, so
-rebuilding them isn't necessary. The Linux-side user libraries may also
-be provided prebuilt, but customers often want to change the
-configuration (e.g. static, dynamic).
-
-IPC provides GNU makefile(s) to rebuild all its libraries at the base of
-the product, details are below.
-
-.. note::
-  GNU make version 3.81 or greater is required. The XDC tools (provided
-  with most SDKs and CCS distributions) includes a pre-compiled version of
-  GNU make 3.81 in $(XDC_INSTALL_DIR)/gmake.
-
-products.mak
-""""""""""""""
-
-IPC contains a **products.mak** file at the root of the product that
-specifies the necessary paths and options to build IPC for the various
-OS support.
-
-Edit **products.mak** and set the following variables:
-
--  Variables used by **both Linux-side and BIOS-side** build scripts
-
-   -  **PLATFORM** - (Optional) Device to build for
-
-      -  To find the supported list of platforms, run: **./configure
-         --help**
-      -  If not set, Linux libraries and executables for all supported
-         platforms will be built.
-      -  If not set, BIOS libraries for all toolchains specified (see
-         below) will be built, but no BIOS-side executables will be
-         built.
-
-         -  BIOS-side builds started leveraging this variable in IPC
-            3.10. Prior releases built BIOS-side executables for **all**
-            supported platforms based on that targets/toolchains set
-            above (which can take a while!)
-
--  Variables used by **Linux-side** build scripts
-
-   -  **TOOLCHAIN_INSTALL_DIR** - Path to the devices ARM Linux
-      cross-compiler toolchain
-   -  **TOOLCHAIN_LONGNAME** - Long name of the devices toolchain (e.g.
-      arm-none-linux-gnueabi)
-   -  **KERNEL_INSTALL_DIR** - Location of your Linux kernel
-      installation
-
-      -  In old releases, this variable was optional, and only needed
-         for platforms that support the MmRpc API (e.g. OMAP5, DRA7XX).
-         In IPC 3.00.04, 3.10.02, and 3.20+, all platforms began
-         requiring this variable to interrogate your kernel's version
-         (via KERNEL_INSTALL_DIR/linux/version.h) and accommodate
-         different kernels.
-
-   -  **DRM_PREFIX** - (Optional) Location of your libdrm installation,
-      used by some MmRpc tests
-
-      -  This is only used by MmRpc tests, and therefore only should be
-         set for platforms that support the MmRpc API
-      -  If set, additional MmRpc tests may be built.
-
-   -  **CMEM_INSTALL_DIR** - (Optional) Path to TI Linux Utils package
-      to locate the pre-built
-      `CMEM <http://processors.wiki.ti.com/index.php/Linux_Utils_Overview>`__
-      libraries used by some MessageQ tests
-
-      -  If set, additional test applications for select platforms may
-         be built.
-
--  Variables used by **BIOS-side** build scripts
-
-   -  **XDC_INSTALL_DIR** - Path to TI's XDCTools installation (e.g.
-      **c:/ti/xdctools_<version>**)
-   -  **BIOS_INSTALL_DIR** - Path to TI's SYS/BIOS installation (e.g.
-      **c:/ti/bios_<version>**)
-   -  **ti.targets.<device target and file format>** - Path to TI
-      toolchain for the device. (e.g.
-      **c:/ti/CCS/ccsbase/tools/compiler/c6000_<version>**)
-
-      -  Set only the variables to the targets your device supports to
-         minimize build time.
-
-.. note::
-  The specific versions of dependent components can be found in the IPC
-  Release Notes, provided in the product.
-
-ipc-linux.mak
-""""""""""""""""
-
-The Linux-side build is provided as a GNU Autotools (Autoconf, Automake,
-Libtool) project. If you are familiar with Autoconf GNU projects, you
-can proceed with using the **./configure** script directly to
-cross-compile the Linux user libraries and tests.
-
-For those that require some assistance, the IPC package provides a GNU
-makefile (**ipc-linux.mak**) to configure the Linux-side build, using
-the options and component paths set in the **products.mak** file. To
-configure the build using these files, issue the following command:
-
-::
-
-    <buildhost> make -f ipc-linux.mak config
-
-There are few additional target goals provided in the ipc-linux.mak file
-for commonly used configurations. These goals include:
-
--  config - (Default) Configure both static and shared (dynamic) Linux
-   IPC user libraries. Executables (e.g. lad and tests) link against the
-   shared libraries.
--  config-static - Configure static only libraries and executables.
--  config-shared - Configure shared (dynamic) only libraries and
-   executables.
-
-Once the 'config' is complete, and the autotools-generated Makefile has
-been created, you can build the Linux side of IPC by issuing the
-following:
-
-::
-
-    <buildhost> make
-
-You can also specify a PLATFORM to (re)configure for on the command line
-which overrides any options set in the products.mak file as follows:
-
-::
-
-      <buildhost> make -f ipc-linux.mak config PLATFORM=omapl138
-      <buildhost> make
-
-Note that before reconfiguring for a new Linux toolchain or platform,
-the autotools-generated files should be clean(ed):
-
-::
-
-      <buildhost> make distclean
-
-|
-
-ipc-bios.mak
-""""""""""""""
-
-The SYS/BIOS-side IPC is built with a GNU makefile. After editing
-**products.mak**, issue the following command:
-
-::
-
-    <buildhost> make -f ipc-bios.mak all
-
-Based on the number of targets you're building for, this may take some
-time.
-
-.. note::
-  The BIOS-side libraries often come pre-built, so in many cases,
-  rebuilding the BIOS-side is not necessary. Some reasons you may want to
-  rebuild:
-
--  Your distribution of IPC **didn't** come with the necessary pre-built
-   libraries
--  You intend to run the 'test' executables (which often don't come
-   pre-built)
--  You want to use a specific toolchain or dependency version
--  You want to tune some of the compile options
-
-Run
-^^^^^
-
-The IPC product provides a way to install (copy) the necessary IPC
-executables and libraries onto the device's target file-system to
-simplify the execution of the applications.
-
-Configuring Kernel
-"""""""""""""""""""
-
-The IPC product provides a set of Linux kernel patches that need to be
-applied to the different device supported kernels to add necessary
-kernel support. The patches are located in the linux/patches directory
-of the IPC installation.
-
-OMAP-L138
-''''''''''
-
-The kernel for the OMAP-L138, can be obtained from `Gitorious
-linux-davinci project <http://gitorious.org/linux-davinci>`__.
-
-The patches apply to the following commit id:
-**595ab716fc6e648b7dc79a58a01917ebb67b9508**
-
-The specific patches needed for this kernel can be found in the
-**linux/patches/3.8.0** of your IPC installation.
-
-Once the patches are applied, there are a few key config parameters
-needed for rpmsg and socket driver to build/work.
-
-CONFIG_REMOTEPROC=m
-CONFIG_DA8XX_REMOTEPROC=m
-CONFIG_RPMSG=m
-CONFIG_VIRTIO=m
-It is also recommended to compile a Linux kernel with the debugfs
-facility
-
-CONFIG_DEBUG_FS=y
-Re-build the kernel. For example:
-
-::
-
-    buildhost$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-  uImage
-
-You will also need to re-build the kernel modules and install them on
-your target's file system. For example:
-
-::
-
-    buildhost$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-  modules
-    buildhost$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- INSTALL_MOD_PATH=<target filesystem> modules_install
-
-Kernel Boot-up Parameters
-""""""""""""""""""""""""""
-
-IPC requires an argument to be passed to the Linux kernel during boot up
-to properly run the tests. The remote processor(s) (rproc) memory
-location needs to be set.
-
--  For example,
-
-::
-
-    bootargs console=ttyS2,115200n8 root=/dev/nfs nfsroot=HOST:nfs_root,nolock rw ip=dhcp rproc_mem=16M@0xC3000000
-
-*This is just an example, bootargs may vary depending on available setup*
-Depending on the memory map used in the final system configuration,
-the memory to be reserved for rproc usage may differ.
-
-Installing Tests
-""""""""""""""""""
-
-To assemble the IPC test executables and libraries into a directory
-structure suitable for running on the target's file-system, issue the
-following command in the IPC install directory:
-
-::
-
-    buildhost$ make install prefix=<target filesystem>/usr
-
-*Depending on you target's filesystem directory privileges, you may be
-required to run **sudo make install** to properly install the files
-*
-
-.. note::
-  The test executables and libraries will be installed in the location
-  path set by the **prefix** variable. If you are installing directly on a
-  host mounted Network Filesystem(NFS), make sure to specify **usr** at
-  the end of the **prefix** variable path. As with other variables, you
-  can override this on the command line:
-  ::
-
-    buildhost$ sudo make install prefix=<target filesystem>/usr
-
-|
-
-The remote processor's applications will be loaded via the remote_proc
-kernel module but they need to reside on the devices target filesystem
-in **/lib/firmware** directory. The location of the remote core
-application within the IPC product various based on device.
-
-Slave Binaries
-''''''''''''''''
-
-The slave-side test binaries, once built, are found in your
-IPC_INSTALL_DIR/packages/ti/ipc/tests/bin/<platform>_<core> directory.
-
-Copy the appropriate slave-side executable onto the devices target
-filesystem into the **/lib/firmware** directory. For example, OMAP-L138
-developers would do this:
-
-::
-
-    buildhost$ cp IPC_INSTALL_DIR/packages/ti/ipc/tests/bin/ti_platforms_evmOMAPL138_DSP/ <target filesystem>/lib/firmware/.
-
-IPC Daemons and Drivers
-''''''''''''''''''''''''''
-
-IPC provides system-wide services across multiple applications, and
-utilizes low-level system hardware (e.g. interrupts and shared memory).
-To facilitate these services, IPC uses a user-space daemon (LAD) and
-several kernel device drivers.
-
-.. rubric:: LAD
-   :name: lad
-
-System-wide IPC state is managed by a user-space daemon (LAD). This
-daemon is specific to a given device, and is named lad_<device>. It will
-reside on the target's filesystem (typically in /usr/bin/) after
-following the `#Installing Tests <index_Foundational_Components.html#installing-tests>`__ section. To run
-LAD, execute:
-
-::
-
-    target# /usr/bin/lad_<device>
-
-This forks the LAD daemon and leaves it running in the background.
-
-LAD takes an optional argument to indicate a filename into which log
-statements should be emitted. This file will be created in the
-**/tmp/LAD/** directory. How to specify the filename varies based on
-your IPC release. For example, to instruct LAD to emit log statements
-into a 'lad.txt' file, start LAD like this:
-
--  Releases before IPC 3.21:
-
-::
-
-    target# /usr/bin/lad_<device> lad.txt
-
--  IPC 3.21 and after:
-
-::
-
-    target# /usr/bin/lad_<device> -l lad.txt
-
-|
-
-.. rubric:: Drivers
-   :name: drivers
-
-The kernel drivers/modules added by the Linux patches must be inserted
-into the kernel for IPC applications to run correctly. Refer to the
-`#Configuring Kernel <index_Foundational_Components.html#configuring-kernel>`__ section. The required
-modules must be configured, built and loaded onto the target's
-filesystem.
-
-Prior to loading the modules, a directory (/debug) must be created at
-the root of your devices filesystem. This directory will be mounted as a
-debugfs (debug filesystem) which the kernel modules will use to provide
-details about the slaves (e.g. running state, trace output, etc). If the
-/debug directory doesn't exist, simply create it as follows:
-
-::
-
-    target# mkdir /debug
-
-.. rubric:: OMAP-L138
-   :name: omap-l138-1
-
-On OMAP-L138, the kernel modules can be loaded with the following
-command on the target's file-system:
-
-::
-
-    target# depmod -a
-    target# mount -t debugfs none /debug
-    target# modprobe remoteproc
-    target# modprobe da8xx_remoteproc da8xx_fw_name=messageq_single.xe674
-    target# modprobe virtio_rpmsg_bus
-    target# modprobe rpmsg_proto
-
-The kernel modules can be unloaded by issuing the following command on
-the target's file-system:
-
-::
-
-    target# umount /debug
-    target# rmmod rpmsg_proto
-    target# rmmod virtio_rpmsg_bus
-    target# rmmod da8xx_remoteproc
-    target# rmmod remoteproc
-
-.. rubric:: OMAP54XX
-   :name: omap54xx
-
-On OMAP54XX, the kernel modules can be loaded with the following command
-on the target's file-system:
-
-::
-
-    target# depmod -a
-    target# mount -t debugfs none /debug
-    target# modprobe remoteproc
-    target# modprobe omap_remoteproc
-    target# modprobe virtio_rpmsg_bus
-    target# modprobe rpmsg_proto
-
-Running Test Applications
-''''''''''''''''''''''''''
-
-The test applications are already on the target's filesystem in /usr/bin
-assuming the `#Installing Tests <index_Foundational_Components.html#installing-tests>`__ section has been
-followed.
-
-To run the test application's, execute the following on the target's
-filesystem:
-
-::
-
-    target# /usr/bin/MessageQApp_<device>
-
-.. rubric:: OMAP-L138
-   :name: omap-l138-2
-
-The expected output on the Linux-side should be:
-
-::
-
-    Using numLoops: 100; procId : 1
-    Entered MessageQApp_execute
-    Local MessageQId: 0x1
-    Remote queueId  [0x10000]
-    Exchanging 100 messages with remote processor DSP...
-    MessageQ_get #0 Msg = 0x15328
-    Exchanged 1 messages with remote processor DSP
-    MessageQ_get #1 Msg = 0x15328
-    ...
-    ...
-    Exchanged 99 messages with remote processor DSP
-    MessageQ_get #99 Msg = 0x15328
-    Exchanged 100 messages with remote processor DSP
-    Sample application successfully completed!
-    Leaving MessageQApp_execute
-
-The output on the remote processor, can be obtained by running the
-following on the target filesystem:
-
-::
-
-    target# cat /debug/remoteproc/remoteproc0/trace0
-
-The expected output on the remote processor should be:
-
-::
-
-    3 Resource entries at 0xc3100000
-    messageq_single.c:main: MultiProc id = 1
-    registering rpmsg-proto service on 61 with HOST
-    tsk1Fxn: created MessageQ: SLAVE_DSP; QueueID: 0x10000
-    Awaiting sync message from host...
-    [t=0x00000001:67984156] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: no object for endpoint: 53
-    [t=0x00000001:67f626ed] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: no object for endpoint: 53
-    Received msg from (procId:remoteQueueId): 0x0:0x1
-           payload: 8 bytes; loops: 100 with printing.
-    Got msg #0 (40 bytes) from procId 0
-    Sending msg Id #0 to procId 0
-    Got msg #1 (40 bytes) from procId 0
-    Sending msg Id #1 to procId 0
-    ...
-    ...
-    Got msg #98 (40 bytes) from procId 0
-    Sending msg Id #98 to procId 0
-    Got msg #99 (40 bytes) from procId 0
-    Sending msg Id #99 to procId 0
-    Awaiting sync message from host...
-    [t=0x00000015:7b46c4c2] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: no object for endpoint: 53
-    [t=0x00000015:7b6315fb] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: no object for endpoint: 53
-
-See Also
-^^^^^^^^^^
-
--  `IPC 3.x <index_Foundational_Components.html#ipc-3-x>`__
--  `IPC Users Guide <index_Foundational_Components.html#ipc-user-guide>`__
--  `IPC 3.x FAQ <index_Foundational_Components.html#ipc-faq>`__
--  `IPC Install Guide QNX <index_Foundational_Components.html#qnx-install-guide>`__
--  `IPC Install Guide BIOS <index_Foundational_Components.html#bios-install-guide>`__
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_QNX.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_QNX.rst
deleted file mode 100644
index a011a7f78..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_QNX.rst
+++ /dev/null
@@ -1,646 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Install_Guide_QNX
-
-Introduction
-^^^^^^^^^^^^^
-
-Inter/Intra Processor Communication (IPC) is a product designed to
-enable communication between processors in a multi-processor
-environment. Features of IPC include message passing, multi-processor
-gates, shared memory primitives, and more.
-
-IPC is designed for use with processors running SYS/BIOS applications.
-This is typically an ARM or DSP. IPC includes support for High Level
-Operating Systems (HLOS) like Linux, as well as the SYS/BIOS RTOS. The
-breadth of IPC features supported in an HLOS environment is reduced in
-an effort to simplify the product.
-
-Install
-^^^^^^^^
-
-IPC is often distributed and installed within a larger SDK. In those
-cases, no installation is required.
-
-Outside of an SDK, `IPC can be downloaded
-here <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/index.html>`__,
-and is released as a zip file. To install, simply extract the file.
-
-::
-
-    buildhost$ unzip ipc_<version>.zip
-
-This will extract the IPC product in a directory with its product name
-and version information (e.g. **c:/ti/ipc_<version>**)
-
-.. note::
-
-  -  This document assumes the IPC install path to be the user's home
-     directory on a Linux host machine (**/home/<user>**) or the user's
-     main drive on a Windows host machine (**C:\\**). The variable
-     **IPC_INSTALL_DIR** will be used throughout the document. If IPC was
-     installed at a different location, make appropriate changes to
-     commands.
-  -  Some customers find value in archiving the released sources in a
-     configuration management system. This can help in identifying any
-     changes made to the original sources - often useful when updating to
-     newer releases.
-
-Build
-^^^^^^^
-
-The IPC product often comes with prebuilt SYS/BIOS-side libraries, so
-rebuilding them isn't necessary. The QNX-side libraries/binaries may
-also be provided prebuilt by SDK programs, but the standalone IPC
-release does not currently pre-build them.
-
-IPC provides GNU makefile(s) to rebuild all its libraries at the base of
-the product, details are below.
-
-.. note::
-  GNU make version 3.81 or greater is required. The XDC tools (provided
-  with most SDKs and CCS distributions) includes a pre-compiled version of
-  GNU make 3.81 in $(XDC_INSTALL_DIR)/gmake.
-
-products.mak
-"""""""""""""
-
-IPC contains a **products.mak** file at the root of the product that
-specifies the necessary paths and options to build IPC for the various
-OS support.
-
-Edit **products.mak** and set the following variables:
-
--  Variables used by both QNX and BIOS
-
-   -  **PLATFORM** - Device to build for
-
-      -  QNX started using this variable in IPC 3.20. Prior releases
-         required setting "DEVICE" for QNX and "PLATFORM" for BIOS. The
-         two variables were consolidated in IPC 3.20.
-      -  BIOS started leveraging this variable in IPC 3.10. Prior
-         releases built BIOS-side executables for **all** supported
-         platforms based on that targets/toolchains set above (which can
-         take a while!)
-
--  QNX
-
-   -  **QNX_INSTALL_DIR** - Path to your QNX installation directory.
-   -  **DESTDIR** - Path to which target binaries will be exported when
-      running the 'make install' goal.
-   -  **DEVICE** - (only required for releases prior to IPC 3.20) Device
-      to build for
-
--  SYS/BIOS
-
-   -  **XDC_INSTALL_DIR** - Path to TI's XDCTools installation
-   -  **BIOS_INSTALL_DIR** - Path to TI's SYS/BIOS installation
-   -  **ti.targets.<device target and file format>** - Path to TI
-      toolchain for the device.
-
-      -  Set only the variables to the targets your device supports to
-         minimize build time.
-
-   -  **gnu.targets.arm.<device target and file format>** - Path to GNU
-      toolchain for the device.
-
-      -  Set only the variables to the targets your device supports to
-         minimize build time.
-
-.. note::
-  The versions used during validation can be found in the IPC Release
-  Notes provided in the product.
-
-.. rubric:: ipc-qnx.mak
-   :name: ipc-qnx.mak
-
-The QNX-side build is performed using QNX makefiles. To build using the
-components paths set in the **products.mak** file, issue the following
-command:
-
-::
-
-    <buildhost> make -f ipc-qnx.mak all
-
-ipc-bios.mak
-""""""""""""""
-
-The SYS/BIOS-side IPC is built with a GNU makefile. After editing
-**products.mak**, issue the following command:
-
-::
-
-    <buildhost> make -f ipc-bios.mak all
-
-Based on the number of targets you're building for, this may take some
-time.
-
-**Note for Windows users:** If you are building with a Windows host
-machine and it has the QNX tools installed, you will instead need to run
-the following in a separate command prompt window (cmd.exe) to build the
-SYS/BIOS side outside of the QNX build environment:
-
-::
-
-    <buildhost> set PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
-    <buildhost> <XDC_INSTALL_DIR>\gmake -f ipc-bios.mak all
-
-where <XDC_INSTALL_DIR> should be replaced with the installation
-directory of your XDC tools, same as the path you have used in
-products.mak.
-
-Run
-^^^^^
-
-The IPC product provides a way to install (copy) the necessary IPC
-executables and libraries onto the device's target file-system to
-simplify the execution of the applications. The details can vary across
-OS's, so this description has been separated into OS-specific sections.
-
-Configuring the BSP
-""""""""""""""""""""
-
-Some of the provided IPC tests that use a utility called
-SharedMemoryAllocator require a carveout to be created in the QNX-owned
-memory. To reserve this memory, you must make the following change in
-the file <QNX BSP installation
-directory>\src\hardware\startup\boards\<board name>\build in the QNX
-BSP. E.g.
-
-::
-
-   startup-omap5432uevm -r 0xBA300000,0x5A00000 -vvvvv -P2 -W
-
-Save the file, then rebuild the QNX OS image (ifs-*.bin) and replace
-your existing one with the new one.
-
-Installing Tests in QNX
-""""""""""""""""""""""""
-
-To assemble the IPC resource manager, shared libraries and test
-executables into a directory structure suitable for running on the
-device's file-system, issue the following command in the IPC_INSTALL_DIR
-directory:
-
-::
-
-    buildhost$ make -f ipc-qnx.mak install
-
-This will install the binaries into the directory specified by DESTDIR
-in products.mak. It this assumed that DESTDIR is a directory visible to
-the target filesystem. If not, you should copy its contents to such a
-location (e.g. onto an SD card that can be accessed by the EVM).
-
-When building in Windows, some users might get build messages that
-report a version mismatch in cygwin:
-
-::
-
-    C:/QNX650/host/win32/x86/usr/bin/make -j 1 -Cle.v7 -fMakefile install
-          1 [main] ? (5984) C:\QNX650\host\win32\x86\usr\photon\bin\find.exe: *** fa
-    tal error - system shared memory version mismatch detected - 0x8A88009C/0x2D1E009C.
-    This problem is probably due to using incompatible versions of the cygwin DLL.
-    Search for cygwin1.dll using the Windows Start->Find/Search facility
-    and delete all but the most recent version.  The most recent version *should*
-    reside in x:\cygwin\bin, where 'x' is the drive on which you have
-    installed the cygwin distribution.  Rebooting is also suggested if you
-    are unable to find another cygwin DLL.
-
-Based on what we observed the binaries are still exported correctly
-despite the messages. If you do want to eliminate them, you should
-replace the file cygwin1.dll in
-<QNX_INSTALL_DIR>\host\win32\x86\usr\photon\bin with the newest
-cygwin1.dll you can find on your host machine (do a search on your PC's
-filesystem in Windows).
-
-Some of the tests rely on corresponding remote core applications to be
-run on the slave processor(s). The remote processor's applications are
-loaded when launching the resource manager. See section
-`#IPC_resource_manager <index_Foundational_Components.html#ipc-resource-manager>`__ for details on
-launching the resource manager.
-
-The location of the remote core applications within the IPC product
-varies based on device.
-
-Installing remote core applications
-'''''''''''''''''''''''''''''''''''''
-
-Remote core applications can be found in
-<IPC_INSTALL_DIR>/packages/ti/ipc/tests/bin/ti_platform_<your platform
-name>_\* directories.
-
-For example, you can copy the messageq_single.xem4 for OMAP54xx uEVM's
-IPU onto the device's target filesystem into the **bin** directory as
-follows:
-
-::
-
-    buildhost$ copy <IPC_INSTALL_DIR>/packages/ti/ipc/tests/bin/ti_platform_omap54xx_ipu/messageq_single.xem4 <DESTDIR>/armle-v7/bin
-
-'ti_platform_omap54xx_ipu' indicates the platform is 'omap54xx' and the
-remote core name is 'IPU'. You only need to copy the binaries relevant
-to your platform.
-
-IPC resource manager
-"""""""""""""""""""""""
-
-Much of the functionality of IPC is provided by the resource manager. It
-can be launched as follows:
-
-::
-
-    target# cd <target directory corresponding to DESTDIR>/armle-v7/bin
-    target# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<target directory corresponding to DESTDIR>/armle-v7/usr/lib
-    target# ipc <CORE1> <remote executable 1> <CORE2> <remote executable 2> ...
-
-<CORE> should correspond to the name of the remote core on which you
-want the remote executable to be loaded. As a rule of thumb, it is the
-capitalized version of the core name specified by the name of the
-directory from which the executable was copied in the `#Installing remote core applications
-<index_Foundational_Components.html#installing-remote-core-applications>`__
-section. For example, if the executable is copied from
-"ti_platform_omap54xx\_**ipu**/test_omx_ipu_omap5.xem4", then you should
-load it as follows:
-
-::
-
-    target# ipc IPU test_omx_ipu_omap5.xem4
-
-The resource manager will register devices in the pathname space for
-communicating with the IPC. Communication with the IPC is only possible
-once the needed devices are registered. The following devices are
-registered by default when the IPC resource manager is launched:
-
-+------------+---------------------------------------------------------------+
-| Device     | Description                                                   |
-+============+===============================================================+
-| /dev/tiipc | Provides the "ti-ipc" protocol. Needed by MessageQ APIs.      |
-+------------+---------------------------------------------------------------+
-| /dev/ipc   | Provides the HWSpinLock functionality. Needed by GateMP APIs. |
-+------------+---------------------------------------------------------------+
-
-Additionally, more devices may be registered by the remote core firmware
-if using the "rpmsg-rpc" protocol. In that case, the name that appears
-in the pathname space is specified by the remote core firmware.
-
-Later, when you are done running applications that use IPC and no longer
-need the resource manager, it can be terminated as follows:
-
-::
-
-    target# cd <target directory corresponding to DESTDIR>/armle-v7/bin
-    target# slay ipc
-
-Running Test Applications
-""""""""""""""""""""""""""
-
-The QNX-side of the test applications are already on the target's
-filesystem in <target directory corresponding to DESTDIR>/armle-v7/bin
-and <target directory corresponding to DESTDIR>/armle-v7/bin/tests,
-assuming the `#Installing Tests in QNX <index_Foundational_Components.html#installing-tests-in-qnx>`__ and
-`#IPC resource manager <index_Foundational_Components.html#ipc-resource-manager>`__ sections have been
-followed and that the resource manager has loaded the remote core(s)
-with the executable corresponding to the test you'd like to run.
-
-To find out the syntax to use for running the test (say MessageQApp),
-run
-
-::
-
-    target# cd <target directory corresponding to DESTDIR>/armle-v7/bin/tests
-    target# use MessageQApp
-
-To run a test application, execute it on the target's filesystem:
-
-::
-
-    target# cd <target directory corresponding to DESTDIR>/armle-v7/bin/tests
-    target# ./MessageQApp 10
-
-Here is a list of the main tests that are available in the IPC product:
-
--  MessageQApp: Test that creates a single thread that sends messages
-   from host to remote core using MessageQ
-
-   -  messageq_single.x\* need to be loaded by the resource manager
-
--  MessageQMulti: Test that creates multiple threads which send messages
-   from host to remote core using MessageQ
-
-   -  messageq_multi.x\* need to be loaded by the resource manager
-
--  mmrpc_test: Test that exercises MMRPC
-
-   -  test_omx_ipu_<platform>.x\* need to be loaded by the resource
-      manager
-   -  Aside from the IPC resource manager, this test also needs the
-      shmemallocator resource manager to be launched beforehand:
-
-::
-
-         target# cd <target directory corresponding to DESTDIR>/armle-v7/bin
-         target# shmemallocator
-         target# cd tests
-         target# mmrpc_test 1
-
-.. rubric:: Expected output
-   :name: expected-output
-
-To give you an idea, the expected output for MessageQApp on the QNX-side
-should look similar to this:
-
-::
-
-    Using numLoops: 10; procId : 1
-    Entered MessageQApp_execute
-    Local MessageQId: 0x1
-    Remote queueId  [0x10000]
-    Exchanging 10 messages with remote processor IPU...
-    MessageQ_get #0 Msg = 0x11c9f0
-    Exchanged 1 messages with remote processor IPU
-    MessageQ_get #1 Msg = 0x11c9f0
-    Exchanged 2 messages with remote processor IPU
-    MessageQ_get #2 Msg = 0x11c9f0
-    ...
-    ...
-    Exchanged 9 messages with remote processor IPU
-    MessageQ_get #9 Msg = 0x11c9f0
-    Exchanged 10 messages with remote processor IPU
-    Sample application successfully completed!
-    Leaving MessageQApp_execute
-
-The output on the remote processor can be obtained by running the
-following on the target filesystem:
-
-::
-
-    target# cat /dev/ipc-trace/IPU
-
-The expected output on the remote processor should look similar to this:
-
-::
-
-    [0][      0.000] 16 Resource entries at 0x3000
-    [0][      0.000] messageq_single.c:main: MultiProc id = 1
-    [0][      0.000] [t=0x006c565d] ti.ipc.transports.TransportVirtioSetup: TransportVirtio
-    Setup_attach: remoteProcId: 0
-    [0][      0.000] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
-    [0][      0.000] [t=0x0072625b] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_create: endPt c
-    reated: 61
-    [0][      0.000] [t=0x0073e8d9] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_toHost kicked
-    [0][      0.000] [t=0x00753771] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][      0.000] [t=0x0076cb49] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][      0.000]        Received msg: from: 0x5a, to: 0x35, dataLen: 72
-    [0][      0.000] [t=0x007872e9] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: no object
-    for endpoint: 53
-    [0][      0.000] tsk1Fxn: created MessageQ: SLAVE_CORE0; QueueID: 0x10000
-    [0][      0.000] Awaiting sync message from host...
-    [0][     51.992] [t=0x0c475268] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][     51.992] [t=0x0c48eb28] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][     51.993]        Received msg: from: 0x400, to: 0x3d, dataLen: 176
-    [0][     51.993] [t=0x0c4ad220] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: calling c
-    allback with data len: 176, from: 1024
-    [0][     51.993]
-    [0][     52.995] [t=0x0c873ded] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][     52.996] [t=0x0c88b029] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][     52.996]        Received msg: from: 0x406, to: 0x3d, dataLen: 40
-    [0][     52.996] [t=0x0c8a8a87] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: calling c
-    allback with data len: 40, from: 1030
-    [0][     52.996]
-    [0][     52.996] Received msg from (procId:remoteQueueId): 0x0:0x1
-    [0][     52.996]        payload: 8 bytes; loops: 10 with printing.
-    [0][     52.997] [t=0x0c8eab7e] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][     52.997] [t=0x0c9031bc] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][     52.997]        Received msg: from: 0x406, to: 0x3d, dataLen: 40
-    [0][     52.997] [t=0x0c9208fa] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: calling c
-    allback with data len: 40, from: 1030
-    [0][     52.997]
-    [0][     52.997] Got msg #0 (40 bytes) from procId 0
-    [0][     52.997] Sending msg Id #0 to procId 0
-    [0][     52.998] [t=0x0c959f33] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][     52.998] [t=0x0c971df7] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][     52.998]        Received msg: from: 0x406, to: 0x3d, dataLen: 40
-    [0][     52.998] [t=0x0c98f3e7] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: calling c
-    allback with data len: 40, from: 1030
-    [0][     52.998]
-    [0][     52.999] Got msg #1 (40 bytes) from procId 0
-    [0][     52.999] Sending msg Id #1 to procId 0
-    [0][     52.999] [t=0x0c9c7a00] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][     52.999] [t=0x0c9df7fc] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][     52.999]        Received msg: from: 0x406, to: 0x3d, dataLen: 40
-    [0][     52.999] [t=0x0c9fce5a] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: calling c
-    allback with data len: 40, from: 1030
-    [0][     52.999]
-    [0][     53.000] Got msg #2 (40 bytes) from procId 0
-    [0][     53.000] Sending msg Id #2 to procId 0
-    [0][     53.000] [t=0x0ca36e79] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][     53.000] [t=0x0ca4ea95] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][     53.000]        Received msg: from: 0x406, to: 0x3d, dataLen: 40
-    [0][     53.001] [t=0x0ca6c975] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: calling c
-    allback with data len: 40, from: 1030
-    [0][     53.001]
-    [0][     53.001] Got msg #3 (40 bytes) from procId 0
-    [0][     53.001] Sending msg Id #3 to procId 0
-    ...
-    ...
-    [0][     53.007] Got msg #8 (40 bytes) from procId 0
-    [0][     53.007] Sending msg Id #8 to procId 0
-    [0][     53.007] [t=0x0cccd3d7] ti.ipc.rpmsg.MessageQCopy: callback_availBufReady: virt
-    Queue_fromHost kicked
-    [0][     53.007] [t=0x0cce50ed] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_swiFxn:
-    [0][     53.007]        Received msg: from: 0x406, to: 0x3d, dataLen: 40
-    [0][     53.007] [t=0x0cd027bd] ti.ipc.rpmsg.MessageQCopy: MessageQCopy_send: calling c
-    allback with data len: 40, from: 1030
-    [0][     53.007]
-    [0][     53.008] Got msg #9 (40 bytes) from procId 0
-    [0][     53.008] Sending msg Id #9 to procId 0
-    [0][     53.008] Awaiting sync message from host...
-
-Running standalone examples
-""""""""""""""""""""""""""""
-
-On some platforms, there are standalone examples provided to illustrate
-how to use specific features in IPC. These standalone examples are
-designed to be easily rebuilt outside of the IPC product, and represent
-a good starting point for development. If available, the examples are
-located in <IPC_INSTALL_DIR>\examples\archive\<platform of your choice>.
-
-To use the examples, unzip the example you want in a working directory
-of your choice. Update the products.mak file in the example's directory
-with the installation locations of the various dependent components.
-Then build it. E.g.:
-
-::
-
-    buildhost$ unzip ex02_messageq.zip
-    buildhost$ cd ex02_messageq
-    buildhost$ make clean
-    buildhost$ make
-    buildhost$ make install
-
-This would produce the host and remote core binaries in an 'install'
-subdirectory. **Tip**: Alternatively, for convenience, you can also
-extract and rebuild all examples available for your platform at once
-with this series of commands:
-
-::
-
-    buildhost$ cd <IPC_INSTALL_DIR>/examples
-    buildhost$ make extract
-    buildhost$ make
-    buildhost$ make install
-
-Next step is to copy the content of the 'install' subdirectory into a
-location accessible by your target board (e.g. SD card). Run the example
-on the target using IPC by loading the remote cores like you would with
-the test applications, then run the example. E.g.:
-
-::
-
-    target# ipc IPU ex02_messageq/debug/server_ipu.xem4 DSP ex02_messageq/debug/server_dsp.xe64T
-    target# cd ex02_messageq/debug/
-    target# app_host IPU
-
-Advanced topics
-""""""""""""""""
-
-Load and unload individual cores while IPC is running (IPC 3.23.01 and above)
-''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-In some applications, there may be a need to load or unload cores after
-the IPC resource manager is already up and running -- e.g. change the
-DSP executable while keeping the IPU running.
-
-In order to load and start a core with an executable, you can do the
-following after having launched the resource manager:
-
-::
-
-    target# echo <slave executable file path> > /dev/ipc-file/<core name>
-    target# echo 1 > /dev/ipc-state/<core name>
-
-The first command sets the filename of an executable to be loaded, and
-the second command loads and starts the core with that executable.
-
-To stop and unload a core, use the following command:
-
-::
-
-    target# echo 0 > /dev/ipc-state/<core name>
-
-Keep in mind that this simply puts the core into reset. If there is any
-on-going communication between the given core and the others, it is the
-responsibility of the user application to clean up and terminate IPC on
-the slave before unloading a core, thus to avoid causing any memory
-leaks or communication errors.
-
-Inspect the state of a slave core (IPC 3.23.01 and above)
-''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-To find out the state of a slave core (whether it is running or in
-reset), issue the following command:
-
-::
-
-    target# cat /dev/ipc-state/<core name>
-
-Tracing
-'''''''''
-
-When an issue arises, sometimes it is useful to see the output of
-internal traces from IPC. This section talks about how to view IPC trace
-from both the host and the slave cores on the QNX command prompt.
-
-.. rubric:: Host-side trace output
-   :name: host-side-trace-output
-
-.. rubric:: Trace from IPC user libraries (IPC 3.35 and above)
-   :name: trace-from-ipc-user-libraries-ipc-3.35-and-above
-
-Trace output from the IPC user libraries is controlled using the
-environment variable *IPC_DEBUG*, when launching an application that
-uses IPC. E.g.:
-
-::
-
-    target# IPC_DEBUG=<level> app_host
-
-where <level> can be set to a value between 1 and 3, with 3 being the
-most verbose.
-
-.. rubric:: Trace from IPC resource manager (IPC 3.35 and above)
-   :name: trace-from-ipc-resource-manager-ipc-3.35-and-above
-
-To show the trace output of the IPC resource manager in the QNX system
-log, run the following command:
-
-::
-
-    target# sloginfo -m42
-
-The verbosity of the trace can be controlled using the environment
-variable *IPC_DEBUG_SLOG_LEVEL* when launching the IPC resource manager.
-E.g.:
-
-::
-
-    target# IPC_DEBUG_SLOG_LEVEL=<level> ipc DSP1 ex02_messageq/debug/server_dsp1.xe66
-
-where <level> can be set to a value between 0 and 7, with 7 being the
-most verbose. The default level is 2.
-
-|
-
-.. rubric:: Slave-side trace output
-   :name: slave-side-trace-output
-
-To show all trace output (including IPC's) on a given slave core, simply
-run the following
-
-::
-
-    target# cat /dev/ipc-trace/<core name>
-
-where <core name> corresponds to the name of the slave core which trace
-output you are interested in (e.g. DSP1, IPU1 or IPU2 for DRA7xx)
-
-Note that older versions of IPC may use a slightly different path that
-is based on the MultiProc id of the core of interest:
-/dev/ipc-trace<id>.
-
-Building the IPC resource manager in debug mode (IPC 3.35 and above)
-'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-When debugging an issue, the user may wish to have the ability to step
-through the source code in the IPC resource manager. For this to happen,
-the IPC resource manager needs to be built in debug mode with debug
-symbols. Adding IPC_DEBUG=1 to the file <IPC_INSTALL_DIR>/qnx/Makefile
-and rebuilding IPC would do the trick:
-
-::
-
-       ipc3x_dev: utils
-           @cd src/ipc3x_dev; \
-               make IPC_PLATFORM=$(IPC_PLATFORM) SMP=1 QNX_CFLAGS=$(QNX_CFLAGS) IPC_DEBUG=1
-
-::
-
-    target# make -f ipc-qnx.mak clean
-    target# make -f ipc-qnx.mak all
-
-See Also
-^^^^^^^^^^
-
--  `IPC 3.x <index_Foundational_Components.html#ipc-3-x>`__
--  `IPC Users Guide <index_Foundational_Components.html#ipc-user-guide>`__
--  `IPC 3.x FAQ <index_Foundational_Components.html#ipc-faq>`__
--  `IPC Install Guide Linux <index_Foundational_Components.html#linux-install-guide>`__
--  `IPC Install Guide BIOS <index_Foundational_Components.html#bios-install-guide>`__
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_Module.rst
deleted file mode 100644
index a70c88822..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_Module.rst
+++ /dev/null
@@ -1,175 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/Ipc_Module
-
-.. |ipcCfg_Ipc_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/index.html#ti/sdo/ipc/Ipc.html
-
-.. |ipcCfg_Ipc_Img2| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-
-.. |ipcRun_Ipc_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_ipc_8h.html
-
-.. |ipcRun_Ipc_Img2| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_ipc_8h.html
-
-|
-
-   +-------------------+-------------------+
-   |         API Reference Links           |
-   +===================+===================+
-   | |ipcCfg_Ipc_Img1| | |ipcRun_Ipc_Img1| |
-   +-------------------+-------------------+
-
-The main purpose of the Ipc module is to initialize the various subsystems of IPC. All applications that use IPC modules must call the Ipc_start() API, which does the following:
-
-- Initializes a number of objects and modules used by IPC
-- Synchronizes multiple processors so they can boot in any order
-
-An application that uses IPC APIs--such as MessageQ--must include the Ipc module header file and call Ipc_start()
-before any calls to IPC modules. Here is a BIOS-side example:
-
-.. code-block:: c
-
-    #include <ti/ipc/Ipc.h>
-
-  int main(int argc, char* argv[])
- {
-      Int status;
-
-      /* Call Ipc_start() */
-     status = Ipc_start();
-      if (status < 0) {
-         System_abort("Ipc_start failed\n");
-      }
-
-     BIOS_start();
-      return (0);
- }
-
-|
-
-By default, the BIOS implementation of Ipc_start() internally calls Notify_start() if it has not already been called,
-then loops through the defined SharedRegions so that it can set up the HeapMemMP and GateMP instances used internally by the IPC modules.
-It also sets up MessageQ transports to remote processors.
-
-The SharedRegion with an index of 0 (zero) is often used by BIOS-side IPC_start() to create resource management tables
-for internal use by other IPC modules. Thus SharedRegion "0" must be accessible by all processors.
-See SharedRegion Module for more about the SharedRegion module.
-
-Ipc Module Configuration (BIOS-side only)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In an XDCtools configuration file, you configure the Ipc module for use as follows:
-
-::
-
-  Ipc = xdc.useModule('ti.sdo.ipc.Ipc');
-
-
-You can configure what the Ipc_start() API will do--which modules it will start and which objects it will create--by using the Ipc.setEntryMeta
-method in the configuration file to set the following properties:
-
-- **setupNotify.** If set to false, the Notify module is not set up. The default is true.
-- **setupMessageQ.** If set to false, the MessageQ transport instances to remote processors are not set up and
-  the MessageQ module does not attach to remote processors. The default is true.
-
-For example, the following statements from the notify example configuration turn off the setup of the MessageQ transports and connections to remote processors:
-
-.. code-block:: c
-
-  /* To avoid wasting shared memory for MessageQ transports */
-  for (var i = 0; i < MultiProc.numProcessors; i++) {
-      Ipc.setEntryMeta({
-          remoteProcId: i,
-          setupMessageQ: false,
-      });
-  }
-
-You can configure how the IPC module synchronizes processors by configuring the Ipc.procSync property. For example:
-
-::
-
-  Ipc.procSync = Ipc.ProcSync_ALL;
-
-
-The options are:
-
-- Ipc.ProcSync_ALL. If you use this option, the Ipc_start() API automatically attaches to and synchronizes all remote processors.
-  If you use this option, your application should never call Ipc_attach().
-  Use this option if all IPC processors on a device start up at the same time and connections should be established between every possible pair of processors.
-- Ipc.ProcSync_PAIR. (Default) If you use this option, you must explicitly call Ipc_attach() to attach to a specific remote processor.
-
-   If you use this option, Ipc_start() performs system-wide IPC initialization, but does not make connections to remote processors.
-   Use this option if any or all of the following are true:
-   - You need to control when synchronization with each remote processor occurs.
-   - Useful work can be done while trying to synchronize with a remote processor by yielding a thread after each attempt to Ipc_attach() to the processor.
-   - Connections to some remote processors are unnecessary and should be made selectively to save memory.
-   - Ipc.ProcSync_NONE. If you use this option, Ipc_start() doesn't synchronize any processors before setting up the objects needed by other modules.
-
-  Use this option with caution. It is intended for use in cases where the application performs its own synchronization and you want to avoid a potential
-  deadlock situation with the IPC synchronization.
-
-  If you use the ProcSync_NONE option, Ipc_start() works exactly as it does with ProcSync_PAIR. :
-  However, in this case, Ipc_attach() does not synchronize with the remote processor.
-  As with other ProcSync options, Ipc_attach() still sets up access to GateMP, SharedRegion,
-  Notify, NameServer, and MessageQ transports, so your application must still call Ipc_attach()
-  for each remote processor that will be accessed. Note that an Ipc_attach() call for a remote processor
-  whose ID is less than the local processor's ID must occur after the corresponding remote processor has called Ipc_attach() to the local processor.
-  For example, processor #2 can call Ipc_attach(1) only after processor #1 has called Ipc_attach(2).:
-
-You can configure a function to perform custom actions in addition to the default actions performed when attaching to or detaching from a remote processor.
-These functions run near the end of Ipc_attach() and near the beginning of Ipc_detach(), respectively.
-Such functions must be non-blocking and must run to completion. The following example configures two attach functions and two detach functions.
-Each set of functions will be passed a different argument:
-
-::
-
-  var Ipc = xdc.useModule('ti.sdo.ipc.Ipc');
-
-  var fxn = new Ipc.UserFxn;
-  fxn.attach = '&userAttachFxn1';
-  fxn.detach = '&userDetachFxn1';
-  Ipc.addUserFxn(fxn, 0x1);
-
-  fxn.attach = '&userAttachFxn2';
-  fxn.detach = '&userDetachFxn2';
-  Ipc.addUserFxn(fxn, 0x2);
-
-|ipcCfg_Ipc_Img2| The latest version of the IPC module configuration documentation is available
-`here <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html>`_
-
-Ipc Module APIs
-^^^^^^^^^^^^^^^^
-In addition to the Ipc_start() API, which all applications that use IPC modules are required to call,
-the Ipc module also provides the following APIs for processor synchronization:
-
-- Ipc_attach() Creates a connection to the specified remote processor.
-- Ipc_detach() Deletes the connection to the specified remote processor.
-
-You must call Ipc_start() on a processor before calling Ipc_attach().
-
-.. note::
-   Call Ipc_attach() to the processor that owns shared memory region 0--usually
-   the processor with an id of 0--before making a connection to any other remote processor.
-   For example, if there are three processors configured with MultiProc, processor 1 should
-   attach to processor 0 before it can attach to processor 2.
-
-Use these functions unless you are using the Ipc.ProcSync_ALL configuration setting.
-With that option, Ipc_start() automatically attaches to and synchronizes all remote processors,
-and your application should never call Ipc_attach().
-
-The Ipc.ProcSync_PAIR configuration option expects that your application will call
-Ipc_attach() for each remote processor with which it should be able to communicate.
-
-.. note::
-  In ARM-Linux/DSP-RTOS scenario, Linux application gets the IPC configuration from LAD which has Ipc.ProcSync_ALL configured.
-  DSP has Ipc.ProcSync_PAIR configured.
-
-Processor synchronization means that one processor waits until the other processor signals that a particular module is ready for use.
-Within Ipc_attach(), this is done for the GateMP, SharedRegion (region 0), and Notify modules and the MessageQ transports.
-
-You can call the Ipc_detach() API to delete internal instances created by Ipc_attach() and to free the memory used by these instances.
-
-|ipcRun_Ipc_Img2| The latest version of the IPC module run-time API documentation is available
-`online <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_ipc_8h.html>`_
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_Resource_Usage.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_Resource_Usage.rst
deleted file mode 100644
index df78ddb2a..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_Resource_Usage.rst
+++ /dev/null
@@ -1,144 +0,0 @@
-
-Overview
-^^^^^^^^^
-
-The main aim of this page is to capture details about the different
-resources used in the IPC drivers.
-
-.. note:: This page is under construction
-
-Interrupt map usage
-^^^^^^^^^^^^^^^^^^^^
-
-AM57xx Interrupt resources
-"""""""""""""""""""""""""""
-
-The following table captures the interrupt resources used by IPC
-associated with different cores for the AM57xx platform. If customer
-wants to use any of the interrupt resources, it is better to make sure
-any of the resources listed here are not used.
-
-**A15 Interrupt Mapping**
-
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| Index   | Addr         | Value   | Name                       | Source           | Description                        |
-+=========+==============+=========+============================+==================+====================================+
-| 134     | 0x4A002B44   | 127     | EVE1_IRQ_MBX0_USER3        | EVE1_MAILBOX0    | Eve1 Mailbox 0 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 135     | 0x4A002B44   | 128     | EVE2_IRQ_MBX0_USER3        | EVE2_MAILBOX0    | Eve2 Mailbox 0 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 136     | 0x4A002B48   | 129     | MAILBOX5_IRQ_USER2         | MAILBOX5         | Mailbox 5 user 2 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 137     | 0x4A002B48   | 130     | EVE3_IRQ_MBX0_USER3        | EVE3_MAILBOX0    | Eve 3 Mailbox 0 user 3 interrupt   |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 138     | 0x4A002B4C   | 131     | EVE4_IRQ_MBX0_USER3        | EVE4_MAILBOX0    | Eve4 Mailbox 0 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 141     | 0x4A002B50   | 134     | MAILBOX6_IRQ_USER2         | MAILBOX6         | Mailbox 6 user 2 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-
-**DSP1 Interrupt Mapping**
-
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| Index   | Addr         | Value   | Name                       | Source           | Description                        |
-+=========+==============+=========+============================+==================+====================================+
-| 55      | 0x4A002974   | 24      | EVE1_IRQ_MBX0_USER1        | EVE1_MAILBOX0    | Eve1 Mailbox 0 user 1 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 56      | 0x4A002978   | 25      | EVE2_IRQ_MBX0_USER1        | EVE2_MAILBOX0    | Eve2 Mailbox 0 user 1 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 57      | 0x4A002978   | 26      | MAILBOX5_IRQ_USER0         | MAILBOX5         | Mailbox 5 user 0 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 58      | 0x4A00297C   | 27      | EVE3_IRQ_MBX0_USER1        | EVE3_MAILBOX0    | Eve 3 Mailbox 0 user 1 interrupt   |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 59      | 0x4A00297C   | 28      | EVE4_IRQ_MBX0_USER1        | EVE4_MAILBOX0i   | Eve4 Mailbox 0 user 1 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 60      | 0x4A002980   | 29      | MAILBOX7_IRQ_USER0         | MAILBOX7         | Mailbox 7 user 0 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 61      | 0x4A002980   | 30      | MAILBOX8_IRQ_USER0         | MAILBOX8         | Mailbox 8 user 0 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-
-**DSP2 Interrupt Mapping**
-
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-| Index   | Addr         | Value   | Name                        | Source           | Description                        |
-+=========+==============+=========+=============================+==================+====================================+
-| 55      | 0x4A0029F4   | 24      | EVE1_IRQ_MBX1_USER1         | EVE1_MAILBOX1    | Eve1 Mailbox 1 user 1 interrupt    |
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-| 56      | 0x4A0029F8   | 25      | EVE2_IRQ_MBX1_USER1         | EVE2_MAILBOX1    | Eve2 Mailbox 1 user 1 interrupt    |
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-| 57      | 0x4A0029F8   | 26      | MAILBOX6_IRQ_USER0          | MAILBOX6         | Mailbox 6 user 0 interrupt         |
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-| 58      | 0x4A0029FC   | 27      | EVE3_IRQ_MLBX1_USER1        | EVE3_MAILBOX1    | Eve 3 Mailbox 1 user 1 interrupt   |
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-| 59      | 0x4A0029FC   | 28      | EVE4_IRQ_MBX1_USER1         | EVE4_MAILBOX1    | Eve4 Mailbox 1 user 1 interrupt    |
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-| 60      | 0x4A002A00   | 29      | MAILBOX7_IRQ_USER1          | MAILBOX7         | Mailbox 7 user 1 interrupt         |
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-| 61      | 0x4A002A00   | 30      | MAILBOX8_IRQ_USER1          | MAILBOX8         | Mailbox 8 user 1 interrupt         |
-+---------+--------------+---------+-----------------------------+------------------+------------------------------------+
-
-**IPU1 Interrupt Mapping**
-
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| Index   | Addr         | Value   | Name                       | Source           | Description                        |
-+=========+==============+=========+============================+==================+====================================+
-| 64      | 0x4A002830   | 42      | EVE1_IRQ_MBX0_USER2        | EVE1_MAILBOX0    | Eve1 Mailbox 0 user 2 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 65      | 0x4A002834   | 43      | EVE2_IRQ_MBX0_USER2        | EVE2_MAILBOX0    | Eve2 Mailbox 0 user 2 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 66      | 0x4A002834   | 44      | MAILBOX5_IRQ_USER1         | MAILBOX5         | Mailbox 5 user 1 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 67      | 0x4A002838   | 45      | EVE3_IRQ_MBX0_USER2        | EVE3_MAILBOX0    | Eve 3 Mailbox 0 user 2 interrupt   |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 68      | 0x4A002838   | 46      | EVE4_IRQ_MBX0_USER2        | EVE4_MAILBOX0    | Eve4 Mailbox 0 user 2 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 69      | 0x4A00283C   | 47      | MAILBOX7_IRQ_USER2         | MAILBOX7         | Mailbox 7 user 2 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 70      | 0x4A00283C   | 48      | MAILBOX8_IRQ_USER2         | MAILBOX8         | Mailbox 8 user 2 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 71      | 0x4A002840   | 49      | EVE1_IRQ_MBX1_USER3        | EVE1_MAILBOX1    | Eve1 Mailbox 1 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 72      | 0x4A002840   | 50      | EVE2_IRQ_MBX1_USER3        | EVE2_MAILBOX1    | Eve2 Mailbox 1 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 73      | 0x4A002844   | 51      | MAILBOX5_IRQ_USER3         | MAILBOX5         | Mailbox 5 user 3 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 74      | 0x4A002844   | 52      | EVE3_IRQ_MBX1_USER3        | EVE3_MAILBOX1    | Eve 3 Mailbox 1 user 3 interrupt   |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 75      | 0x4A002848   | 53      | EVE4_IRQ_MBX1_USER3        | EVE4_MAILBOX1    | Eve4 Mailbox 1 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 76      | 0x4A002848   | 54      | MAILBOX8_IRQ_USER2         | MAILBOX8         | Mailbox 8 user 2 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-
-|
-
-**IPU2 Interrupt Mapping**
-
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| Index   | Addr         | Value   | Name                       | Source           | Description                        |
-+=========+==============+=========+============================+==================+====================================+
-| 64      | 0x4A0028A4   | 42      | EVE1_IRQ_MBX1_USER2        | EVE1_MAILBOX1    | Eve1 Mailbox 1 user 2 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 65      | 0x4A0028A8   | 43      | EVE2_IRQ_MBX1_USER2        | EVE2_MAILBOX1    | Eve2 Mailbox 1 user 2 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 66      | 0x4A0028A8   | 44      | MAILBOX6_IRQ_USER1         | MAILBOX6         | Mailbox 6 user 1 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 67      | 0x4A0028AC   | 45      | EVE3_IRQ_MBX1_USER2        | EVE3_MAILBOX1    | Eve 3 Mailbox 1 user 2 interrupt   |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 68      | 0x4A0028AC   | 46      | EVE4_IRQ_MBX1_USER2        | EVE4_MAILBOX1    | Eve4 Mailbox 1 user 2 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 69      | 0x4A0028B0   | 47      | MAILBOX7_IRQ_USER3         | MAILBOX7         | Mailbox 7 user 3 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 70      | 0x4A0028B0   | 48      | MAILBOX8_IRQ_USER3         | MAILBOX8         | Mailbox 8 user 3 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 71      | 0x4A0028B4   | 49      | EVE1_IRQ_MBX1_USER3        | EVE1_MAILBOX1    | Eve1 Mailbox 1 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 72      | 0x4A0028B4   | 50      | EVE2_IRQ_MBX1_USER3        | EVE2_MAILBOX1    | Eve2 Mailbox 1 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 73      | 0x4A0028B8   | 51      | MAILBOX6_IRQ_USER3         | MAILBOX6         | Mailbox 6 user 3 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 74      | 0x4A0028B8   | 52      | EVE3_IRQ_MBX1_USER3        | EVE3_MAILBOX1    | Eve 3 Mailbox 1 user 3 interrupt   |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 75      | 0x4A0028BC   | 53      | EVE4_IRQ_MBX1_USER3        | EVE4_MAILBOX1    | Eve4 Mailbox 1 user 3 interrupt    |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-| 76      | 0x4A0028BC   | 54      | MAILBOX8_IRQ_USER3         | MAILBOX8         | Mailbox 8 user 3 interrupt         |
-+---------+--------------+---------+----------------------------+------------------+------------------------------------+
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_Resource_customTable.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_Resource_customTable.rst
deleted file mode 100644
index eba123847..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_Resource_customTable.rst
+++ /dev/null
@@ -1,552 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Resource_customTable
-
-Introduction
-^^^^^^^^^^^^^^
-
-The IPC 3.x product introduced support for loading target images which
-include a `Linux-defined resource table <http://lwn.net/Articles/489009/>`__.
-In IPC 3.00.01, `IPC added the ability <http://git.ti.com/cgit/cgit.cgi/ipc/ipcdev.git/commit/?h=ipc-next&id=44169db6cd6f02193acf7ee97c13f956f599431d>`__
-for users to override the default resource table with their own. This
-article describes the mechanics involved to do that.
-
-.. note::
-  Although the Linux community defined the resource table, the IPC port to
-  QNX also uses the same resource table.
-
-.. note::
-  This is an expert technique. Most users do not need to modify the
-  default resource table.
-
-Config
-^^^^^^^^^
-To indicate you want to provide your own resource table, you need to set
-the ``Resource.customTable`` config parameter ``true``.
-
-::
-
-    /* Override the default resource table with my own */
-    var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
-    Resource.customTable = true;
-
-When ``Resource.customtable`` is set to ``true``, IPC will no longer
-generate a default table, and the user will be able to supply their own
-table using a specially-named C struct,
-``ti_ipc_remoteproc_ResourceTable``.
-
-C Code
-^^^^^^^^^
-The user-supplied resource table is a C structure named
-``ti_ipc_remoteproc_ResourceTable`` that needs to be linked into the
-target executable. The platform-specific default resource tables are
-provided in IPC's **packages/ti/ip/remoteproc/rsc_table_*.h**, and are
-the recommended place to start from.
-
-After finding the default resource table for your platform, you can copy
-the entirety of it into your own C file, compile it, and link it into
-your executable.
-
-.. note::
-  When configuring in a TYPE_TRACE element (a trace buffer) you must
-  explicitly declare the symbol as an extern (as below). The trace buffer
-  is generated during config, and unfortunately there is no header to
-  #include that declares the name of this symbol. Also note the size of
-  the trace buffer declared in the resource table must match the size
-  you've specified in your .cfg script.
-
-For reference, here is an Vayu compatible resource table derived from
-**packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h**\ ( Disclaimer: This
-is a reference design only, and it is subject to enhancements,
-improvements and other changes without notifications).
-
-.. code-block:: c
-
-    #include "rsc_types.h"
-     
-    /* IPU Memory Map */
-    #define L4_DRA7XX_BASE          0x4A000000
-     
-    /* L4_CFG & L4_WKUP */
-    #define L4_PERIPHERAL_L4CFG     (L4_DRA7XX_BASE)
-    #define IPU_PERIPHERAL_L4CFG    0x6A000000
-     
-    #define L4_PERIPHERAL_L4PER1    0x48000000
-    #define IPU_PERIPHERAL_L4PER1   0x68000000
-     
-    #define L4_PERIPHERAL_L4PER2    0x48400000
-    #define IPU_PERIPHERAL_L4PER2   0x68400000
-     
-    #define L4_PERIPHERAL_L4PER3    0x48800000
-    #define IPU_PERIPHERAL_L4PER3   0x68800000
-     
-    #define L4_PERIPHERAL_L4EMU     0x54000000
-    #define IPU_PERIPHERAL_L4EMU    0x74000000
-     
-    #define L3_PERIPHERAL_PRUSS     0x4B200000
-    #define IPU_PERIPHERAL_PRUSS    0x6B200000
-     
-    #define L3_PERIPHERAL_DMM       0x4E000000
-    #define IPU_PERIPHERAL_DMM      0x6E000000
-     
-    #define L3_IVAHD_CONFIG         0x5A000000
-    #define IPU_IVAHD_CONFIG        0x7A000000
-     
-    #define L3_IVAHD_SL2            0x5B000000
-    #define IPU_IVAHD_SL2           0x7B000000
-     
-    #define L3_TILER_MODE_0_1       0x60000000
-    #define IPU_TILER_MODE_0_1      0xA0000000
-     
-    #define L3_TILER_MODE_2         0x70000000
-    #define IPU_TILER_MODE_2        0xB0000000
-     
-    #define L3_TILER_MODE_3         0x78000000
-    #define IPU_TILER_MODE_3        0xB8000000
-     
-    #define L3_OCMC_RAM       0x40300000
-    #define IPU_OCMC_RAM      0x60300000
-     
-    #define L3_EMIF_SDRAM     0xA0000000
-    #define IPU_EMIF_SDRAM        0x10000000
-     
-    #define IPU_MEM_TEXT            0x0
-    #define IPU_MEM_DATA            0x80000000
-     
-    #define IPU_MEM_IOBUFS          0x90000000
-     
-    #define IPU_MEM_IPC_DATA        0x9F000000
-    #define IPU_MEM_IPC_VRING       0x60000000
-    #define IPU_MEM_RPMSG_VRING0    0x60000000
-    #define IPU_MEM_RPMSG_VRING1    0x60004000
-    #define IPU_MEM_VRING_BUFS0     0x60040000
-    #define IPU_MEM_VRING_BUFS1     0x60080000
-     
-    #define IPU_MEM_IPC_VRING_SIZE  SZ_1M
-    #define IPU_MEM_IPC_DATA_SIZE   SZ_1M
-     
-    #if defined(VAYU_IPU_1)
-    #define IPU_MEM_TEXT_SIZE       (SZ_1M)
-    #elif defined(VAYU_IPU_2)
-    #define IPU_MEM_TEXT_SIZE       (SZ_1M * 6)
-    #endif
-     
-    #if defined(VAYU_IPU_1)
-    #define IPU_MEM_DATA_SIZE       (SZ_1M * 5)
-    #elif defined(VAYU_IPU_2)
-    #define IPU_MEM_DATA_SIZE       (SZ_1M * 48)
-    #endif
-     
-    #define IPU_MEM_IOBUFS_SIZE     (SZ_1M * 90)
-     
-    /*
-     * Assign fixed RAM addresses to facilitate a fixed MMU table.
-     * PHYS_MEM_IPC_VRING & PHYS_MEM_IPC_DATA MUST be together.
-     */
-    /* See CMA BASE addresses in Linux side: arch/arm/mach-omap2/remoteproc.c */
-    #if defined(VAYU_IPU_1)
-    #define PHYS_MEM_IPC_VRING      0x9D000000
-    #elif defined (VAYU_IPU_2)
-    #define PHYS_MEM_IPC_VRING      0x95800000
-    #endif
-     
-    #define PHYS_MEM_IOBUFS         0xBA300000
-     
-    /*
-     * Sizes of the virtqueues (expressed in number of buffers supported,
-     * and must be power of 2)
-     */
-    #define IPU_RPMSG_VQ0_SIZE      256
-    #define IPU_RPMSG_VQ1_SIZE      256
-     
-    /* flip up bits whose indices represent features we support */
-    #define RPMSG_IPU_C0_FEATURES   1
-     
-    struct my_resource_table {
-        struct resource_table base;
-     
-        UInt32 offset[21];  /* Should match 'num' in actual definition */
-     
-        /* rpmsg vdev entry */
-        struct fw_rsc_vdev rpmsg_vdev;
-        struct fw_rsc_vdev_vring rpmsg_vring0;
-        struct fw_rsc_vdev_vring rpmsg_vring1;
-     
-        /* text carveout entry */
-        struct fw_rsc_carveout text_cout;
-     
-        /* data carveout entry */
-        struct fw_rsc_carveout data_cout;
-     
-        /* ipcdata carveout entry */
-        struct fw_rsc_carveout ipcdata_cout;
-     
-        /* trace entry */
-        struct fw_rsc_trace trace;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem0;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem1;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem2;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem3;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem4;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem5;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem6;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem7;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem8;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem9;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem10;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem11;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem12;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem13;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem14;
-     
-        /* devmem entry */
-        struct fw_rsc_devmem devmem15;
-    };
-    extern char ti_trace_SysMin_Module_State_0_outbuf__A;
-    #define TRACEBUFADDR (UInt32)&ti_trace_SysMin_Module_State_0_outbuf__A
-     
-    #pragma DATA_SECTION(ti_ipc_remoteproc_ResourceTable, ".resource_table")
-    #pragma DATA_ALIGN(ti_ipc_remoteproc_ResourceTable, 4096)
-     
-    struct my_resource_table ti_ipc_remoteproc_ResourceTable = {
-        1,      /* we're the first version that implements this */
-        21,     /* number of entries in the table */
-        0, 0,   /* reserved, must be zero */
-        /* offsets to entries */
-        {
-            offsetof(struct my_resource_table, rpmsg_vdev),
-            offsetof(struct my_resource_table, text_cout),
-            offsetof(struct my_resource_table, data_cout),
-            offsetof(struct my_resource_table, ipcdata_cout),
-            offsetof(struct my_resource_table, trace),
-            offsetof(struct my_resource_table, devmem0),
-            offsetof(struct my_resource_table, devmem1),
-            offsetof(struct my_resource_table, devmem2),
-            offsetof(struct my_resource_table, devmem3),
-            offsetof(struct my_resource_table, devmem4),
-            offsetof(struct my_resource_table, devmem5),
-            offsetof(struct my_resource_table, devmem6),
-            offsetof(struct my_resource_table, devmem7),
-            offsetof(struct my_resource_table, devmem8),
-            offsetof(struct my_resource_table, devmem9),
-            offsetof(struct my_resource_table, devmem10),
-            offsetof(struct my_resource_table, devmem11),
-            offsetof(struct my_resource_table, devmem12),
-            offsetof(struct my_resource_table, devmem13),
-            offsetof(struct my_resource_table, devmem14),
-            offsetof(struct my_resource_table, devmem15),
-        },
-     
-        /* rpmsg vdev entry */
-        {
-            TYPE_VDEV, VIRTIO_ID_RPMSG, 0,
-            RPMSG_IPU_C0_FEATURES, 0, 0, 0, 2, { 0, 0 },
-            /* no config data */
-        },
-        /* the two vrings */
-        { IPU_MEM_RPMSG_VRING0, 4096, IPU_RPMSG_VQ0_SIZE, 1, 0 },
-        { IPU_MEM_RPMSG_VRING1, 4096, IPU_RPMSG_VQ1_SIZE, 2, 0 },
-     
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_TEXT, 0,
-            IPU_MEM_TEXT_SIZE, 0, 0, "IPU_MEM_TEXT",
-        },
-     
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_DATA, 0,
-            IPU_MEM_DATA_SIZE, 0, 0, "IPU_MEM_DATA",
-        },
-     
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_IPC_DATA, 0,
-            IPU_MEM_IPC_DATA_SIZE, 0, 0, "IPU_MEM_IPC_DATA",
-        },
-     
-        {
-            TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:sysm3",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_MEM_IPC_VRING, PHYS_MEM_IPC_VRING,
-            IPU_MEM_IPC_VRING_SIZE, 0, 0, "IPU_MEM_IPC_VRING",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_MEM_IOBUFS, PHYS_MEM_IOBUFS,
-            IPU_MEM_IOBUFS_SIZE, 0, 0, "IPU_MEM_IOBUFS",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_TILER_MODE_0_1, L3_TILER_MODE_0_1,
-            SZ_256M, 0, 0, "IPU_TILER_MODE_0_1",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_TILER_MODE_2, L3_TILER_MODE_2,
-            SZ_128M, 0, 0, "IPU_TILER_MODE_2",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_TILER_MODE_3, L3_TILER_MODE_3,
-            SZ_128M, 0, 0, "IPU_TILER_MODE_3",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_L4CFG, L4_PERIPHERAL_L4CFG,
-            SZ_16M, 0, 0, "IPU_PERIPHERAL_L4CFG",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_L4PER1, L4_PERIPHERAL_L4PER1,
-            SZ_2M, 0, 0, "IPU_PERIPHERAL_L4PER1",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_L4PER2, L4_PERIPHERAL_L4PER2,
-            SZ_4M, 0, 0, "IPU_PERIPHERAL_L4PER2",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_L4PER3, L4_PERIPHERAL_L4PER3,
-            SZ_8M, 0, 0, "IPU_PERIPHERAL_L4PER3",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_L4EMU, L4_PERIPHERAL_L4EMU,
-            SZ_16M, 0, 0, "IPU_PERIPHERAL_L4EMU",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_PRUSS, L3_PERIPHERAL_PRUSS,
-            SZ_1M, 0, 0, "IPU_PERIPHERAL_PRUSS",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_IVAHD_CONFIG, L3_IVAHD_CONFIG,
-            SZ_16M, 0, 0, "IPU_IVAHD_CONFIG",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_IVAHD_SL2, L3_IVAHD_SL2,
-            SZ_16M, 0, 0, "IPU_IVAHD_SL2",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_DMM, L3_PERIPHERAL_DMM,
-            SZ_1M, 0, 0, "IPU_PERIPHERAL_DMM",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_OCMC_RAM, L3_OCMC_RAM,
-            SZ_4M, 0, 0, "IPU_OCMC_RAM",
-        },
-     
-        {
-            TYPE_DEVMEM,
-            IPU_EMIF_SDRAM, L3_EMIF_SDRAM,
-            SZ_256M, 0, 0, "IPU_EMIF_SDRAM",
-        },
-    };
-
-
-You can find 3 new TYPE_DEVMEM entries added in above resource table.
-
--  L3_PERIPHERAL_PRUSS
--  IPU_OCMC_RAM
--  IPU_EMIF_SDRAM
-
-All ELF section placements (as well as the VRINGS, which aren’t in an
-ELF section) are placed in memory allocated from the remoteproc CMA area
-and are mapped to the virtual address as specified in the TYPE_CARVEOUT
-entries.
-
-The virtual addresses #defined are:
-
-.. code-block:: c
-
-    #define IPU_MEM_TEXT            0x0
-    #define IPU_MEM_DATA            0x80000000
-     
-    #define IPU_MEM_IOBUFS          0x90000000
-     
-    #define IPU_MEM_IPC_DATA        0x9F000000
-    #define IPU_MEM_IPC_VRING       0x60000000
-
-The followings are fixed physical address to facilitate a fixed MMU
-table.
-
-.. code-block:: c
-
-    #if defined(VAYU_IPU_1)
-    #define PHYS_MEM_IPC_VRING      0x9D000000
-    #elif defined (VAYU_IPU_2)
-    #define PHYS_MEM_IPC_VRING      0x95800000
-    #endif
-
-These PHYS_MEM values match exactly the physical address specified in
-the remoteproc CMA area in Linux DTS file:
-
-::
-
-                    ipu2_cma_pool: ipu2_cma@95800000 {
-                            compatible = "shared-dma-pool";
-                            reg = <0x95800000 0x3800000>;
-                            reusable;
-                            status = "okay";
-                    };
-     
-                    ipu1_cma_pool: ipu1_cma@9d000000 {
-                            compatible = "shared-dma-pool";
-                            reg = <0x9d000000 0x2000000>;
-                            reusable;
-                            status = "okay";
-                    };
-
-
-The 1st entry in the resource table is:
-
-.. code-block:: c
-
-        /* rpmsg vdev entry */
-        {
-            TYPE_VDEV, VIRTIO_ID_RPMSG, 0,
-            RPMSG_IPU_C0_FEATURES, 0, 0, 0, 2, { 0, 0 },
-            /* no config data */
-        },
-        /* the two vrings */
-        { IPU_MEM_RPMSG_VRING0, 4096, IPU_RPMSG_VQ0_SIZE, 1, 0 },
-        { IPU_MEM_RPMSG_VRING1, 4096, IPU_RPMSG_VQ1_SIZE, 2, 0 },
-
-This tells remoteproc to allocate the vrings and vring buffers, and the
-remoteproc CMA area is used for this.
-
-The 2nd-4th entries are:
-
-.. code-block:: c
-
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_TEXT, 0,
-            IPU_MEM_TEXT_SIZE, 0, 0, "IPU_MEM_TEXT",
-        },
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_DATA, 0,
-            IPU_MEM_DATA_SIZE, 0, 0, "IPU_MEM_DATA",
-        },
-        {
-            TYPE_CARVEOUT,
-            IPU_MEM_IPC_DATA, 0,
-            IPU_MEM_IPC_DATA_SIZE, 0, 0, "IPU_MEM_IPC_DATA",
-        },
-
-These carveouts tell remoteproc to allocate memory from its CMA area and
-map the allocated physical address to the virtual address specified in
-the carveout (the 1st field after TYPE_CARVEOUT), in the IPU’s MMU
-(“iommu” in Linux kernel parlance). These are for the ELF sections that
-are placed (mapped) in those virtual address.
-
-The TYPE_TRACE entry tells remoteproc where the remote executable’s
-trace buffer is, using its C symbol.
-
-The TYPE_DEVMEM entries are virtual <-> physical mappings. remoteproc
-just creates an IPU MMU mapping for the entry. The 1st TYPE_DEVMEM entry
-corresponds to the vrings and creates the IPU MMU mapping needed to
-access them from the IPU core:
-
-.. code-block:: c
-
-        {
-            TYPE_DEVMEM,
-            IPU_MEM_IPC_VRING, PHYS_MEM_IPC_VRING,
-            IPU_MEM_IPC_VRING_SIZE, 0, 0, "IPU_MEM_IPC_VRING",
-        },
-
-New TYPE_DEVMEM entry
-^^^^^^^^^^^^^^^^^^^^^^^
-
-To add a new TYPE_DEVMEM entry, for example, to access PRU-ICSS from IPU
-
--  1. specify the physical address of PRU-ICSS and its virutal address.
-
-::
-
-        #define L3_PERIPHERAL_PRUSS     0x4B200000
-        #define IPU_PERIPHERAL_PRUSS    0x6B200000
-
--  2. increase size of **offset[X]** array in struct my_resource_table.
--  3. add new **struct fw_rsc_devmem devmemY** entry in struct
-   my_resource_table.
--  4. increase **number** of entries in ti_ipc_remoteproc_ResourceTable.
--  5. add a **offsetof(struct my_resource_table, devmemY)** in
-   ti_ipc_remoteproc_ResourceTable.
--  6. add actual entry in ti_ipc_remoteproc_ResourceTable.
-
-.. code-block:: c
-
-        {
-            TYPE_DEVMEM,
-            IPU_PERIPHERAL_PRUSS, L3_PERIPHERAL_PRUSS,
-            SZ_1M, 0, 0, "IPU_PERIPHERAL_PRUSS",
-        },
-
-Note, when MMU is enabled, even though it is a one-to-one mapping, you
-need to have an entry mapped in the MMU for that, e.g. to access
-PRU-ICSS from DSP, you must add the following entry in
-**rsc_table_vayu_dsp.h**
-
-::
-
-    #define L3_PRU_ICSS             0x4B200000
-    #define DSP_PRU_ICSS            0x4B200000
-
-The MMU pagetable can be dumped through debugfs - "cat
-/sys/kernel/debug/omap_iommu/<iommu_name>/pagetable"
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_Users_Guide.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_Users_Guide.rst
deleted file mode 100644
index 16fcf7067..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_Users_Guide.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide
-
-.. |ipcCfg_Img| Image::  /images/Book_cfg.png
-               :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |ipcRun_Img| Image::  /images/Book_run.png
-               :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/index.html
-
-
-Inter-Processor Communication (IPC) provides a processor-agnostic API which can be used for communication between processors in a multi-processor environment (inter-core), communication to other threads on same processor (inter-process), and communication to peripherals (inter-device).
-The API supports message passing, streams, and linked lists.
-IPC can be used to communicate with the following:
-
-- Other threads on the same processor
-- Threads on other processors running SYS/BIOS
-- Threads on other processors running an HLOS (e.g., Linux, QNX, Android)
-
-.. image:: /images/IPC_comm_features.JPG
-
-Overview
-========
-This user's guide contains the topics in the following list. It also
-links to API reference documentation for static configuration (|ipcCfg_Img|)
-and run-time C processing (|ipcRun_Img|) for each module.
-
-**Getting Started**
-
--  `Use Cases for IPC <index_Foundational_Components.html#use-cases-for-ipc>`__ explains the various use cases for IPC.
-
--  `IPC Examples <index_Foundational_Components.html#ipc-examples>`__ explains how
-   to build and generate the IPC examples.
-
--  `IPC Training <index_Foundational_Components.html#ipc-training>`__ lists available IPC training.
-
--  `IPC 3.x <index_Foundational_Components.html#ipc-3-x>`__
-   Provides details of IPC 3.x releases
-
--  `Run IPC Examples on AM572x <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#run-ipc-examples-on-am572x>`__
-
--  `Run IPC Examples on AM65xx <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#run-ipc-examples-on-am65xx>`__
-
-**Application Development**
-
--  `Create DSP and IPU firmware using PDK drivers and IPC to load from ARM Linux on AM57xx devices <index_how_to_guides.html#create-dsp-and-ipu-firmware-using-pdk-drivers-and-ipc-to-load-from-arm-linux-on-am57xx-devices>`__
-
--  `Customizing Memory map for creating Multicore Applications on AM57xx using IPC <index_how_to_guides.html#customizing-memory-map-for-creating-multicore-applications-on-am57xx-using-ipc>`__
-
--  `Optimizing IPC
-   Applications <index_Foundational_Components.html#optimizing-ipc-applications>`__
-   provides hints for improving the runtime performance and shared
-   memory usage of applications that use IPC.
-
--  `IPC
-   Benchmarking <index_Foundational_Components.html#ipc-benchmarking>`__
-   IPC Benchmarking with IPC 3.x
-
--  `IPC Custom
-   ResourceTable <index_Foundational_Components.html#resource-custom-table>`__
-   Provides details of customizing the resource table.
-
--  `IPC Debugging Tools and Techniques on AM57xx <index_how_to_guides.html#ipc-debugging-tools-and-techniques-on-am57xx>`__
-
-**IPC Internal/API & Other Useful Links**
-
--  `The TI SDO IPC Package <index_Foundational_Components.html#ti-sdo-ipc-package>`__
-   section describes the modules in the ti.sdo.ipc package.
-
--  `The TI SDO Utils Package <index_Foundational_Components.html#ti-sdo-utils-package>`__
-   section describes the modules in the ti.sdo.utils package.
-
--  `IPC 3.x Migration
-   Guide <http://processors.wiki.ti.com/index.php/IPC_3.x_Migration_Guide>`__
-   Provides details of migrating to IPC 3.x from previous releases
-
--  `IPC GateMP Support for UIO and Misc
-   Driver <index_Foundational_Components.html#gatemp-support-for-uio-and-misc-driver>`__
-   Provides details of IPC GateMP support with UIO driver
-
--  `RTOS IPC
-   Transports <index_Foundational_Components.html#ipc-transports>`__
-   explains details of the additional RTOS IPC transports provided via
-   the Processor SDK PDK component.
-
--  `Rebuilding IPC <index_Foundational_Components.html#rebuilding-ipc>`__
-   explains how to rebuild the IPC libraries if you modify the source
-   files.
-
-**FAQ**
-
--  `IPC 3.x
-   FAQ <index_Foundational_Components.html#ipc-faq>`__
-   Frequently asked questions on IPC 3.x
-
-|
-
-.. note::
-   Please see the release notes in your IPC installation before starting to
-   use IPC. The release notes contain important information about feature
-   support, issues, and compatibility information for a particular release.
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_IPC_examples.rst b/source/rtos/PDK_Platform_Software/IPC/_IPC_examples.rst
deleted file mode 100644
index f73647056..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_IPC_examples.rst
+++ /dev/null
@@ -1,256 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/Examples
-
-Building IPC Examples
----------------------
-The IPC BIOS examples are located in the Processor SDK RTOS IPC directory within the examples folder. Please refer to the readme of each example for details on each example.
-
-The examples are makefile based and can be built using the top-level makefile provided in the Processor SDK RTOS folder. The following commands will build all of the IPC examples.
-
-**Windows**
-::
-
-	cd (Processor SDK RTOS folder)
-	setupenv.bat
-	gmake ipc_examples
-
-**Linux**
-::
-
-	cd (Processor SDK RTOS folder)
-	source ./setupenv.sh
-	make ipc_examples
-
-
-IPC Examples: Details
-----------------------
-
-This section explains some of the common details about IPC examples.
-The sub-directories under the examples are organised into the code for each of the cores in the SOC.
-For example
-
- - Host
- - DSP1
- - DSP2
- - IPU1
- - IPU2
-
-Typically we have a host core which is the main core in the SOC and other slave cores.
-The directory name of the slave cores have a base name (like DSP, IPU etc) which indicates the type of core and a core number.
-Depending on the example, the Host can run TI BIOS or Linux or QNX and the slave cores in general run TI BIOS only.
-So the specific build related files need to be interpreted accordingly.
-
-BIOS Application Configuration Files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The cores running BIOS in general has a config file which brings in all the modules needed to complete the application running on the specific core.
-This section explains the details of the entries in the config file.
-Note: The details here are just representative of a typical configuration. In general the configuration is customized based on the particular example.
-
-BIOS Configuration
-"""""""""""""""""""
-The following configuration are related to configuring BIOS
-::
-
-   var BIOS        = xdc.useModule('ti.sysbios.BIOS');
-   /*  This adds ipc Startup to be done part of BIOS  startup before main*/
-   BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');
-
-   /* The following configures Debug libtype with Debug build */
-   if (Program.build.profile == "debug") {
-        BIOS.libType = BIOS.LibType_Debug;
-   } else {
-       BIOS.libType = BIOS.LibType_Custom;
-   }
-
-   var Sem = xdc.useModule('ti.sysbios.knl.Semaphore');
-   var instSem0_Params = new Sem.Params();
-   instSem0_Params.mode = Sem.Mode_BINARY;
-   Program.global.runOmpSem = Sem.create(0, instSem0_Params);
-   Program.global.runOmpSem_complete = Sem.create(0, instSem0_Params);
-
-   var Task = xdc.useModule('ti.sysbios.knl.Task');
-   Task.common$.namedInstance = true;
-
-   /* default memory heap */
-   var Memory = xdc.useModule('xdc.runtime.Memory');
-   var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
-   var heapMemParams = new HeapMem.Params();
-   heapMemParams.size = 0x8000;
-   Memory.defaultHeapInstance = HeapMem.create(heapMemParams);
-
-   /* create a heap for MessageQ messages */
-   var HeapBuf = xdc.useModule('ti.sysbios.heaps.HeapBuf');
-   var params = new HeapBuf.Params;
-   params.align = 8;
-   params.blockSize = 512;
-   params.numBlocks = 20;
-
-XDC Runtime
-"""""""""""""
-The following configuration are in general used by an IPC application in BIOS
-::
-
-   /* application uses the following modules and packages */
-   xdc.useModule('xdc.runtime.Assert');
-   xdc.useModule('xdc.runtime.Diags');
-   xdc.useModule('xdc.runtime.Error');
-   xdc.useModule('xdc.runtime.Log');
-   xdc.useModule('xdc.runtime.Registry');
-
-   xdc.useModule('ti.sysbios.knl.Semaphore');
-   xdc.useModule('ti.sysbios.knl.Task');
-
-IPC Configuration
-""""""""""""""""""
-The following IPC modules are used in a typical IPC application.
-::
-
-   xdc.useModule('ti.sdo.ipc.Ipc');
-   xdc.useModule('ti.ipc.ipcmgr.IpcMgr');
-   var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
-   /* The following configures the PROC List */
-   MultiProc.setConfig("CORE0", ["HOST", "CORE0"]);
-
-   var msgHeap = HeapBuf.create(params);
-
-   var MessageQ  = xdc.useModule('ti.sdo.ipc.MessageQ');
-   /* Register msgHeap with messageQ */
-   MessageQ.registerHeapMeta(msgHeap, 0);
-
-The following lines configure placement of Resource table in memory.
-Note that some platforms or applications the placement of memory can be in a different section in the memory map.
-::
-
-   /* Enable Memory Translation module that operates on the Resource Table */
-   var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
-   Resource.loadSegment = Program.platform.dataMemory;
-
-Transport Configuration
-""""""""""""""""""""""""
-Typically the transport to be used by IPC is specified here. The following snippet configures RPMsg based transport.
-::
-
-   /* Setup MessageQ transport */
-   var VirtioSetup = xdc.useModule('ti.ipc.transports.TransportRpmsgSetup');
-   MessageQ.SetupTransportProxy = VirtioSetup;
-
-NameServer Configuration
-""""""""""""""""""""""""""
-The Name server to be used is specified here.
-::
-
-   /* Setup NameServer remote proxy */
-   var NameServer = xdc.useModule("ti.sdo.utils.NameServer");
-   var NsRemote = xdc.useModule("ti.ipc.namesrv.NameServerRemoteRpmsg");
-   NameServer.SetupProxy = NsRemote;
-
-
-Instrumentation Configuration
-""""""""""""""""""""""""""""""
-The following configuration are required for system logging and diagnostics.
-::
-
-     /* system logger */
-   var LoggerSys = xdc.useModule('xdc.runtime.LoggerSys');
-   var LoggerSysParams = new LoggerSys.Params();
-   var Defaults = xdc.useModule('xdc.runtime.Defaults');
-   Defaults.common$.logger = LoggerSys.create(LoggerSysParams);
-
-   /* enable runtime Diags_setMask() for non-XDC spec'd modules */
-   var Diags = xdc.useModule('xdc.runtime.Diags');
-   Diags.setMaskEnabled = true;
-
-   /* override diags mask for selected modules */
-   xdc.useModule('xdc.runtime.Main');
-   Diags.setMaskMeta("xdc.runtime.Main",
-       Diags.ENTRY | Diags.EXIT | Diags.INFO, Diags.RUNTIME_ON);
-
-   var Registry = xdc.useModule('xdc.runtime.Registry');
-   Registry.common$.diags_ENTRY = Diags.RUNTIME_OFF;
-   Registry.common$.diags_EXIT  = Diags.RUNTIME_OFF;
-   Registry.common$.diags_INFO  = Diags.RUNTIME_OFF;
-   Registry.common$.diags_USER1 = Diags.RUNTIME_OFF;
-   Registry.common$.diags_LIFECYCLE = Diags.RUNTIME_OFF;
-   Registry.common$.diags_STATUS = Diags.RUNTIME_OFF;
-
-   var Main = xdc.useModule('xdc.runtime.Main');
-   Main.common$.diags_ASSERT = Diags.ALWAYS_ON;
-   Main.common$.diags_INTERNAL = Diags.ALWAYS_ON;
-
-Other Optional Configurations
-""""""""""""""""""""""""""""""
-In addition to the above configurations there are other platform specific configurations may be used to enable certain features.
-
-For example the following sections shows the sections used to enable device exception handler. ( But the deh module may not be available on all devices)
-::
-
-   var Idle = xdc.useModule('ti.sysbios.knl.Idle');
-   var Deh = xdc.useModule('ti.deh.Deh');
-
-   /* Must be placed before pwr mgmt */
-   Idle.addFunc('&ti_deh_Deh_idleBegin');
-
-Building IPC examples using products.mak
------------------------------------------
-The following sections discuss how to individually build the IPC examples by modifying the product.mak file.
-
-The IPC product contains an examples/archive directory with device-specific examples.
-Once identifying your device, the examples can be unzipped anywhere on your build host.
-Typically once unzipped, the user edits the example's individual **products.mak** file and simply invokes **make**.
-
-.. note::
-  A common place to unzip the examples is into the **IPC_INSTALL_DIR/examples/** directory.
-  Each example's **products.mak** file is smart enough to look up two directories (in this case, into **IPC_INSTALL_DIR**)
-  for a master **products.mak** file, and if found it uses those variables.
-  This technique enables users to set the dependency variables in one place, namely **IPC_INSTALL_DIR/products.mak**.
-
-Each example contains a **readme.txt** with example-specific details.
-
-Generating Examples
-^^^^^^^^^^^^^^^^^^^^
-
-The IPC product will come with the generated examples directory.
-The IPC product is what is typically delivered with SDKs such as Processor SDK.
-However, some SDKs point directly to the IPC git tree for the IPC source.
-In this case, the IPC Examples can be generated separately.
-
-Tools
-^^^^^
-
-The following tools need to be installed:
- - `XDC tools <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/>`__ (check the IPC release notes for compatible version)
-
-Source Code
-^^^^^^^^^^^^
-
-::
-
-  mkdir ipc
-  cd ipc
-  git clone git://git.ti.com/ipc/ipc-metadata.git
-  git clone git://git.ti.com/ipc/ipc-examples.git
-
-Then checkout the IPC release tag that is associated with the IPC version being used. Do this for both repos. For example:
-
-::
-
-  git checkout 3.42.01.03
-
-Build
-^^^^^
-
-::
-
-  cd ipc-examples/src
-  make .examples XDC_INSTALL_DIR=<path_to_xdc_tools> IPCTOOLS=<path_to_ipc-metadata>/src/etc
-
-For example:
-::
-
-  make .examples XDC_INSTALL_DIR=/opt/ti/xdctools_3_32_00_06_core IPCTOOLS=/home/user/ipc/ipc-metadata/src/etc
-
-The "examples" director will be generated in the path "ipc-examples/src/":
-::
-
-  ipc-examples/src/examples
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_ListMP_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_ListMP_Module.rst
deleted file mode 100644
index 3d7d0859f..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_ListMP_Module.rst
+++ /dev/null
@@ -1,138 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/ListMP_Module
-
-.. |lmpCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |lmpRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_list_m_p_8h.html
-
-|
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |lmpCfg_Img1| | |lmpRun_Img1| |
-   +---------------+---------------+
-
-The ti.sdo.ipc.ListMP module is a linked-list based module designed to be used in a multi-processor environment.
-It is designed to provide a means of communication between different processors.
-ListMP uses shared memory to provide a way for multiple processors to share, pass, or store data buffers, messages, or state information.
-ListMP is a low-level module used by several other IPC modules, including MessageQ, HeapBufMP, and transports, as a building block for
-their instance and state structures.
-
-A common challenge that occurs in a multi-processor environment is preventing concurrent data access in shared memory between different processors.
-ListMP uses a multi-processor gate to prevent multiple processors from simultaneously accessing the same linked-list.
-All ListMP operations are atomic across processors.
-
-You create a ListMP instance dynamically as follows:
-
-# Initialize a ListMP_Params structure by calling ListMP_Params_init().
-# Specify the name, regionId, and other parameters in the ListMP_Params structure.
-# Call ListMP_create().
-
-ListMP uses a ti.sdo.utils.NameServer instance to store the instance information.
-The ListMP name supplied must be unique for all ListMP instances in the system.
-
-::
-
-  ListMP_Params params;
-  GateMP_Handle gateHandle;
-  ListMP_Handle handle1;
-
-  /* If gateHandle is NULL, the default remote gate will be
-     automatically chosen by ListMP */
-  gateHandle = GateMP_getDefaultRemote();
-  ListMP_Params_init(&params);
-  params.gate = gateHandle;
-  params.name = "myListMP";
-  params.regionId = 1;
-  handle1 = ListMP_create(&params, NULL);
-
-Once created, another processor or thread can open the ListMP instance by calling ListMP_open().
-
-::
-
-  while (ListMP_open("myListMP", &handle1, NULL) < 0) {
-      ;
-  }
-
-ListMP uses SharedRegion pointers (see SharedRegion Module), which are portable across processors, to translate addresses for shared memory.
-The processor that creates the ListMP instance must specify the shared memory in terms of its local address space.
-This shared memory must have been defined in the SharedRegion module by the application.
-The ListMP module has the following constraints:
-
-- ListMP elements to be added/removed from the linked-list must be stored in a shared memory region.
-- The linked list must be on a worst-case cache line boundary for all the processors sharing the list.
-- ListMP_open() should be called only when global interrupts are enabled.
-
-A list item must have a field of type ListMP_Elem as its first field. For example, the following structure could be used for list elements:
-
-::
-
-  typedef struct Tester {
-    ListMP_Elem elem;
-    Int         scratch[30];
-    Int         flag;
-  } Tester;
-
-Besides creating, opening, and deleting a list instance, the ListMP module provides functions for the following common list operations:
-
-- **ListMP_empty().** Test for an empty ListMP.
-- **ListMP_getHead().** Get the element from the front of the ListMP.
-- **ListMP_getTail().** Get the element from the end of the ListMP.
-- **ListMP_insert().** Insert element into a ListMP at the current location.
-- **ListMP_next().** Return the next element in the ListMP (non-atomic).
-- **ListMP_prev().** Return previous element in the ListMP (non-atomic).
-- **ListMP_putHead().** Put an element at the head of the ListMP.
-- **ListMP_putTail().** Put an element at the end of the ListMP.
-- **ListMP_remove().** Remove the current element from the middle of the ListMP.
-
-This example prints a "flag" field from the list elements in a ListMP instance in order:
-
-::
-
-  System_printf("On the List: ");
-  testElem = NULL;
-  while ((testElem = ListMP_next(handle, (ListMP_Elem *)testElem)) != NULL) {
-      System_printf("%d ", testElem->flag);
-  }
-
-This example prints the same items in reverse order:
-
-::
-
-  System_printf("in reverse: ");
-  elem = NULL;
-  while ((elem = ListMP_prev(handle, elem)) != NULL) {
-      System_printf("%d ", ((Tester  *)elem)->flag);
-  }
-
-This example determines if a ListMP instance is empty:
-
-::
-
-  if (ListMP_empty(handle1) == TRUE) {
-    System_printf("Yes, handle1 is empty\n");
-  }
-
-This example places a sequence of even numbers in a ListMP instance:
-
-::
-
-  /* Add 0, 2, 4, 6, 8 */
-  for (i = 0; i < COUNT; i = i + 2) {
-      ListMP_putTail(handle1, (ListMP_Elem *)&(buf[i]));
-  }
-
-The instance state information contains a pointer to the head of the linked-list, which is stored in shared memory.
-Other attributes of the instance stored in shared memory include the version, status, and the size of the shared address.
-Other processors can obtain a handle to the linked list by calling ListMP_open().
-
-The following figure shows local memory and shared memory for processors Proc 0 and Proc 1, in which Proc 0 calls ListMP_create() and Proc 1 calls ListMP_open().
-
-.. Image:: /images/IpcUG_ipc_2_4_1.png
-
-
-The cache alignment used by the list is taken from the SharedRegion on a per-region basis. The alignment must be the same across all processors and should be the worst-case cache line boundary.
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_List_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_List_Module.rst
deleted file mode 100644
index 8d2ad6e16..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_List_Module.rst
+++ /dev/null
@@ -1,161 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/List_Module
-
-.. |lisCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |lisRun_Img1| Image:: /images/Book_run.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/latest/docs/html/_list_8h.html
-
-|
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |lisCfg_Img1| | |lisRun_Img1| |
-   +---------------+---------------+
-
-The ti.sdo.utils.List module provides support for creating lists of objects.
-A List is implemented as a doubly-linked list, so that elements can be inserted or removed
-from anywhere in the list. Lists do not have a maximum size.
-
-
-Basic FIFO Operation of a List
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To add a structure to a List, its first field needs to be of type List_Elem.
-The following example shows a structure that can be added to a List.
-A List has a "head", which is the front of the list.
-List_put() adds elements to the back of the list, and List_get() removes and returns
-the element at the head of the list. Together, these functions support a FIFO queue.
-
-**Run-time example:** The following example demonstrates the basic List operations--List_put() and List_get().
-
-::
-
-  /* This structure can be added to a List because the first
-   * field is a List_Elem. Declared globally. */
-  typedef struct Rec {
-      List_Elem elem;
-      Int data;
-  } Rec;
-
-  ...
-
-  List_Handle myList;              /* in main() */
-  Rec r1, r2;
-  Rec* rp;
-
-  r1.data = 100;
-  r2.data = 200;
-
-  /* No parameters are needed to create a List. */
-  myList = List_create(NULL, NULL);
-
-  /* Add r1 and r2 to the back of myList. */
-  List_put(myList, &(r1.elem));
-  List_put(myList, &(r2.elem));
-
-  /* get the records and print their data */
-  while ((rp = List_get(myList)) != NULL) {
-      System_printf("rec: %d\n", rp->data);
-  }
-
-The example prints the following:
-
-::
-
-  rec: 100
-  rec: 200
-
-|
-
-Iterating Over a List
-^^^^^^^^^^^^^^^^^^^^^^^^
-The List module also provides several APIs for looping over a List.
-
-List_next() with NULL returns the element at the front of the List (without removing it).
-List_next() with an elem returns the next elem. NULL is returned when the end of the List is reached.
-
-Similarly, List_prev() with NULL returns the tail. List_prev() with an elem returns the previous elem.
-NULL is returned when the beginning of the List is reached.
-
-**Run-time example:** The following example demonstrates one way to iterate over a List
-once from beginning to end. In this example, "myList" is a List_Handle.
-
-::
-
-  List_Elem   *elem = NULL;
-  Rec* rp;
-
-  ...
-
-  /* To start the search at the beginning of the List */
-  rp = NULL;
-
-  /* Begin protection against modification of the List */
-  key = Gate_enterSystem();
-
-  while ((elem = List_next(myList, elem)) != NULL) {
-       System_printf("rec: %d\n", rp->data);
-  }
-  /* End protection against modification of the List */
-  Gate_leaveSystem(key);
-
-|
-
-Inserting and Removing List Elements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Elements can also be inserted or removed from anywhere in the middle of a List using List_insert() and List_remove().
-List_insert() inserts an element in front of the specified element.
-Use List_putHead() to place an element at the front of the List and List_put() to
-place an element at the end of the List.
-
-List_remove() removes the specified element from whatever List it is in.
-
-Note that List does not provide any APIs for inserting or removing elements at a given index in the List.
-
-**Run-time example:** The following example demonstrates List_insert() and List_remove():
-
-::
-
-  /* Insert r2 in front of r1 in the List. */
-  List_insert(myList, &(r1.elem), &(r2.elem));
-
-  /* Remove r1 from the List. */
-  List_remove(myList, &(r1.elem));
-
-|
-
-**Run-time example:** The following example treats the List as a LIFO stack using List_putHead() and List_get():
-
-::
-
-  List_Elem  elem[NUMELEM];
-  List_Elem *tmpElem;
-
-  // push onto the top (i.e. head)
-  for (i = 0; i < NUMELEM; i++) {
-      List_putHead(listHandle, &(elem[i]));
-  }
-
-  // remove the buffers in FIFO order.
-  while((tmpElem = List_get(listHandle)) != NULL) {
-      // process tmpElem
-  }
-
-|
-
-Atomic List Operations
-^^^^^^^^^^^^^^^^^^^^^^^^
-Lists are commonly shared across multiple threads in the system, which might lead to concurrent
-modifications of the List by different threads, which would corrupt the List.
-List provides several "atomic" APIs that disable interrupts before operating on the List.
-These APIs are List_get() List_put(), List_putHead(), and List_empty().
-
-An atomic API completes in core functionality without being interrupted.
-Therefore, atomic APIs are thread-safe. An example is List_put().
-Multiple threads can call this API at the same time.
-The threads do not have to manage the synchronization.
-
-Other APIs--List_prev(), List_next(), List_insert(), and List_remove()--should be protected by the application.
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_MessageQ_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_MessageQ_Module.rst
deleted file mode 100644
index 7687b6a5a..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_MessageQ_Module.rst
+++ /dev/null
@@ -1,510 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/MessageQ_Module
-
-.. |msgCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |msgCfg_Img2| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-
-.. |msgRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_message_q_8h.html
-
-.. |msgRun_Img2| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_message_q_8h.html
-
-|
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |msgCfg_Img1| | |msgRun_Img1| |
-   +---------------+---------------+
-
-
-The MessageQ module supports the structured sending and receiving of variable length messages.
-It is OS independent and works with any threading model. For each MessageQ you create,
-there is a single reader and may be multiple writers.
-
-MessageQ is the recommended messaging API for most applications.
-It can be used for both homogeneous and heterogeneous multi-processor messaging,
-along with single-processor messaging between threads.
-
-.. note::
-   The MessageQ module in IPC is similar in functionality to the MSGQ module in DSP/BIOS 5.x.
-
-The following are key features of the MessageQ module:
-
-- Writers and readers can be relocated to another processor with no runtime code changes.
-- Timeouts are allowed when receiving messages.
-- Readers can determine the writer and reply back.
-- Receiving a message is deterministic when the timeout is zero.
-- Messages can reside on any message queue.
-- Supports zero-copy transfers (BIOS only)
-- Messages can be sent and received from any type of thread.
-- The notification mechanism is specified by the application (BIOS only)
-- Allows QoS (quality of service) on message buffer pools. For example, using specific buffer pools for specific message queues. (BIOS only)
-
-Messages are sent and received via a message queue. A reader is a thread that gets (reads) messages
-from a message queue. A writer is a thread that puts (writes) a message to a message queue.
-Each message queue has one reader and can have many writers.
-A thread may read from or write to multiple message queues.
-
-- **Reader.** The single reader thread calls MessageQ_create(), MessageQ_get(), MessageQ_free(), and MessageQ_delete().
-- **Writer.** Writer threads call MessageQ_open(), MessageQ_alloc(), MessageQ_put(), and MessageQ_close().
-
-The following figure shows the flow in which applications typically use the main runtime MessageQ APIs:
-
-.. Image:: /images/IpcUG_ipc_2_3_1.png
-
-Conceptually, the reader thread creates and owns the message queue. Writer threads then open a created message queue to get access to them.
-
-Configuring the MessageQ Module (BIOS only)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-On BIOS-based systems, you can configure a number of module-wide properties for MessageQ in your XDCtools configuration file.
-
-|msgCfg_Img2| A snapshot of the MessageQ module configuration
-documentation is available `online <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html>`_.
-
-To configure the MessageQ module, you must enable the module as follows:
-
-::
-
-  var MessageQ = xdc.useModule('ti.sdo.ipc.MessageQ');
-
-Some example Module-wide configuration properties you can set follow; refer to the IPC documentation for details.
-
-::
-
-  // Maximum length of MessageQ names
-  MessageQ.maxNameLen = 32;
-
-  // Max number of MessageQs that can be dynamically created
-  MessageQ.maxRuntimeEntries = 10;
-
-Creating a MessageQ Object
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-You can create message queues dynamically. Static creation is not supported.
-A MessageQ object is not a shared resource. That is, it resides on the processor, within the process, that creates it.
-
-The reader thread creates a message queue. To create a MessageQ object dynamically,
-use the MessageQ_create() C API, which has the following syntax:
-
-::
-
-  MessageQ_Handle MessageQ_create(String name, MessageQ_Params *params);
-
-When you create a queue, you specify a name string. This name will be needed by the MessageQ_open() function,
-which is called by threads on the same or remote processors that want to send messages to the created message queue.
-While the name is not required (that is, it can be NULL), an unnamed queue cannot be opened.
-
-An ISync handle is associated with the message queue via the synchronizer parameter.
-
-If the call is successful, the MessageQ_Handle is returned. If the call fails, NULL is returned.
-
-You initialize the params struct by using the MessageQ_Params_init() function, which initializes the params structure with the default values. A NULL value for params can be passed into the create call, which results in the defaults being used.
-The default synchronizer is SyncSem.
-
-The following code creates a MessageQ object using SyncSem as the synchronizer.
-
-::
-
-  MessageQ_Handle   messageQ;
-  MessageQ_Params   messageQParams;
-  SyncSem_Handle    syncSemHandle;
-
-  ...
-
-  syncSemHandle = SyncSem_create(NULL, NULL);
-  MessageQ_Params_init(&messageQParams);
-  messageQParams.synchronizer = SyncSem_Handle_upCast(syncSemHandle);
-  messageQ = MessageQ_create(CORE0_MESSAGEQNAME, &messageQParams);
-
-In this example, the CORE0_MESSAGEQNAME constant may be defined in header shared by multiple cores.
-
-|msgRun_Img2| A snapshot of the MessageQ module run-time
-API documentation is available `online <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_message_q_8h.html>`_.
-
-
-Opening a Message Queue
-^^^^^^^^^^^^^^^^^^^^^^^^
-Writer threads open a created message queue to get access to them.
-In order to obtain a handle to a message queue that has been created,
-a writer thread must call MessageQ_open(), which has the following syntax.
-
-::
-
-  Int MessageQ_open(String name, MessageQ_QueueId *queueId);
-
-This function expects a name, which must match with the name of the created object.
-Internally MessageQ calls NameServer_get() to find the 32-bit queueId associated with the created message queue.
-NameServer looks both locally and remotely.
-
-If no matching name is found on any processor, MessageQ_open() returns MessageQ_E_NOTFOUND.
-If the open is successful, the Queue ID is filled in and MessageQ_S_SUCCESS is returned.
-
-The following code opens the MessageQ object created by the processor.
-
-::
-
-  MessageQ_QueueId   remoteQueueId;
-  Int                status;
-
-  ...
-
-  /* Open the remote message queue. Spin until it is ready. */
-  do {
-     status = MessageQ_open(CORE0_MESSAGEQNAME, &remoteQueueId);
-  }
-  while (status < 0);
-
-Allocating a Message
-^^^^^^^^^^^^^^^^^^^^^^
-MessageQ manages message allocation via the MessageQ_alloc() and MessageQ_free() functions.
-MessageQ uses Heaps for message allocation. MessageQ_alloc() has the following syntax:
-
-::
-
-  MessageQ_Msg MessageQ_alloc(UInt16        heapId,
-                              UInt32        size);
-
-The allocation size in MessageQ_alloc() must include the size of the message header, which is 32 bytes.
-
-The following code allocates a message:
-
-::
-
-  #define MSGSIZE                  256
-  #define HEAPID                     0
-  ...
-  MessageQ_Msg     msg;
-
-  ...
-
-  msg = MessageQ_alloc(HEAPID, sizeof(MessageQ_MsgHeader));
-  if (msg == NULL) {
-      System_abort("MessageQ_alloc failed\n");
-  }
-
-Once a message is allocated, it can be sent on any message queue.
-Once the reader receives the message, it may either free the message or re-use the message.
-Messages in a message queue can be of variable length.
-The only requirement is that the first field in the definition of a message must be a MsgHeader structure.
-For example:
-
-::
-
-  typedef struct MyMsg {
-      MessageQ_MsgHeader header;     // Required
-      SomeEnumType       type        // Can be any field
-      ...                            // ...
-  } MyMsg;
-
-The MessageQ APIs use the MessageQ_MsgHeader internally. Your application should not
-modify or directly access the fields in the MessageQ_MsgHeader structure.
-
-MessageQ Allocation and Heaps
-"""""""""""""""""""""""""""""""
-All messages sent via the MessageQ module must be allocated from a xdc.runtime.IHeap implementation, such as ti.sdo.ipc.heaps.HeapBufMP.
-The same heap can also be used for other memory allocation not related to MessageQ.
-
-The MessageQ_registerHeap() API assigns a MessageQ heapId to a heap. When allocating a message, the heapId is used, not the heap handle. The heapIds should start at zero and increase.
-The maximum number of heaps is determined by the numHeap module configuration property.
-See the online documentation for MessageQ_registerHeap() for details.
-
-::
-
-  /* Register this heap with MessageQ */
-  status = MessageQ_registerHeap( HeapBufMP_Handle_upCast(heapHandle), HEAPID);
-
-If the registration fails (for example, the heapId is already used), this function returns FALSE.
-
-An application can use multiple heaps to allow an application to regulate its message usage.
-For example, an application can allocate critical messages from a heap of fast on-chip memory and non-critical messages from a heap of slower external memory.
-Additionally, heaps MessageQ uses can be shared with other modules and/or the application.
-
-MessageQ alternatively supports allocating messages without the MessageQ_alloc() function.
-
-Heaps can be unregistered via MessageQ_unregisterHeap().
-
-MessageQ Allocation Without a Heap
-""""""""""""""""""""""""""""""""""""
-It is possible to send MessageQ messages that are allocated statically instead of being allocated at run-time via MessageQ_alloc().
-However the first field of the message must still be a MsgHeader.
-To make sure the MsgHeader has valid settings, the application must call MessageQ_staticMsgInit().
-This function initializes the header fields in the same way that MessageQ_alloc() does,
-except that it sets the heapId field in the header to the MessageQ_STATICMSG constant.
-
-If an application uses messages that were not allocated using MessageQ_alloc(), it cannot free the messages via the MessageQ_free() function,
-even if the message is received by a different processor. Also, the transport may internally call MessageQ_free()
-and encounter an error.
-
-If MessageQ_free() is called on a statically allocated message, it asserts that the heapId of the message is not MessageQ_STATICMSG.
-
-Sending a Message
-^^^^^^^^^^^^^^^^^^^
-Once a message queue is opened and a message is allocated, the message can be sent to the MessageQ via
-the MessageQ_put() function, which has the following syntax.
-
-::
-
-  Int MessageQ_put(MessageQ_QueueId queueId,
-                 MessageQ_Msg     msg);
-
-For example:
-
-::
-
-  status = MessageQ_put(remoteQueueId, msg);
-
-Opening a queue is not required. Instead the message queue ID can be "discovered"
-via the MessageQ_getReplyQueue() function, which returns the 32-bit queueId.
-
-::
-
-  MessageQ_QueueId replyQueue;
-  MessageQ_Msg     msg;
-
-  /* Use the embedded reply destination */
-  replyMessageQ = MessageQ_getReplyQueue(msg);
-  if (replyMessageQ == MessageQ_INVALIDMESSAGEQ) {
-      System_abort("Invalid reply queue\n");
-  }
-
-  /* Send the response back */
-  status = MessageQ_put(replyQueue, msg);
-      if (status < 0) {
-          System_abort("MessageQ_put was not successful\n");
-      }
-
-If the destination queue is local, the message is placed on the appropriate priority linked list and the ISync signal function is called.
-If the destination queue is on a remote processor, the message is given to the proper transport and returns.
-
-If MessageQ_put() succeeds, it returns MessageQ_S_SUCCESS. If MessageQ_E_FAIL is returned,
-an error occurred and the caller still owns the message.
-
-There can be multiple senders to a single message queue. MessageQ handles the thread safety.
-
-Before you send a message, you can use the MessageQ_setMsgId() function to assign a numeric value to the message that can be checked by the receiving thread.
-
-::
-
-  /* Increment...the remote side will check this */
-  msgId++;
-  MessageQ_setMsgId(msg, msgId);
-
-You can use the MessageQ_setMsgPri() function to set the priority of the message.
-
-Receiving a Message
-^^^^^^^^^^^^^^^^^^^^
-To receive a message, a reader thread calls the MessageQ_get() API.
-
-::
-
-  Int MessageQ_get(MessageQ_Handle handle,
-                   MessageQ_Msg    *msg,
-                   UInt            timeout)
-
-If a message is present, it returned by this function. In this case the ISync's wait() function is not called.
-For example:
-
-::
-
-  /* Get a message */
-  status = MessageQ_get(messageQ, &msg, MessageQ_FOREVER);
-  if (status < 0) {
-       System_abort("Should not happen; timeout is forever\n");
-  }
-
-If no message is present and no error occurs, this function blocks while waiting for the timeout period for the message to arrive.
-If the timeout period expires, MessageQ_E_FAIL is returned. If an error occurs, the msg argument will be unchanged.
-
-After receiving a message, you can use the following APIs to get information about the message from the message header:
-
-- MessageQ_getMsgId() gets the ID value set by MessageQ_setMsgId(). For example:
-
-::
-
-    /* Get the id and increment it to send back */
-    msgId = MessageQ_getMsgId(msg);
-    msgId += NUMCLIENTS;
-    MessageQ_setMsgId(msg, msgId);
-
-- MessageQ_getMsgPri() gets the priority set by MessageQ_setMsgPri().
-- MessageQ_getMsgSize() gets the size of the message in bytes.
-- MessageQ_getReplyQueue() gets the ID of the queue provided by MessageQ_setReplyQueue().
-
-Deleting a MessageQ Object
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-MessageQ_delete() frees a MessageQ object stored in local memory. If any messages are still on the internal linked lists, they will be freed.
-The contents of the handle are nulled out by the function to prevent use after deleting.
-
-::
-
-  Void MessageQ_delete(MessageQ_Handle *handle);
-
-The queue array entry is set to NULL to allow re-use.
-
-Once a message queue is deleted, no messages should be sent to it. A MessageQ_close() is recommended, but not required.
-
-Message Priorities
-^^^^^^^^^^^^^^^^^^^
-MessageQ supports three message priorities as follows:
-
-- MessageQ_NORMALPRI = 0
-- MessageQ_HIGHPRI = 1
-- MessageQ_URGENTPRI = 3
-
-You can set the priority level for a message before sending it by using the MessageQ_setMsgPri() function:
-
-::
-
-  Void MessageQ_setMsgPri(MessageQ_Msg        msg,
-                        MessageQ_Priority   priority)
-
-Internally a MessageQ object maintains two linked lists: normal and high-priority.
-A normal priority message is placed onto the "normal" linked list in FIFO manner.
-A high priority message is placed onto the "high-priority" linked list in FIFO manner.
-An urgent message is placed at the beginning of the high linked list.
-
-
-.. note::
-  Since multiple urgent messages may be sent before a message is read, the order of urgent messages is not guaranteed.
-
-When getting a message, the reader checks the high priority linked list first.
-If a message is present on that list, it is returned. If not, the normal priority linked list is checked.
-If a message is present there, it is returned. Otherwise the synchronizer's wait function is called.
-
-.. note::
-  The MessageQ priority feature is enabled by the selecting different MessageQ transports.
-  Some MessageQ implementations (e.g. Linux) may not support multiple transports and therefore may not support this feature.
-
-Thread Synchronization (BIOS only)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-MessageQ supports reads and writes of different thread models.
-It can work with threading models that include SYS/BIOS's Hwi, Swi, and Task threads.
-
-This flexibility is accomplished by using an implementation of the xdc.runtime.knl.ISync interface.
-The creator of the message queue must also create an object of the desired ISync implementation and assign that object as the "synchronizer" of the MessageQ.
-Each message queue has its own synchronizer object.
-
-An ISync object has two main functions: signal() and wait().
-Whenever MessageQ_put() is called, the signal() function of the ISync implementation is called.
-If MessageQ_get() is called when there are no messages on the queue, the wait() function of the ISync implementation is called.
-The timeout passed into the MessageQ_get() is directly passed to the ISync wait() API.
-
-.. note::
-  Since ISync implementations must be binary, the reader thread must drain the MessageQ of all messages before waiting for another signal.
-
-For example, if the reader is a SYS/BIOS Swi, the instance could be a SyncSwi.
-When a MessageQ_put() is called, the Swi_post() API would be called.
-The Swi would run and it must call MessageQ_get() until no messages are returned.
-If the Swi does not get all the messages, the Swi will not run again, or at least will not run until a new message is placed on the queue.
-
-The calls to ISync functions occurs directly in MessageQ_put() when the call occurs on the same processor where the queue was created. In the remote case, the transport calls MessageQ_put(), which is then a local put, and the signal function is called.
-
-The following are ISync implementations provided by XDCtools and SYS/BIOS:
-
-- **xdc.runtime.knl.SyncNull.** The signal() and wait() functions do nothing. Basically this implementation allows for polling.
-- **xdc.runtime.knl.SyncSemThread.** An implementation built using the xdc.runtime.knl.Semaphore module, which is a binary semaphore.
-- **xdc.runtime.knl.SyncGeneric.xdc.** This implementation allows you to use custom signal() and wait() functions as needed.
-- **ti.sysbios.syncs.SyncSem.** An implementation built using the ti.sysbios.ipc.Semaphore module. The signal() function runs a Semaphore_post(). The wait() function runs a Semaphore_pend().
-- **ti.sysbios.syncs.SyncSwi.** An implementation built using the ti.sysbios.knl.Swi module. The signal() function runs a Swi_post(). The wait() function does nothing and returns FALSE if the timeout elapses.
-- **ti.sysbios.syncs.SyncEvent.** An implementation built using the ti.sysbios.ipc.Event module. The signal() function runs an Event_post(). The wait() function does nothing and returns FALSE if the timeout elapses. This implementation allows waiting on multiple events.
-
-The following code from the "message" example creates a SyncSem instance and assigns it to the synchronizer field in the MessageQ_Params structure before creating the MessageQ instance:
-
-::
-
-  #include <ti/sysbios/syncs/SyncSem.h>
-  ...
-
-  MessageQ_Params   messageQParams;
-  SyncSem_Handle    syncSemHandle;
-
-  /* Create a message queue using SyncSem as synchronizer */
-  syncSemHandle = SyncSem_create(NULL, NULL);
-  MessageQ_Params_init(&messageQParams);
-  messageQParams.synchronizer = SyncSem_Handle_upCast(syncSemHandle);
-  messageQ = MessageQ_create(CORE1_MESSAGEQNAME, &messageQParams, NULL);
-
-ReplyQueue
-^^^^^^^^^^^^^
-For some applications, doing a MessageQ_open() on a queue is not realistic.
-For example, a server may not want to open all the clients' queues for sending responses.
-To support this use case, the message sender can embed a reply queueId in the message
-using the MessageQ_setReplyQueue() function.
-
-::
-
-  Void MessageQ_setReplyQueue(MessageQ_Handle handle,
-                            MessageQ_Msg msg)
-
-This API stores the message queue's queueId into fields in the MsgHeader.
-
-The MessageQ_getReplyQueue() function does the reverse. For example:
-
-::
-
-  MessageQ_QueueId replyQueue;
-  MessageQ_Msg     msg;
-  ...
-
-  /* Use the embedded reply destination */
-  replyMessageQ = MessageQ_getReplyQueue(msg);
-  if (replyMessageQ == MessageQ_INVALIDMESSAGEQ) {
-     System_abort("Invalid reply queue\n");
-  }
-
-The MessageQ_QueueId value returned by this function can then be used in a MessageQ_put() call.
-
-The queue that is embedded in the message does not have to be the sender's queue.
-
-Remote Communication via Transports (BIOS only)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-MessageQ is designed to support multiple processors. To allow this, different transports can be plugged into MessageQ.
-
-In a multi-processor system, MessageQ communicates with other processors via ti.sdo.ipc.interfaces.IMessageQTransport instances.
-There can be up to two IMessageQTransport instances for each processor to which communication is desired.
-One can be a normal-priority transport and the other for handling high-priority messages.
-This is done via the priority parameter in the transport create() function.
-If there is only one register to a remote processor (either normal or high), all messages go via that transport.
-
-There can be different transports on a processor. For example, there may be a shared memory transport to processor A and an sRIO one to processor B.
-
-When your application calls Ipc_start(), the default transport instance used by MessageQ is created automatically.
-Internally, transport instances are responsible for registering themselves with MessageQ via the MessageQ_registerTransport() function.
-
-IPC provides an implementation of the IMessageQTransport interface called ti.sdo.ipc.transports.TransportShm (shared memory).
-You can write other implementations to meet your needs.
-
-When a transport is created via a transport-specific create() call, a remote processor ID (defined via the MultiProc module) is specified.
-This ID denotes which processor this instance communicates with.
-Additionally there are configuration properties for the transport--such as the message priority handled--that can be defined in a Params structure.
-The transport takes these pieces of information and registers itself with MessageQ.
-MessageQ now knows which transport to call when sending a message to a remote processor.
-
-Trying to send to a processor that has no transport results in an error.
-
-Custom Transport Implementations
-"""""""""""""""""""""""""""""""""
-Transports can register and unregister themselves dynamically. That is, if the transport instance is deleted,
-it should unregister with MessageQ.
-
-When receiving a message, transports need to form the MessageQ_QueueId that allows them to call MessageQ_put().
-This is accomplished via the MessageQ_getDstQueue() API.
-
-::
-
-  MessageQ_QueueId MessageQ_getDstQueue(MessageQ_Msg msg)
-
-Sample Runtime Program Flow (Dynamic)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The following figure shows the typical sequence of events when using a MessageQ.
-A message queue is created by a Task. An open on the same processor then occurs.
-Assume there is one message in the system. The opener allocates the message and
-sends it to the created message queue, which gets and frees it.
-
-.. Image:: /images/IpcUG_ipc_2_3_2.png
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_MultiProc_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_MultiProc_Module.rst
deleted file mode 100644
index 36585db91..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_MultiProc_Module.rst
+++ /dev/null
@@ -1,252 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/MultiProc_Module
-
-.. |mpmCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |mpmCfg_Img2| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-
-.. |mpmRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_multi_proc_8h.html
-
-.. |mpmRun_Img2| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_multi_proc_8h.html
-
-|
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |mpmCfg_Img1| | |mpmRun_Img1| |
-   +---------------+---------------+
-
-Introduction
-^^^^^^^^^^^^^^
-
-Many IPC modules require the ability to uniquely specify and identify processors in a
-multi-processor environment. The MultiProc module centralizes processor ID management into one module.
-Most multi-processor IPC applications require that you configure this module using the MultiProc.setConfig()
-function in the *.cfg script. The setConfig() function tells the MultiProc module:
-
-- The specific processor for which this application is being built.
-- The processors in this cluster. A "cluster" is a set of processors within
-
-a system that share some memory and for which notification between those processors is needed.
-
-Most systems contain a single cluster. For systems with multiple clusters, you also need to configure the numProcessors and baseIdOfCluster properties.
-
-Each processor reference by the MultiProc module can be uniquely identified by either its name string or an integer ranging from 0 to MultiProc.maxProcessors - 1.
-
-The following XDCtools configuration statements set up a MultiProc array.
-At runtime, the "DSP" processor running this configuration gets assigned an ID value of 2.
-The other processors in the system are "VIDEO" with a processor ID of 0 and "DSS" with a
-processor ID of 1.
-
-::
-
-  /* DSP will get assigned processor id 2. */
-  var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
-  MultiProc.setConfig("DSP", ["VIDEO", "DSS", "DSP"]);
-
-|
-
-The ID is a software-only setting. It does not correlate to hardware core IDs or any other type of hardware identification. For devices with more than one core, each core must have its own unique processor ID. The ID is also independent of any OS setting.
-The processor ID is not always known at configuration time. It might need to be determined at initialization time via a GPIO pin, flash setting, or some other method. You can call the MultiProc_setLocalId() API (with the restriction that it must be called before module startup) to set the processor ID. However, other modules that use MultiProc need to know that the static ID will be changed during initialization. Setting the local name to NULL in the MultiProc.setConfig statement in the configuration indicates that the MultiProc_setLocalId() API will be used at runtime. Other modules that use MultiProc should act accordingly by deferring processing until the actual ID is known.
-
-For example, the following fragment of configuration code requires that the MultiProc_setLocalId() API be run during startup to fill in the NULL processor name.
-
-::
-
-  /* Specify startup function */
-  var Startup = xdc.useModule('xdc.runtime.Startup');
-  Startup.firstFxns.$add('&setMyId');
-
-  /* Specify MultiProc config; current processor unknown */
-  var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
-  MultiProc.setConfig(null, ["CORE0", "CORE1", "CORE2"]);
-
-|
-
-Then, the application code could contain the following setMyID() function to be run at startup:
-
-::
-
-  Void setMyId()
-  {
-      UInt16 procId;
-      Int    status;
-
-      //
-      // Board specific determination of processor id.
-      // Example: GPIO_READ reads register of GPIO pin 5
-      //
-      if (GPIO_READ(5) == 0) {
-            procId = 0;
-      }
-      else {
-         procId = 1;
-      }
-
-      MultiProc_setLocalId(procId);
-  }
-
-|
-
-Your application can query the MultiProc table using various runtime APIs.
-At runtime, the MultiProc_getId() call returns the MultiProc ID for any processor name. At config-time, the MultiProc.getIdMeta() call returns the same value. For example:
-
-::
-
-  core1ProcId = MultiProc_getId("CORE1");
-
-|
-
-MultiProc_self() returns the processor ID of the processor running the API. For example:
-
-::
-
-  System_printf("My MultiProc id = %d\n", MultiProc_self());
-
-|
-
-MultiProc_getBaseIdOfCluster() returns the MultiProc ID of the base processor in the cluster to which this processor belongs.
-The MultiProc_getName() API returns that processor name if given the MultiProc ID. For example:
-
-::
-
-  core0Name = MultiProc_getName(0);
-
-|
-
-MultiProc_getNumProcessors() evaluates to the total number of processors.
-
-::
-
-  System_printf("Number of processors in the system = %d\n",
-                MultiProc_getNumProcessors() );
-
-|
-
-MultiProc_getBaseIdOfCluster() returns the MultiProc ID of the base processor in the cluster to which this processor belongs.
-The MultiProc_getName() API returns that processor name if given the MultiProc ID. For example:
-
-::
-
-  core0Name = MultiProc_getName(0);
-
-|
-
-MultiProc_getNumProcessors() evaluates to the total number of processors.
-
-::
-
-  System_printf("Number of processors in the system = %d\n",
-                MultiProc_getNumProcessors() );
-
-|
-
-MultiProc_getNumProcsInCluster() returns the number of processors in the cluster to which this processor belongs.
-
-Configuring Clusters With the MultiProc Module
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-A "cluster" is a set of processors within a system that share some memory and for which notification between those processors is needed. If your system has multiple clusters, you need to configure the MultiProc module's numProcessors and baseIdOfCluster properties in addition to calling the MultiProc.setConfig() function.
-
-Notifications are not supported between different clusters.
-
-For example, in a system with two 'C6678 devices that each use eight homogeneous cores, you could configure the first 'C6678 device as follows:
-
-::
-
-  var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
-  MultiProc.baseIdOfCluster = 0;
-  MultiProc.numProcessors = 16;
-  MultiProc.setConfig(null, ["CORE0", "CORE1", "CORE2",
-           "CORE3", "CORE4", "CORE5", "CORE6", "CORE7"]);
-
-|
-
-You could configure the second 'C6678 device as follows:
-
-::
-
-  var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
-  MultiProc.baseIdOfCluster = 8;
-  MultiProc.numProcessors = 16;
-  MultiProc.setConfig(null, ["CORE0", "CORE1", "CORE2",
-           "CORE3", "CORE4", "CORE5", "CORE6", "CORE7"]);
-
-|
-
-Notice that the MultiProc.numProcessors property specifies the total number of processors in the system, while the length of the array passed to setConfig() specifies the number of processors in the cluster. (If you are not using multiple clusters, the numProcessors property is configured automatically.)
-The MultiProc.baseIdOfCluster property is set to the MultiProc ID number you want to use for the first processor in the array for this cluster. For example, if there are 8 processors in a cluster, the baseIdOfCluster property should be 0 for the first cluster and 8 for the second cluster.
-
-|mpmCfg_Img2| The latest version of the MultiProc module configuration documentation
-is available in `MultiProc page <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/index.html#ti/sdo/utils/MultiProc.html>`_
-
-
-Creating Connections with MultiProc
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The Ipc_start() and Ipc_attach() APIs can only be used to attach and synchronizes with processors in the same cluster.
-
-To create a connection between cores in different clusters, you must manually create a connection using the MessageQ and ti.sdo.ipc.NameServerMessageQ modules. The NameServerMessageQ module supports NameServer requests between different clusters by using MessageQ, which in turns uses the MessageQ transport to send a NameServer request.
-
-You can control the timeout period for the NameServerMessageQ module by configuring its timeoutInMicroSecs parameter, which defaults to 1 second. If a response is not received within the timeout period, the NameServer request returns a failure status. The NameServerRemoteNotify module also has a timeoutInMicroSecs parameter that you can configure; it defaults to wait forever.
-
-Creating a connection between cores in different clusters allows you to call MessageQ_open() even for a core on a different cluster. Note that these calls must occur after the MessageQ heap has been registered, because they allocate memory from the heap.
-
-Once the connection has been created, MessageQ can be used between different processors on different clusters just as it is used between different processors in the same cluster.
-
-|mpmRun_Img2| The latest version of the MultiProc module run-time API documentation is
-available in `MultiProc run-time API  <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_multi_proc_8h.html>`_
-
-
-Example
-^^^^^^^^^
-The following example function creates a NameServerMessageQ and TransportXXX to communicate remotely with a processor in a different cluster. The "remoteProcId" would be specified to be the MultiProc ID of the processor in the system. "TransportXXX" must be a copy-based transport that does not require any shared memory. You would need to create such a transport, because IPC does not provide one.
-
-::
-
-  Void myRemoteCreateFunction(Uint16 remoteProcId)
-  {
-      NameServerMessageQ_Params  nsParams;
-      NameServerMessageQ_Handle  nsHandle;
-      TransportXXX_Handle        tranHandle;
-      TransportXXX_Params        tranParams;
-      Error_Block eb;
-
-      Error_init(&eb);
-
-      /*
-       *  Note: You must register a MessageQ heap prior to
-       *  calling NameServerMessageQ_create().
-       */
-
-      /* init nsParams */
-      NameServerMessageQ_Params_init(&nsParams);
-
-      /* create driver to remote processor */
-      nsHandle = NameServerMessageQ_create(
-          remoteProcId, /* MultiProc ID of proc on 2nd cluster */
-          &nsParams,
-          &eb);
-        if (nsHandle == NULL) {
-          SYS_abort("NameServerMessageQ_create() failed");
-      }
-
-        /* initialize the transport parameters */
-      TransportXXX_Params_init(&tranParams);
-
-      tranHandle = TransportXXX_create(
-         remoteProcId, /* MultiProc ID of proc on 2nd cluster */
-         &tranParams,
-         &eb);
-      if (tranHandle == NULL) {
-          SYS_abort("TransportXXX_create() failed");
-      }
-  }
-
-|
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_NameServer_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_NameServer_Module.rst
deleted file mode 100644
index 82863446a..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_NameServer_Module.rst
+++ /dev/null
@@ -1,160 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/NameServer_Module 
-
-.. |nsmCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/index.html#ti/sdo/utils/NameServer.html
-
-.. |nsmCfg_Img2| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-                 
-.. |nsmRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_name_server_8h.html
-
-.. |nsmRun_Img2| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_name_server_8h.html
-                 
-| 
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |nsmCfg_Img1| | |nsmRun_Img1| |
-   +---------------+---------------+
-
-
-The NameServer module manages local name/value pairs. This enables an application and other modules to store and retrieve values based on a name.
-The NameServer module maintains thread-safety for its APIs. However, NameServer APIs cannot be called from an interrupt (that is, Hwi context). They can be called from Swis (BIOS-only) and Tasks.
-
-This module supports different lengths of values. The NameServer_add() and NameServer_get() functions support variable-length values. The NameServer_addUInt32() function is optimized for UInt32 variables and constants.
-
-The NameServer module currently does not perform any endian or word size conversion. Also there is no asynchronous support at this time.
-
-You can create NameServer instances dynamically. On BIOS, you can also create NameServer instances statically.
-
-Creating NameServer Instances Statically (BIOS-only)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To create a NameServer instance statically, you can add statements similar to the following to your XDCtools configuration script:
-
-::
-  
-  var NameServer = xdc.useModule('ti.sdo.utils.NameServer');
-   
-  var nameServerParams = new NameServer.Params;
-  nameServerParams.maxRuntimeEntries = 10;
-  nameServerParams.maxNameLen = 32;
-  var nameServer0 = NameServer.create("nameServer0", nameServerParams);
-
-If you want to specify the heap to be used by the NameServer module and a NameServer instance, use configuration statements similar to the following:
-
-
-::
-  
-  var NameServer = xdc.useModule('ti.sdo.utils.NameServer');
-  var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
-   
-  var heapParams = new HeapMem.Params;
-  heapParams.size = 1024;
-  var heapMem = HeapMem.create(heapParams);
-   
-  var nameServerParams = new NameServer.Params;
-  nameServerParams.tableHeap = heapMem;
-  var nameServer = NameServer.create("staticNameServer", nameServerParams);
-
-To create a NameServer instance dynamically, initialize a NameServer_Params structure with 
-NameServer_Params_init() and customize the values as needed. 
-The parameters include the following:
-
-- **checkExisting.** If true, NameServer check to see if a name already exists in the name/value table before adding it.
-- **maxNameLen.** Specify the maximum length, in characters, of the name field in the table.
-- **maxRuntimeEntries.** Specify the maximum number of name/value pairs this table can hold. If you set this parameter to NameServer_ALLOWGROWTH, then NameServer allows dynamic growth of the table.
-- **maxValueLen.** Specify the maximum length, in MAUs, of the value field in the table.
-- **tableHeap.** The heap to allocate the name/value table from when allocating dynamically. If this parameter is NULL, the heap used for object allocation is also used here.
-
-After setting parameters, use NameServer_create() to create an instance. 
-Each NameServer instance manages its own name/value table.
-
-|nsmCfg_Img2| The latest version of the NameServer module 
-configuration documentation is available `online <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html>`_.
-
-Creating and Removing NameServer Instances Dynamically
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The following C example creates a NameServer instance dynamically. 
-The instance allows a maximum of 10 runtime entries (instead of using ALLOWGROWTH). 
-This example also specifies where to allocate the memory needed for the tables (instead of using the default).
-
-::
-  
-  NameServer_Handle NSHandle;
-  NameServer_Params params;
-   
-  NameServer_Params_init(&params);
-  params.tableHeap = HeapStd_Handle_upCast(myHeap);
-  params.maxRuntimeEntries = 10;
-  NSHandle = NameServer_create("myTable", &params);
-  if (NSHandle == NULL) {
-      // manage error
-  }
-
-This example C code adds and removes entries at run-time:
-
-::
-  
-  Ptr key;
-   
-  key = NameServer_addUInt32(NSHandle, "volume", 5);
-  if (key == NULL) {
-      // manage error
-  }
-   
-  NameServer_removeEntry(NSHandle, key);
-  // or
-  NameServer_remove(NSHandle, "volume");
-
-
-|nsmRun_Img2| The latest version of the NameServer module run-time API 
-documentation is available `online <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_name_server_8h.html>`_.
-
-
-Searching NameServer Instances
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The following example searches the NameServer instance pointed to by "handle" on 
-the specified processor for a name-value pair with the name stored in nameToFind. 
-It returns the value of the pair to valueBuf.
-
-::
-  
-  /* Search NameServer */
-  status = NameServer_get(NSHandle, nameToFind, valueBuf, sizeof(UInt32), procId);
-
-Using different parameters for different table instances allows you to meet 
-requirements like the following:
-
-- **Size differences.** The maxValueLen parameter specifies the maximum length, in MAUs, of the value field in the table. One table could allow long values (for example, > 32 bits), while another table could be used to store integers. This customization enables better memory usage.
-- **Performance.** Multiple NameServer tables can improve the search time when retrieving a name/value pair.
-- **Relax name uniqueness.** Names in a specific table must be unique, but the same name can be used in different tables.
-
-When you call NameServer_delete(), the memory for the name/values pairs is freed. 
-You do not need to call NameServer_remove() on the entries before deleting a NameServer instance.
-
-Other NameServer APIs
-^^^^^^^^^^^^^^^^^^^^^^
-In addition to the functions mentioned above, the NameServer module provides the following APIs:
-
-- **NameServer_get()** Retrieves the value portion of a local name/value pair from the specified processor.
-- **NameServer_getLocal()** Retrieves the value portion of a local name/value pair.
-- **NameServer_remove()** Removes a name/value pair from the table given a name.
-- **NameServer_removeEntry()** Removes an entry from the table given a pointer to an entry.
-
-NameServer maintains the name/values table in local memory, not in shared memory. 
-However the NameServer module can be used in a multiprocessor system. 
-The module communicates with other processors via NameServer Remote drivers, 
-which are implementations of the INameServerRemote interface. 
-The communication to the other processors is dependent on the Remote drivers implementation. 
-When a remote driver is created, it registers with NameServer via the NameServer_registerRemoteDriver() API.
-
-The NameServer module uses the MultiProc module to identify different processors. 
-Which remote processors to query and the order in which they are queried is 
-determined by the procId array passed to the NameServer_get() function.
-
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_Notify_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_Notify_Module.rst
deleted file mode 100644
index 906f3fcee..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_Notify_Module.rst
+++ /dev/null
@@ -1,73 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/Notify_Module
-
-.. |notCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |notRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_notify_8h.html
-
-|
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |notCfg_Img1| | |notRun_Img1| |
-   +---------------+---------------+
-
-he ti.sdo.ipc.Notify module manages the multiplexing/demultiplexing of software interrupts over hardware interrupts.
-In order to use any Notify APIs, you must first call Ipc_start(). This sets up all the necessary Notify drivers, shared memory, and interprocessor interrupts. However, note that if you've configured Ipc.setupNotify = false, you will need to explicitly call Notify_start() outside the scope of Ipc_start().
-
-To be able to receive notifications, a processor registers one or more callback functions to an eventId by calling Notify_registerEvent(). The callback function must have the following signature:
-
-::
-
-  Void cbFxn(UInt16 procId, UInt16 lineId, UInt32 eventId, UArg arg, UInt32 payload);
-
-Notify_registerEvent(), like most other Notify APIs, uses a MultiProc ID and line ID to target a specific interrupt line to/from a specific processor on a device.
-
-::
-
-  Int status;
-  armProcId = MultiProc_getId("ARM");
-
-  Ipc_start();
-
-  /* Register cbFxn with Notify. It will be called when ARM
-   * sends event number EVENTID to line #0 on this processor.
-   * The argument 0x1010 is passed to the callback function. */
-  status = Notify_registerEvent(armProcId, 0, EVENTID,
-                   (Notify_FnNotifyCbck)cbFxn, 0x1010);
-  if (status < 0) {
-      System_abort("Notify_registerEvent failed\n");
-  }
-
-The line ID number is typically 0 (zero), but is provided for use on systems that have multiple interrupt lines between processors.
-
-When using Notify_registerEvent(), multiple callbacks may be registered with a single event. If you plan to register only one callback function for an event on this processor, you can call Notify_registerEventSingle() instead of Notify_registerEvent(). Better performance is provided with Notify_registerEventSingle(), and a Notify_E_ALREADYEXISTS status is returned if you try to register a second callback for the same event.
-
-Once an event has been registered, a remote processor may "send" an event by calling Notify_sendEvent(). If the specified event and interrupt line are both enabled, all callback functions registered to the event will be called sequentially.
-
-::
-
-  while (seq < NUMLOOPS) {
-    Semaphore_pend(semHandle, BIOS_WAIT_FOREVER);
-    /* Semaphore_post is called by callback function*/
-    status = Notify_sendEvent(armProcId, 0, EVENTID, seq, TRUE);
-  }
-
-In this example, the seq variable is sent as the "payload" along with the event. The payload is limited to a fixed size of 32 bits.
-
-Since the fifth argument in the previous example call to Notify_sendEvent() is TRUE, if any previous event to the same event ID was sent, the Notify driver waits for an acknowledgement that the previous event was received.
-
-A specific event may be disabled or enabled using Notify_disableEvent() and Notify_enableEvent(). All notifications on an entire interrupt line may be disabled or restored using Notify_disable() and Notify_restore() calls. Notify_disable() does not alter the state of individual events. Instead, it just disables the ability of the Notify module to receive events on the specified interrupt line.
-
-"Loopback" mode, which is enabled by default, allows notifications to be registered and sent locally. This is accomplished by supplying the processor's own MultiProc ID to Notify APIs. Line ID 0 (zero) is always used for local notifications. It is important to be aware of some subtle (but important) differences between remote and local notifications:
-
- - Loopback callback functions execute in the context of the same thread that called Notify_sendEvent(). This is in contrast to callback functions called due to another processor's sent notification--such "remote" callback functions execute in an ISR context.
- - Loopback callback functions execute with interrupts disabled.
- - Disabling the local interrupt line causes all notifications that are sent to the local processor to be lost. By contrast, a notification sent to an enabled event on a remote processor that has called Notify_disableEvent() results in a pending notification until the disabled processor has called Notify_restore().
- - Local notifications do not support events of different priorities. By contrast, Notify driver implementations may correlate event IDs with varying priorities.
-
-.. note::
-  The Notify Module is only supported in SYS/BIOS environments. It is not provided on HLOS's.
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_Optimizing_IPC_Applications.rst b/source/rtos/PDK_Platform_Software/IPC/_Optimizing_IPC_Applications.rst
deleted file mode 100644
index 4038570d4..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_Optimizing_IPC_Applications.rst
+++ /dev/null
@@ -1,572 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/Optimizing_IPC_Applications
-
-Compiler and Linker Optimization
-----------------------------------
-
-You can optimize your application for better performance and code size
-or to give you more debugging information by selecting different ways of
-compiling and linking your application. For example, you can do this by
-linking with versions of the SYS/BIOS and IPC libraries that were
-compiled differently.
-
-The choices you can make related to compiler and linker optimization are
-located in the following places:
-
--  **RTSC Build-Profile.** You see this field when you are creating a
-   new CCS project or modifying the CCS Build settings. We recommend
-   that you use the "release" setting. The "release" option is preferred
-   even when you are creating and debugging an application; the "debug"
-   option is mainly intended for internal use by Texas Instruments. The
-   "release" option results in a somewhat smaller executable that can
-   still be debugged. This build profile primarily affects how Codec
-   Engine and some device drivers are built.
-
-.. note::
-
-   The "whole_program" and "whole_program_debug" options for the RTSC
-   Build-Profile have been deprecated, and are no longer recommended.
-   The option that provides the most similar result is to set the
-   BIOS.libType configuration property to BIOS.LibType_Custom.
-
-
--  **CCS Build Configuration.** This setting in the CCS Build settings
-   allows you to choose between and customize multiple build
-   configurations. Each configuration can have the compiler and linker
-   settings you choose.
--  **BIOS.libType configuration property.** You can set this property in
-   XGCONF or by editing the .cfg file in your project. This property
-   lets you select from two pre-compiled versions of the SYS/BIOS and
-   IPC libraries or to have a custom version of the SYS/BIOS and IPC
-   libraries compiled based on the needs of your application. See the
-   table and discussion that follow for more information.
-
-The options for the BIOS.libType configuration property are as follows:
-
-+-------------+-------------+-------------+-------------+-------------+
-| BIOS.libTyp | Compile     | Logging     | Code Size   | Run-Time    |
-| e           | Time        |             |             | Performance |
-+=============+=============+=============+=============+=============+
-| Instrumente | Fast        | On          | Good        | Good        |
-| d           |             |             |             |             |
-| (BIOS.LibTy |             |             |             |             |
-| pe_Instrume |             |             |             |             |
-| nted)       |             |             |             |             |
-+-------------+-------------+-------------+-------------+-------------+
-| Non-Instrum | Fast        | Off         | Better      | Better      |
-| ented       |             |             |             |             |
-| (BIOS.LibTy |             |             |             |             |
-| pe_NonInstr |             |             |             |             |
-| umented)    |             |             |             |             |
-+-------------+-------------+-------------+-------------+-------------+
-| Custom      | Fast (slow  | As          | Best        | Best        |
-| (BIOS.LibTy | first time) | configured  |             |             |
-| pe_Custom)  |             |             |             |             |
-+-------------+-------------+-------------+-------------+-------------+
-| Debug       | Slower      | As          |             |             |
-| (BIOS.LibTy |             | configured  |             |             |
-| pe_Debug)   |             |             |             |             |
-+-------------+-------------+-------------+-------------+-------------+
-
--  **Instrumented.** (default) This option links with pre-built SYS/BIOS
-   (and IPC) libraries that have instrumentation available. All Asserts
-   and Diags settings are checked. Your configuration file can enable or
-   disable various Diags and logging related settings. However, note
-   that the checks to see if Diags are enabled before outputting a Log
-   event are always performed, which has an impact on performance even
-   if you use the ALWAYS_ON or ALWAYS_OFF setting. The resulting code
-   size when using this option may be too large to fit on some targets,
-   such as C28x and MSP430. This option is easy to use and debug and
-   provides a fast build time.
--  **Non-Instrumented.** This option links with pre-built SYS/BIOS (and
-   IPC) libraries that have instrumentation turned off. No Assert or
-   Diag settings are checked, and logging information is not available
-   at run-time. The checking for Asserts and Diags is compiled out of
-   the libraries, so run-time performance and code size are optimized.
-   Checking of Error_Blocks and handling errors in ways other than
-   logging an event are still supported. This option is easy to use and
-   provides a fast build time.
--  **Custom.** This option builds custom versions of the SYS/BIOS (and
-   IPC) libraries that contain the modules and APIs that your
-   application needs to access. If you have not used a particular module
-   in your .cfg file or your C code (and it is not required internally
-   by a SYS/BIOS module that is used), that module is not contained in
-   the custom libraries compiled for your application. This option
-   provides the best run-time performance and best code size given the
-   needs of your application. Instrumentation is available to whatever
-   extent your application configures it.
-
-   The first time you build a project with the custom libType, the build
-   will be longer. The custom libraries are stored in the "src"
-   directory of your project. Subsequent builds may be faster; libraries
-   do not need to be rebuilt unless you change one of the few
-   configuration properties that affect the build settings, or you use
-   an additional module that wasn't already used in the previous
-   configuration.:
-
-.. note::
-
-   If you disable SYS/BIOS Task or Swi scheduling, you must use the
-   "custom" option in order to successfully link your application.
-
-   The custom option uses program optimization that removes many
-   initialized constants and small code fragments (often "glue" code)
-   from the final executable image. Such classic optimizations as
-   constant folding and function inlining are used, including across
-   module boundaries. The custom build preserves enough debug
-   information to make it still possible to step through the optimized
-   code in CCS and locate global variables.:
-
--  **Debug.** This option is not recommended; it is intended for
-   internal use by Texas Instruments developers.
-
-The following example statements set the BIOS.libType configuration
-property:
-
-::
-
-    var BIOS = xdc.useModule('ti.sysbios.BIOS');
-    BIOS.libType = BIOS.LibType_Custom;
-
-If you use the custom option for the BIOS.libType, you can also set the
-BIOS.customCCOpts property to customize the C compiler command-line
-options used when compiling the SYS/BIOS libraries. If you want to
-change this property, it is important to first examine and understand
-the default command-line options used to compile the SYS/BIOS libraries
-for your target. You can see the default in XGCONF or by placing the
-following statement in your configuration script and building the
-project:
-
-::
-
-    print("customCCOpts =", BIOS.customCCOpts);
-
-Be careful not to cause problems for the SYS/BIOS compilation when you
-modify this property. For example, the --program_level_compile option is
-required. (Some --define and --include_path options are used on the
-compiler command line but are not listed in the customCCOpts definition;
-these also cannot be removed.)
-For example, to create a debuggable custom library, you can remove the
--o3 option from the BIOS.customCCOpts definition by specifying it with
-the following string for a C64x+ target:
-
-::
-
-    BIOS.customCCOpts = "-mv64p --abi=eabi -q -mi10 -mo -pdr -pden -pds=238 -pds=880
-      -pds1110  --embed_inline_assembly --program_level_compile -g";
-
-
-Optimizing Runtime Performance
---------------------------------
-
-You can use one or more of the following techniques to improve the
-runtime performance of IPC applications:
-
--  After you have finished debugging an application, you can disable
-   asserts and logging with the following configuration statements:
-
-::
-
-       var Diags = xdc.useModule("xdc.runtime.Diags");
-       var Defaults = xdc.useModule('xdc.runtime.Defaults');
-       Defaults.common$.diags_ASSERT = Diags.ALWAYS_OFF;
-       Defaults.common$.logger = null;
-
--  If shared memory has the same address on all processors, you can use
-   the following configuration statement to set the
-   SharedRegion.translate property to false. See `SharedRegion
-   Module <index_Foundational_Components.html#shared-region-module>`__ for more
-   about SharedRegion configuration.
-
-::
-
-       SharedRegion.translate = false;
-
--  Ensure that code, data, and shared data are all placed in cacheable
-   memory. Refer to the SYS/BIOS documentation for information on how to
-   configure a cache. See the *TI SYS/BIOS Real-time* *Operating System
-   v6.x User's Guide* (`SPRUEX3 <http://www.ti.com/lit/pdf/SPRUEX3>`__)
-   for details.
--  You can reduce contention between multiple processors and multiple
-   threads by creating a new gate for use by a new IPC module instance.
-   Leaving the params.gate property set to NULL causes the default
-   system GateMP instance to be used for context protection. However, in
-   some cases it may be optimal to create a new GateMP instance and
-   supply it to the instance creation. See `GateMP
-   Module <index_Foundational_Components.html#gatemp-module>`__ for more
-   information. For example:
-
-.. code-block:: c
-
-       GateMP_Params gateParams;
-       GateMP_Handle gateHandle;
-       HeapBufMP_Params heapParams;
-        
-       GateMP_Params_init(&gateParams);
-       gateHandle = GateMP_create(&gateParams);
-        
-       HeapBufMP_Params_init(&heapParams);
-       heapParams.gate = gateHandle;
-
-
--  If a unicache is shared between two cores in shared memory and you
-   expect to share certain IPC instances (such as a GateMP or ListMP)
-   solely between those two cores, you may be able to improve
-   performance by creating a SharedRegion with cache disabled for use
-   between those two cores only. Since region 0 needs to be accessible
-   by all cores on a system, region 1 can be created with a cache line
-   size of 0 and a cacheEnable configuration of FALSE. Any IPC instance
-   created within a SharedRegion inherits the cache settings (the
-   cacheEnabled flag and the cacheLineSize) from this region. Therefore,
-   unnecessary cache operations can be avoided by creating an instance
-   in region 1.
-
-   The following configuration statements create a SharedRegion with the
-   cache disabled (on OMAP4430):
-
-.. code-block:: c
-
-       SharedRegion.setEntryMeta(1, /* Create shared region 1 */
-           {   base: 0x86000000,
-               len: 0x10000,
-               ownerProcId: 0,
-               isValid: true,
-               cacheEnabled: false, /* Cache operations unneeded */
-               cacheLineSize: 0, /* Cache padding unneeded */
-               name: "DDR2",
-           });
-
-
-   The following C code creates a HeapBufMP instance in this
-   SharedRegion::
-
-.. code-block:: c
-
-       HeapBufMP_Params heapParams;
-       HeapBufMP_Handle heapHandle;
-        
-       HeapBufMP_Params_init(&heapParams);
-       heapParams.regionId = 1;
-        
-       heapHandle = HeapBufMP_create(&heapParams);
-
-   This heap can be used by either of the Cortex M3 cores on an
-   OMAP4430, because they both share a unicache. Do not use this heap
-   (or anything else belonging to a SharedRegion with caching disabled)
-   from any other processor if the shared memory belonging to the
-   SharedRegion is cacheable.
-
-Optimizing Notify and MessageQ Latency
----------------------------------------
-
-By default, IPC applications are configured to use the
-ti.sdo.ipc.notifyDrivers.NotifyDriverShm Notify driver and the
-ti.sdo.ipc.transports.TransportShm MessageQ transport. These modules are
-used by default because they offer backward compatibility with older
-IPC/SysLink releases. In addition, these modules may offer functionality
-not supported by their newer, lower-latency counterparts.
-
-If your application does not need functionality provided only by the
-default Notify drivers or MessageQ transport, you can reduce the latency
-by switching to alternative MessageQ transports and/or Notify drivers.
-
-Choosing and Configuring Notify Drivers
-----------------------------------------
-
-To switch to a different Notify driver, set the Notify.SetupProxy
-configuration to the family-specific Notify setup module. For example,
-the following statements configure an application on the DM6446 to use
-the NotifyDriverCirc driver for that device:
-
-::
-
-    var Notify = xdc.useModule('ti.sdo.ipc.Notify');
-    Notify.SetupProxy = xdc.useModule('ti.sdo.ipc.family.dm6446.NotifyCircSetup');
-
-|
-
-
-IPC provides the following Notify drivers. Each has a corresponding
-setup module that should be used as the Notify.SetupProxy module.
-
-+-----------------------------------------------+-----------------------+-----------------------+
-| Modules and                                   | Supports Disabling    | Latency               |
-| Description                                   | and Enabling Events   |                       |
-+===============================================+=======================+=======================+
-| ti.sdo.ipc.notifyDrivers.NotifyDriverShm      | Yes                   | Default               |
-| ti.sdo.ipc.family.<family>.NotifySetup        |                       |                       |
-|                                               |                       |                       |
-| |                                             |                       |                       |
-|                                               |                       |                       |
-| This shared-memory Notify driver offers       |                       |                       |
-| room for a single pending notification        |                       |                       |
-| in shared memory per event.                   |                       |                       |
-|                                               |                       |                       |
-+-----------------------------------------------+-----------------------+-----------------------+
-| ti.sdo.ipc.notifyDrivers.NotifyDriverCirc     | No                    | Better than           |
-| ti.sdo.ipc.family.<family>.NotifyCircSetup    |                       | NotifyDriverShm       |
-|                                               |                       |                       |
-| |                                             |                       |                       |
-|                                               |                       |                       |
-| This shared-memory                            |                       |                       |
-| Notify driver uses a                          |                       |                       |
-| circular buffer to                            |                       |                       |
-| store notifications.                          |                       |                       |
-| Unlike                                        |                       |                       |
-| NotifyDriverShm, this                         |                       |                       |
-| driver stores all                             |                       |                       |
-| notifications in the                          |                       |                       |
-| same circular buffer                          |                       |                       |
-| (whose size is                                |                       |                       |
-| configurable).                                |                       |                       |
-+-----------------------------------------------+-----------------------+-----------------------+
-| ti.sdo.ipc.family.ti8                         | No                    | Better than           |
-| 1xx.\ **NotifyDriverM                         |                       | NotifyDriverCirc and  |
-| bx**                                          |                       | NotifyDriverShm       |
-| ti.sdo.ipc.family.ti8                         |                       |                       |
-| 1xx.NotifyMbxSetup                            |                       |                       |
-|                                               |                       |                       |
-| |                                             |                       |                       |
-|                                               |                       |                       |
-| This TI81xx-only                              |                       |                       |
-| Notify driver uses                            |                       |                       |
-| the hardware mailbox.                         |                       |                       |
-| This driver is not                            |                       |                       |
-| usable by other                               |                       |                       |
-| devices.                                      |                       |                       |
-| Notifications are                             |                       |                       |
-| stored in hardware                            |                       |                       |
-| mailbox queues                                |                       |                       |
-| present on TI81xx                             |                       |                       |
-| devices.                                      |                       |                       |
-+-----------------------------------------------+-----------------------+-----------------------+
-
-Choosing and Configuring MessageQ Transports
----------------------------------------------
-
-Similarly, to use an alternative MessageQ transport, configure the
-MessageQ.SetupTransportProxy property to use the transport's
-corresponding Transport Setup proxy. For example, to use the
-TransportShmNotify module, use the following configuration:
-
-::
-
-    var MessageQ = xdc.module('ti.sdo.ipc.MessageQ');
-    MessageQ.SetupTransportProxy =
-          xdc.module('ti.sdo.ipc.transports.TransportShmNotifySetup');
-
-Unlike the Notify setup modules, Transport setup modules are generally
-not family-specific; most are located in the ti.sdo.ipc.transports
-package.
-IPC provides the following transports. Each has a corresponding setup
-module for use as the MessageQ.SetupTransportProxy module.
-
-+-----------------------------------+-----------------------------------+
-| Modules and Description           | Transport Speed                   |
-+===================================+===================================+
-| ti.sdo.ipc.transports.\ **Transpo | Slowest                           |
-| rtShm**                           |                                   |
-| ti.sdo.ipc.transports.TransportSh |                                   |
-| mSetup                            |                                   |
-|                                   |                                   |
-| |                                 |                                   |
-|                                   |                                   |
-| This shared-memory MessageQ       |                                   |
-| transport uses ListMP to          |                                   |
-| temporarily queue messages in     |                                   |
-| shared memory before the messages |                                   |
-| are moved to the destination      |                                   |
-| queue. This transport is          |                                   |
-| typically slowest because of the  |                                   |
-| overhead of queuing messages      |                                   |
-| using a linked list. This is the  |                                   |
-| default MessageQ transport.       |                                   |
-|                                   |                                   |
-+-----------------------------------+-----------------------------------+
-| ti.sdo.ipc.transports.\ **Transpo | Medium                            |
-| rtShmCirc**                       |                                   |
-| ti.sdo.ipc.transports.TransportSh |                                   |
-| mCircSetup                        |                                   |
-|                                   |                                   |
-| |                                 |                                   |
-|                                   |                                   |
-| This shared-memory MessageQ       |                                   |
-| transport uses a fixed-length     |                                   |
-| circular buffer to temporarily    |                                   |
-| queue messages in shared memory   |                                   |
-| before the messages are moved to  |                                   |
-| the destination queue. This       |                                   |
-| transport is typically faster     |                                   |
-| than TransportShm because of the  |                                   |
-| efficiencies gained by using a    |                                   |
-| circular buffer instead of a      |                                   |
-| linked list.                      |                                   |
-+-----------------------------------+-----------------------------------+
-| ti.sdo.ipc.transports.\ **Transpo | Fastest, but depends on fast      |
-| rtShmNotify**                     | processing of messages by         |
-| ti.sdo.ipc.transports.TransportSh | receiver                          |
-| mNotifySetup                      |                                   |
-|                                   |                                   |
-| |                                 |                                   |
-|                                   |                                   |
-| This shared-memory MessageQ       |                                   |
-| transport does no buffering       |                                   |
-| before the messages are moved to  |                                   |
-| the destination queue. Because of |                                   |
-| the lack of buffering, this       |                                   |
-| transport tends to offer lower    |                                   |
-| MessageQ latency than either      |                                   |
-| TransportShm or TransportShm.     |                                   |
-| However, If messages aren't       |                                   |
-| received quickly enough by the    |                                   |
-| receiver, the sender may spin     |                                   |
-| while waiting for the receiver to |                                   |
-| move the message to its local     |                                   |
-| queue.                            |                                   |
-+-----------------------------------+-----------------------------------+
-
-Optimizing Shared Memory Usage
--------------------------------
-
-You can use one or more of the following techniques to reduce the shared
-memory footprint of IPC applications:
-
--  If some connections between processors are not needed, it is not
-   necessary to attach to those cores. To selectively attach between
-   cores, use pair-wise synchronization as described in `Ipc
-   Module <index_Foundational_Components.html#ipc-module>`__. Your C code must
-   call Ipc_attach() for processors you want to connect to if you are
-   using pair-wise synchronization. The following configuration
-   statement causes the Ipc module to expect pair-wise synchronization.
-
-::
-
-   Ipc.procSync = Ipc.ProcSync_PAIR;
-
-|
-
-At run-time, only call Ipc_attach() to a remote processor if one or
-more of the following conditions is true::
-
-   -  The remote processor is the owner of region 0.
-   -  It is necessary to send Notifications between this processor and
-      the remote processor.
-   -  It is necessary to send MessageQ messages between this processor
-      and the remote processor.
-   -  It is necessary for either the local or remote processor to open a
-      module instance using *MODULE*\ \_open() that has been created on
-      the other processor.
-
--  Configure the Ipc.setEntryMeta property to disable components of IPC
-   that are not required. For example, if an application uses Notify but
-   not MessageQ, disabling MessageQ avoids the creation of MessageQ
-   transports during Ipc_attach().
-
-.. code-block:: c
-
-           /* To avoid wasting shared mem for MessageQ transports */
-           for (var i = 0; i < MultiProc.numProcessors; i++) {
-               Ipc.setEntryMeta({
-                   remoteProcId: 1,
-                   setupMessageQ: false,
-               });
-           }
-
--  Configure Notify.numEvents to a lower number. The default value of 32
-   is often significantly more than the total number of Notify events
-   required on a system. See `Notify
-   Module <index_Foundational_Components.html#notify-module>`__ for more
-   information.
-
-   For example, a simple MessageQ application may simply use two events
-   (one for NameServer and one for the MessageQ transport). In this
-   case, we can optimize memory use with the following configuration:
-
-.. code-block:: javascript
-
-    var Notify = xdc.useModule('ti.sdo.ipc.Notify');
-
-    /* Reduce the total number of supported events from 32 to 2 */
-    Notify.numEvents = 2;
-
-    var NameServerRemoteNotify = xdc.useModule('ti.sdo.ipc.NameServerRemoteNotify');
-    NameServerRemoteNotify.notifyEventId = 1;
-
-    var TransportShm = xdc.useModule('ti.sdo.ipc.transports.TransportShm');
-    TransportShm.notifyEventId = 0;
-
--  Reduce the cacheLineSize property of a SharedRegion to reflect the
-   actual size of the cache line. IPC uses the cacheLineSize setting to
-   pad data structures in shared memory. Padding is required so that
-   cache write-back and invalidate operations on data in shared memory
-   do not affect the cache status of adjacent data. The larger the
-   cacheLineSize setting, the more shared memory is used for the sole
-   purpose of padding. Therefore, the cacheLineSize setting should
-   optimally be set to the actual size of the cache line. The default
-   cacheLineSize for SharedRegion is 128. Using the correct size has
-   both performance and size benefits.
-
-   The following example (for C6472) sets the cacheLineSize property to
-   64 because the shared L2 memory has this cache line size.
-
-.. code-block:: c
-
-           SharedRegion.setEntryMeta(0,
-               { base: SHAREDMEM,
-                 len: SHAREDMEMSIZE,
-                 ownerProcId: 0,
-                 isValid: true,
-                 cacheLineSize: 64, /* SL2 cache line size = 64 */
-                 name: "SL2_RAM",
-               });
-
-Optimizing Local Memory Usage
---------------------------------
-
-If the Custom1 and Custom2 GateMP proxies will never be used, make sure
-they are both plugged with the ti.sdo.ipc.gates.GateMPSupportNull GateMP
-delegate. By default, GateMP plugs the Custom1 proxy with the
-GatePeterson delegate. A considerable amount of local memory is reserved
-for use by GatePeterson. You can plug the Custom1 proxy with the
-GateMPSupportNull delegate by adding the following configuration
-statements to your application:
-
-.. code-block:: javascript
-
-    var GateMP = xdc.useModule('ti.sdo.ipc.GateMP');
-    GateMP.RemoteCustom1Proxy = xdc.useModule('ti.sdo.ipc.gates.GateMPSupportNull');
-
-Optimizing Code Size
----------------------
-
-This section provides tips and suggestions for minimizing the code size
-of a SYS/BIOS-based application that uses IPC.
-
--  For a number of ways to configure SYS/BIOS that reduce code size by
-   using custom built SYS/BIOS libraries and by disabling various
-   features, see Section E.3 of the *TI SYS/BIOS Real-time Operating*
-   *System v6.x User's Guide*
-   (`SPRUEX3 <http://www.ti.com/lit/pdf/SPRUEX3>`__). In particular,
-   after you have debugged your code, disabling Asserts as follows helps
-   reduce the size of your code.
-
-::
-       var Defaults = xdc.useModule('xdc.runtime.Defaults');
-       var Diags = xdc.useModule('xdc.runtimg.Diags');
-       Defaults.common$.diags_ASSERT = Diags.ALWAYS_OFF;
-
--  The NotifyDriverCirc notification driver and the TransportShmNotify
-   or TransportShmCirc MessageQ transports described in **Optimizing IPC
-   Applications** use less code space than the default Notify driver and
-   MessageQ transport.
--  You can reduce code size by not using the HeapBufMP Heap
-   implementation. Since IPC uses the HeapMemMP implementation
-   internally, using HeapMemMP in your application does not increase the
-   code size. However, you should be aware that, depending on how your
-   application uses heaps, HeapMemMP may lead to problems with heap
-   fragmentation. See `Heap*MP
-   Modules <index_Foundational_Components.html#heapmp-module>`__ for more about
-   Heap implementations.
-
-|
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_Rebuilding_IPC.rst b/source/rtos/PDK_Platform_Software/IPC/_Rebuilding_IPC.rst
deleted file mode 100644
index affc507f3..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_Rebuilding_IPC.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/Rebuilding_IPC
-
-This page describes how to rebuild the IPC source code.
-
-The IPC product includes source files and build scripts that allow you to modify the IPC sources and rebuild its libraries. You can do this in order to modify, update, or add functionality. If you edit the IPC source code and/or corresponding build scripts, you must also rebuild IPC in order to create new libraries containing these modifications.
-
-Note that you can cause the BIOS-side IPC (and BIOS) libraries to be rebuilt as part of the application build - this is called a 'Custom Build'. The custom-built libraries will be stored with other output from executing your config script, and will contain only modules and APIs that your application needs to access. You can cause such a Custom Build to occur using the BIOS.libType config param as follows.
-
-.. code:: c
-
-   var BIOS = xdc.useModule('ti.sysbios.BIOS');
-   BIOS.libType = BIOS.LibType_Custom;
-
-.. note:: This page provides details about rebuilding the IPC source code. We strongly recommend that you copy the IPC installation to a directory with a different name and rebuild that copy, rather than rebuilding the original installation.
-
-Build Procedure
-------------------
-
-The IPC package now comes bundled with Processor SDK RTOS and can be rebuilt using the top-level makefile located in the Processor SDK RTOS folder. The following commands will build the BIOS-side IPC package.
-
-Windows
-::
-
-    cd (Processor SDK RTOS folder)
-    setupenv.bat
-    gmake ipc_bios
-
-Linux
-::
-
-    cd (Processor SDK RTOS folder)
-    source ./setupenv.sh
-    make ipc_bios
-
-The IPC package can also be cleaned using the following commands.
-
-Windows
-::
-
-    cd (Processor SDK RTOS folder)
-	setupenv.bat
-	gmake ipc_clean
-
-Linux
-::
-
-	cd (Processor SDK RTOS folder)
-	source ./setupenv.sh
-	make ipc_clean
-
-The install guides below have been kept here for those using older, legacy versions of IPC outside of Processor SDK.
-
-The various IPC Install Guides describe the mechanics of rebuilding IPC
-libraries. Please consult the Install Guide appropriate for your
-environment.
-
--  `IPC Install Guide BIOS <index_Foundational_Components.html#bios-install-guide>`__ - for
-   all-BIOS environments
--  `IPC Install Guide Linux <index_Foundational_Components.html#linux-install-guide>`__ -
-   for environments with a combination of Linux and BIOS
--  `IPC Install Guide QNX <index_Foundational_Components.html#qnx-install-guide>`__ - for
-   environments with a combination of QNX and BIOS
-
-Pointing a CCS Project at a Rebuilt IPC
-----------------------------------------
-
-To build your application using the version of IPC you have rebuilt, you
-must point your project to this rebuilt version by following these
-steps:
-
-#. Open CCS and select the application project you want to rebuild.
-#. Right-click on your project and choose **Build Properties**. If you
-   have a configuration project that is separate from your application
-   project, open the build properties for the configuration project.
-#. In the **CCS Build** category of the Properties dialog, choose the
-   **RTSC** tab.
-#. Under the **Products and Repositories** tab, uncheck *all* the boxes
-   for IPC. This ensures that no version is selected.
-
-   .. image:: /images/Rebuild_deselect.png
-
-#. Click the **Add** button next to the **Products and Repositories**
-   tab.
-#. Choose **Select repository from file-system**, and browse to the
-   "packages" directory of the location where you copied and rebuilt
-   IPC. For example, the location may be
-   C:\myIpcBuilds\custom_ipc_1_22_##-##\packages.
-
-   .. image:: /images/Rebuild_addrep.png
-
-#. Click **OK** to apply these changes to the project.
-#. You may now rebuild your project using the re-built version of IPC.
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_SharedRegion_Module.rst b/source/rtos/PDK_Platform_Software/IPC/_SharedRegion_Module.rst
deleted file mode 100644
index 43534df60..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_SharedRegion_Module.rst
+++ /dev/null
@@ -1,179 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/SharedRegion_Module
-
-.. |srmCfg_Img1| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-.. |srmCfg_Img2| Image:: /images/Book_cfg.png
-                 :target: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/indexChrome.html
-
-
-.. |srmRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_multi_proc_8h.html
-
-.. |srmRun_Img2| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_multi_proc_8h.html
-
-|
-
-   +---------------+---------------+
-   |     API Reference Links       |
-   +===============+===============+
-   | |srmCfg_Img1| | |srmRun_Img1| |
-   +---------------+---------------+
-
-The SharedRegion module is designed to be used in a multi-processor environment where there are memory regions that are shared and accessed across different processors.
-In an environment with shared memory regions, a common problem is that these shared regions are memory mapped to different address spaces on different processors. This is shown in the following figure. The shared memory region "DDR2" is mapped into Proc0's local memory space at base address 0x80000000 and Proc1's local memory space at base address 0x90000000. Therefore, the pointers in "DDR2" need to be translated in order for them to be portable between Proc0 and Proc1. The local memory regions for Proc0 and Proc1 are not shared thus they do not need to be added to the SharedRegion module.
-
-.. image:: /images/IpcUG_ipc_2_8_1.png
-
-On systems where address translation is not required, translation is a noop, so performance is not affected.
-
-The SharedRegion module itself does not use any shared memory, because all of its state is stored locally. The APIs use the system gate for thread protection.
-
-This module creates a shared memory region lookup table. The lookup table contains the processor's view of every shared region in the system. In cases where a processor cannot view a certain shared memory region, that shared memory region should be left invalid for that processor. Each processor has its own lookup table.
-
-Each processor's view of a particular shared memory region can be determined by the same region ID across all lookup tables. At runtime, this table, along with the shared region pointer, is used to do a quick address translation.
-
-The lookup table contains the following information about each shared region:
-
- - base. The base address of the region. This may be different on different processors, depending on their addressing schemes.
- - len. The length of the region. This should be should be the same across all processors.
- - ownerProcId. MultiProc ID of the processor that manages this region. If an owner is specified, the owner creates a HeapMemMP instance at runtime. The other cores open the same HeapMemMP instance.
- - isValid. Boolean to specify whether the region is valid (accessible) or not on this processor.
- - cacheEnable. Boolean to specify whether a cache is enabled for the region on the local processor.
- - cacheLineSize. The cache line size for the region. It is crucial that the value specified here be the same on all processors.
- - createHeap. Boolean to specify if a heap is created for the region.
- - name. The name associated with the region.
-
-The maximum number of entries in the lookup table is statically configurable using the SharedRegion.numEntries property. Entries can be added during static configuration or at runtime. When you add or remove an entry in one processor's table, you must update all of the remaining processors' tables to keep them consistent. The larger the maximum number of entries, the longer it will take to traverse the lookup table when searching for the index. Therefore, keep the lookup table small for better performance and footprint.
-
-Because each processor stores information about the caching of a shared memory region in the SharedRegion lookup table, other modules can (and do) make use of this caching information to maintain coherency and alignment when using items stored in shared memory.
-
-In order to use the SharedRegion module, the following must be true:
-
- - The SharedRegion.numEntries property must be the same on all processors.
- - The size of a SharedRegion pointer is 32-bits wide.
- - The SharedRegion lookup table must contain at least 1 entry for address translation to occur.
- - Shared memory regions must not overlap each other from a single processor's viewpoint.
- - Regions are not allowed to overlap from a single processor's view.
-
-The SharedRegion with an index of 0 (zero) is used by IPC_start() to create resource management tables for internal use by other IPC modules. Thus SharedRegion "0" must be accessible by all processors. Your applications can also make use of SharedRegion "0", but must be aware of memory limitations.
-
-
-Adding Table Entries Statically
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-  To create a shared region lookup table in the XDCtools configuration, first determine the shared memory regions you plan to use.
-
-Next, specify the maximum number of entries in the lookup table with the SharedRegion.numEntries property. You can specify a value for the SharedRegion.cacheLineSize configuration property, which is the default cache line size if no size is specified for a region. You can also specify the value of the SharedRegion.translate property, which should only be set to false if all shared memory regions have the same base address on all processors. Setting the translate property to false improves performance because no address translation is performed.
-
-For example:
-
-::
-
-  var SharedRegion = xdc.useModule('ti.sdo.ipc.SharedRegion');
-  SharedRegion.cacheLineSize = 32;
-  SharedRegion.numEntries = 4;
-  SharedRegion.translate = true;
-
-Then, use the SharedRegion.setEntryMeta() method in the configuration file to specify the parameters of the entry.
-
-::
-
-  var SHAREDMEM      = 0x0C000000;
-  var SHAREDMEMSIZE  = 0x00200000;
-
-  SharedRegion.setEntryMeta(0,
-      { base: SHAREDMEM,
-        len: SHAREDMEMSIZE,
-        ownerProcId: 0,
-        isValid: true,
-        cacheEnable: true,
-        cacheLineSize: 128,
-        createHeap: true,
-        name: "internal_shared_mem"
-  });
-
-If, during static configuration, you don't know the base address for every processor, you should set the "isValid" field for an entry for which you don't yet know the base address to "false". Storing this information will allow it to be completed at runtime.
-
-The following figure shows the configuration of a SharedRegion table for the system in the following figure. This system has seven processors and two shared memory regions. Region 0 ("ext") is accessible by all processors. Region 1 ("local") is accessible only by processors 1 to 6.
-
-.. image:: /images/IpcUG_ipc_2_8_2.png
-
-If the "createHeap" field is set to true, a HeapMemMP instance is created within the SharedRegion.
-
-|srmCfg_Img2| The latest version of the SharedRegion module configuration documentation is available
-`online <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/index.html#ti/sdo/ipc/SharedRegion.html>`__.
-
-Modifying Table Entries Dynamically
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In the application's C code, a shared memory region can be modified in the SharedRegion table by calling SharedRegion_setEntry().
-
-Typically, applications configure SharedRegion table entries statically as described in the previous section, and only modify the table entries dynamically in applications where it is possible for shared memory region availability to change dynamically.
-
-The call to SharedRegion_setEntry() must specify all the fields in the SharedRegion_Entry structure. The index specified must be the same across all processors for the same shared memory region. The index also must be smaller than the maxNumEntries property, otherwise an assert will be triggered.
-
-::
-
-  typedef struct SharedRegion_Entry {
-    Ptr base;
-    SizeT len;
-    UInt16 ownerProcId;
-    Bool isValid;
-    Bool cacheEnable;
-    SizeT cacheLineSize;
-    Bool createHeap;
-    String name;
-  } SharedRegion_Entry;
-
-You can use SharedRegion_getEntry() to fill the fields in a SharedRegion_Entry structure. Then, you can modify fields in the structure and call SharedRegion_setEntry() to write the modified fields back to the SharedRegion table.
-
-If you want to reuse an index location in the SharedRegion table, you can call SharedRegion_clear() on all processors to erase the existing entry at that index location.
-
-|srmRun_Img2| The latest version of the SharedRegion module run-time API documentation is available
-`online <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/_shared_region_8h.html>`__.
-
-Using Memory in a Shared Region
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Note that the SharedRegion with an index of 0 (zero) is used by IPC_start() to create resource management tables for internal use by the GateMP, NameServer, and Notify modules. Thus SharedRegion "0" must be accessible by all processors.
-
-This example allocates memory from a SharedRegion:
-
-::
-
-  buf = Memory_alloc(SharedRegion_getHeap(0), sizeof(Tester) * COUNT, 128, NULL);
-
-
-Getting Information About a Shared Region
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The shared region pointer (SRPtr) is a 32-bit portable pointer composed of an ID and offset. The most significant bits of a SRPtr are used for the ID. The ID corresponds to the index of the entry in the lookup table. The offset is the offset from the base of the shared memory region. The maximum number of table entries in the lookup table determines the number of bits to be used for the ID. An increase in the id means the range of the offset would decrease. The ID is limited to 16-bits.
-
-Here is sample code for getting the SRPtr and then getting the real address pointer back.
-
-SharedRegion_SRPtr srptr;
-UInt16 id;
-
-::
-
-  // Get the id of the address if id is not already known.
-  id = SharedRegion_getId(addr);
-
-  // Get the shared region pointer for the address
-  srptr = SharedRegion_getSRPtr(addr, id);
-
-  // Get the address back from the shared region pointer
-  addr = SharedRegion_getPtr(srptr);
-
-In addition, you can use the SharedRegion_getIdByName() function to pass the name of a SharedRegion and receive the ID number of the region.
-
-You can use SharedRegion_getHeap() to get a handle to the heap associated with a region using the heap ID.
-
-You can retrieve a specific shared region's cache configuration from the SharedRegion table by using SharedRegion_isCacheEnabled() and SharedRegion_getCacheLineSize().
-
-.. note::
-   In order to account for the case where the contents of the SharedRegion with an index of 0 cannot be known before the cores are booted, it is recommended to place the SharedRegion 0 owner procId in the MultiProc config array before all other cores that will be attaching to the owner of SharedRegion 0. In this way, it is guaranteed that the SharedRegion 0 owner is able to zero-init the memory before other cores start to access it during Ipc_attach. For example, if IPU1 is the SharedRegion 0 owner, the order would look like this in order to put IPU1 first in the array: ["IPU1","EVE1","DSP1"]
-
-.. note::
-   The SharedRegion Module is only supported in SYS/BIOS environments. It is not provided on HLOS's. For HLOS environments, we suggest using native shared memory APIs when available, for example ION on Android. Other alternatives include CMEM (for Linux) and the QNX-specific SharedMemoryAlloctor, provided in IPC's qnx/ directory.
-
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_The_ti.sdo.ipc_Package.rst b/source/rtos/PDK_Platform_Software/IPC/_The_ti.sdo.ipc_Package.rst
deleted file mode 100644
index 7eb4ea448..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_The_ti.sdo.ipc_Package.rst
+++ /dev/null
@@ -1,267 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/The_ti.sdo.ipc_Package
-
-.. |ipcSdoRun_Img1| Image:: /images/Book_run.png
-                 :target: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/files.html
-
-Introduction
------------------
-This page introduces the modules in the ti.sdo.ipc package.
-
-.. note::
-  This package is not used on HLOS-based cores. Although this is a BIOS-only package,
-  note that the BIOS-side of a HLOS<->BIOS IPC-using application will need to bring in a subset of these packages into the BIOS-side configuration scripts.
-
-The ``ti.sdo.ipc`` package contains the following modules that you may use in your applications:
-
-   +----------------------------+------------------------------------+----------------------------------+
-   |         Module             |      Module Path                   |         Description              |
-   +============================+====================================+==================================+
-   |`GateMP Module <index_      | GateMP                             | Manages gates for mutual         |
-   |Foundational_Compon         |                                    | exclusion of shared resources    |
-   |ents.html#gatemp-           |                                    | by multiple processors and       |
-   |module>`__                  |                                    | threads.                         |
-   |                            |                                    | See `GateMP Module <index_       |
-   |                            |                                    | Foundational_Compon              |
-   |                            |                                    | ents.html#gatemp-                |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`HeapBufMP Module <index_   | ti.sdo.ipc.heaps.HeapBufMP         | Fixed-sized shared memory        |
-   |Foundational_               |                                    | Heaps. Similar to SYS/BIOS's     |
-   |Components.html#heapmp-     |                                    | ti.sysbios.heaps.HeapBuf         |
-   |module>`__                  |                                    | module, but with some            |
-   |                            |                                    | configuration differences.       |
-   |                            |                                    | See `HeapMP Module <index_       |
-   |                            |                                    | Foundational_                    |
-   |                            |                                    | Components.html#heapmp-          |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`HeapMemMP Module <index_   | ti.sdo.ipc.heaps.HeapMemMP         | Variable-sized shared memory     |
-   |Foundational_               |                                    | Heaps.                           |
-   |Components.html#heapmp-     |                                    | See `HeapMP Module <index_       |
-   |module>`__                  |                                    | Foundational_                    |
-   |                            |                                    | Components.html#heapmp-          |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`HeapMultiBufMP Module      | ti.sdo.ipc.heaps.HeapMultiBufMP    | Multiple fixed-sized shared      |
-   |<index_Foundational_        |                                    | memory Heaps.                    |
-   |Components.html#heapmp-     |                                    | See `HeapMP Module <index_       |
-   |module>`__                  |                                    | Foundational_                    |
-   |                            |                                    | Components.html#heapmp-          |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`Ipc Module <index_         | ti.sdo.ipc.Ipc                     | Provides Ipc_start() function    |
-   |Foundational_               |                                    | and allows startup sequence      |
-   |Components.html#ipc-        |                                    | configuration.                   |
-   |module>`__                  |                                    | See `IPC Module <index_          |
-   |                            |                                    | Foundational_                    |
-   |                            |                                    | Components.html#ipc-             |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`ListMP Module <index_      | ti.sdo.ipc.ListMP                  | Doubly-linked list for           |
-   |Foundational_               |                                    | shared-memory, multi-processor   |
-   |Components.html#listmp-     |                                    | applications. Very similar to    |
-   |module>`__                  |                                    | the ti.sdo.utils.List module.    |
-   |                            |                                    | See `ListMP Module <index_       |
-   |                            |                                    | Foundational_                    |
-   |                            |                                    | Components.html#listmp-          |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`MessageQ Module <index_    | ti.sdo.ipc.MessageQ                | Variable size messaging          |
-   |Foundational_               |                                    | module.                          |
-   |Components.html#messageq-   |                                    | See `MessageQ Module <index_     |
-   |module>`__                  |                                    | Foundational_                    |
-   |                            |                                    | Components.html#messageq-        |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   | TransportShm               | ti.sdo.ipc.transports.TransportShm | Transport used by MessageQ       |
-   |                            |                                    | for remote communication with    |
-   |                            |                                    | other processors via shared      |
-   |                            |                                    | memory.                          |
-   |                            |                                    | See `MessageQ Module <index_     |
-   |                            |                                    | Foundational_                    |
-   |                            |                                    | Components.html#messageq-        |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`Notify Module <index_      | ti.sdo.ipc.Notify                  | Low-level interrupt              |
-   |Foundational_               |                                    | mux/demuxer module.              |
-   |Components.html#notify-     |                                    | See `Notify Module <index_       |
-   |module>`__                  |                                    | Foundational_                    |
-   |                            |                                    | Components.html#notify-          |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   | NotifyDriverShm            | ti.sdo.ipc.notifyDrivers.          | Shared memory notification       |
-   |                            | NotifyDriverShm                    | driver used by the Notify        |
-   |                            |                                    | module to communicate between    |
-   |                            |                                    | a pair of processors.            |
-   |                            |                                    | See `Notify Module <index_       |
-   |                            |                                    | Foundational_                    |
-   |                            |                                    | Components.html#notify-          |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-   |`SharedRegion Module <index_| ti.sdo.ipc.SharedRegion            | Maintains shared memory for      |
-   |Foundational_               |                                    | multiple shared regions.         |
-   |Components.html#shared-     |                                    | See `SharedRegion Module <index_ |
-   |region-module>`__           |                                    | Foundational_                    |
-   |                            |                                    | Components.html#shared-region-   |
-   |                            |                                    | module>`__                       |
-   +----------------------------+------------------------------------+----------------------------------+
-
-Additional modules in the subfolders of the ti.sdo.ipc package contain specific implementations of gates,
-heaps, notify drivers, transports, and various device family-specific modules.
-
-In addition, the ti.sdo.ipc package defines the following interfaces that you may implement as your own custom modules:
-
-   +----------------------------+------------------------------------------+
-   |         Module             |      Module Path                         |
-   +============================+==========================================+
-   |IGateMPSupport              | ti.sdo.ipc.interfaces.IGateMPSupport     |
-   +----------------------------+------------------------------------------+
-   |IInterrupt                  | ti.sdo.ipc.notifyDrivers.IInterrupt      |
-   +----------------------------+------------------------------------------+
-   |IMessageQTransport          | ti.sdo.ipc.interfaces.IMessageQTransport |
-   +----------------------------+------------------------------------------+
-   |INotifyDriver               | ti.sdo.ipc.interfaces.INotifyDriver      |
-   +----------------------------+------------------------------------------+
-   |INotifySetup                | ti.sdo.ipc.interfaces.INotifySetup       |
-   +----------------------------+------------------------------------------+
-
-The ``<ipc_install_dir>/packages/ti/sdo/ipc`` directory contains the following packages that you may need to know about:
-
- - **examples.** Contains examples.
- - **family.** Contains device-specific support modules (used internally).
- - **gates.** Contains GateMP implementations (used internally).
- - **heaps.** Contains multiprocessor heaps.
- - **interfaces.** Contains interfaces.
- - **notifyDrivers.** Contains NotifyDriver implementations (used internally).
- - **transports.** Contains MessageQ transport implementations that are used internally.
-
-Including Header Files
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-BIOS applications that use modules in the ti.sdo.ipc or ti.sdo.utils
-package should include the common header files provided in
-``<ipc_install_dir>/packages/ti/ipc/``. These header files offer a
-common API for both SYS/BIOS and HLOS users of IPC.
-
-The following example C code includes header files applications may need
-to use. Depending on the APIs used in your application code, you may
-need to include different XDC, IPC, and SYS/BIOS header files.
-
-::
-
-    #include <xdc/std.h>
-    #include <string.h>
-     
-    /* ---- XDC.RUNTIME module Headers   */
-    #include <xdc/runtime/Memory.h>
-    #include <xdc/runtime/System.h>
-    #include <xdc/runtime/IHeap.h>
-     
-    /* ----- IPC module Headers          */
-    #include <ti/ipc/GateMP.h>
-    #include <ti/ipc/Ipc.h>
-    #include <ti/ipc/MessageQ.h>
-    #include <ti/ipc/HeapBufMP.h>
-    #include <ti/ipc/MultiProc.h>
-     
-    /* ---- BIOS6 module Headers         */
-    #include <ti/sysbios/BIOS.h>
-    #include <ti/sysbios/knl/Task.h>
-     
-    /* ---- Get globals from .cfg Header */
-    #include <xdc/cfg/global.h>
-
-Note that the appropriate include file location has changed from
-previous versions of IPC. The XDCtools-generated header files are still
-available in ``<ipc_install_dir>/packages/ti/sdo/ipc/``, but these
-should not directly be included in runtime .c code.
-You should search your applications for "ti/sdo/ipc" and "ti/sdo/utils"
-and change the header file references found as needed. Additional
-changes to API calls will be needed.
-
-|ipcSdoRun_Img1| Documentation for all common-header APIs is provided in Doxygen format
-in your IPC installation at
-``<ipc_install_dir>/docs/doxygen/html/index.html``. The latest version
-of that documentation is available
-`online <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/doxygen/html/files.html>`__.
-
-
-Standard IPC Function Call Sequence
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For instance-based modules in IPC, the standard IPC methodology when
-creating object dynamically (that is, in C code) is to have the creator
-thread first initialize a *MODULE*\ \_Params structure to its default
-values via a *MODULE*\ \_Params_init() function. The creator thread can
-then set individual parameter fields in this structure as needed. After
-setting up the *MODULE*\ \_Params structure, the creator thread calls
-the *MODULE*\ \_create() function to creates the instance and
-initializes any shared memory used by the instance. If the instance is
-to be opened remotely, a unique name must be supplied in the parameters.
-
-Other threads can access this instance via the *MODULE\_*\ open()
-function, which returns a handle with access to the instance. The name
-that was used for instance creation must be used in the
-*MODULE*\ \_open() function.
-
-In most cases, MODULE_open() functions must be called in the context of
-a Task. This is because the thread running the MODULE_open() function
-needs to be able to block (to pend on a Semaphore in this case) while
-waiting for the remote processor to respond. The response from the
-remote processor triggers a hardware interrupt, which then posts a
-Semaphore to allow to Task to resume execution. The exception to this
-rule is that MODULE_open() functions do not need to be able to block
-when opening an instance on the local processor.
-
-When the threads have finished using an instance, all threads that
-called *MODULE\_*\ open() must call *MODULE*\ \_close(). Then, the
-thread that called *MODULE*\ \_create() can call *MODULE*\ \_delete() to
-free the memory used by the instance.
-
-Note that *all* threads that opened an instance must close that instance
-before the thread that created it can delete it. Also, a thread that
-calls *MODULE*\ \_create() cannot call *MODULE*\ \_close(). Likewise, a
-thread that calls *MODULE\_*\ open() cannot call *MODULE*\ \_delete().
-
-Error Handling in IPC
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Many of the APIs provided by IPC return an integer as a status code.
-Your application can test the status value returned against any of the
-provided status constants. For example:
-
-::
-
-    MessageQ_Msg     msg;
-    MessageQ_Handle  messageQ;
-    Int              status;
-     
-    ...
-    status = MessageQ_get(messageQ, &msg, MessageQ_FOREVER);
-        if (status < 0) {
-            System_abort("Should not happen\n");
-        }
-
-Status constants have the following format: ``MODULE_[S|E]_CONDITION``.
-For example, Ipc_S_SUCCESS, MessageQ_E_FAIL, and SharedRegion_E_MEMORY
-are status codes that may be returned by functions in the corresponding
-modules.
-Success codes always have values greater or equal to zero. For example,
-Ipc_S_SUCCESS=0 and Ipc_S_ALREADYSETUP=1; both are success codes.
-Failure codes always have values less than zero. Therefore, the presence
-of an error can be detected by simply checking whether the return value
-is negative.
-
-Other APIs provided by IPC return a handle to a created object. If the
-handle is NULL, an error occurred when creating the object. For example:
-
-::
-
-    messageQ = MessageQ_create(DSP_MESSAGEQNAME, NULL);
-    if (messageQ == NULL) {
-        System_abort("MessageQ_create failed\n");
-    }
-
-Refer to the Doxygen documentation for status codes returned by IPC
-functions.
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_The_ti.sdo.utils_Package.rst b/source/rtos/PDK_Platform_Software/IPC/_The_ti.sdo.utils_Package.rst
deleted file mode 100644
index 4dd8d97e0..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_The_ti.sdo.utils_Package.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/The_ti.sdo.utils_Package
-
-This page introduces the modules in the ti.sdo.utils package.
-
-The ti.sdo.utils package contains modules that are used as utilities by other modules in the IPC product.
-
-- List. This module provides a doubly-linked list manager for use by other modules. See List Module.
-- MultiProc. This module stores processor IDs in a centralized location for multi-processor applications. See MultiProc Module.
-- NameServer. This module manages name/value pairs for use by other modules. See NameServer Module.
-
diff --git a/source/rtos/PDK_Platform_Software/IPC/_Use_Cases_for_IPC.rst b/source/rtos/PDK_Platform_Software/IPC/_Use_Cases_for_IPC.rst
deleted file mode 100644
index ee70a3d22..000000000
--- a/source/rtos/PDK_Platform_Software/IPC/_Use_Cases_for_IPC.rst
+++ /dev/null
@@ -1,151 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/IPC_Users_Guide/Use_Cases_for_IPC
-
-You can use IPC modules in a variety of combinations. From the simplest
-setup to the setup with the most functionality, the use case options are
-as follows. A number of variations of these cases are also possible:
-
--  **Minimal use of IPC. (BIOS-to-BIOS only)** This scenario performs
-   inter-processor notification. The amount of data passed with a
-   notification is minimal--typically on the order of 32 bits. This
-   scenario is best used for simple synchronization between processors
-   without the overhead and complexity of message-passing
-   infrastructure.
--  **Add data passing. (BIOS-to-BIOS only)** This scenario adds the
-   ability to pass linked list elements between processors to the
-   previous minimal scenario. The linked list implementation may
-   optionally use shared memory and/or gates to manage synchronization.
--  **Add dynamic allocation. (BIOS-to-BIOS only)** This scenario adds
-   the ability to dynamically allocate linked list elements from a heap.
--  **Powerful but easy-to-use messaging. (HLOS and BIOS)** This scenario
-   uses the MessageQ module for messaging. The application configures
-   other modules. However, the APIs for other modules are then used
-   internally by MessageQ, rather than directly by the application.
-
-In the following sections, figures show modules used by each scenario.
-
-.. role:: raw-html(raw)
-   :format: html
-
-- :raw-html:`<font color="blue">Blue boxes,</font>` identify modules for which your application will call C API functions other than those used to dynamically create objects.
-- :raw-html:`<font color="red">Red boxes,</font>` identify modules that require only configuration by your application. Static configuration is performed in an XDCtools configuration script (.cfg). Dynamic configuration is performed in C code.
-- :raw-html:`<font color="grey">Grey boxes,</font>` identify modules that are used internally but do not need to be configured or have their APIs called.
-
-
-Minimal Use Scenario (BIOS-to-BIOS only)
------------------------------------------
-
-This scenario performs inter-processor notification using a Notify
-driver, which is used by the Notify module. This scenario is best used
-for simple synchronization in which you want to send a message to
-another processor to tell it to perform some action and optionally have
-it notify the first processor when it is finished.
-
-.. Image:: /images/IpcUG_over_1_2_1.png
-
-In this scenario, you make API calls to the Notify module. For example,
-the Notify_sendEvent() function sends an event to the specified
-processor. You can dynamically register callback functions with the
-Notify module to handle such events.
-
-You must statically configure MultiProc module properties, which are
-used by the Notify module.
-
-The amount of data passed with a notification is minimal. You can send
-an event number, which is typically used by the callback function to
-determine what action it needs to perform. Optionally, a small
-"payload"? of data can also be sent.
-
-See `Notify Module <index_Foundational_Components.html#notify-module>`__ and
-`MultiProc Module <index_Foundational_Components.html#multiproc-module>`__.
-
-
-Data Passing Scenario (BIOS-to-BIOS only)
---------------------------------------------
-
-In addition to the IPC modules used in the previous scenario, you can
-use the ListMP module to share a linked list between processors.
-
-.. Image:: /images/IpcUG_over_1_2_2.png
-
-In this scenario, you make API calls to the Notify and ListMP modules.
-
-The ListMP module is a doubly-linked-list designed to be shared by
-multiple processors. ListMP differs from a conventional "local"? linked
-list in the following ways:
-
--  Address translation is performed internally upon pointers contained
-   within the data structure.
--  Cache coherency is maintained when the cacheable shared memory is
-   used.
--  A multi-processor gate (GateMP) is used to protect read/write
-   accesses to the list by two or more processors.
-
-ListMP uses SharedRegion's lookup table to manage access to shared
-memory, so configuration of the SharedRegion module is required.
-
-Internally, ListMP can optionally use the NameServer module to manage
-name/value pairs. The ListMP module also uses a GateMP object, which
-your application must configure. The GateMP is used internally to
-synchronize access to the list elements.
-
-See `ListMP Module <index_Foundational_Components.html#listmp-module>`__,
-`GateMP Module <index_Foundational_Components.html#gatemp-module>`__,
-`SharedRegion
-Module <index_Foundational_Components.html#shared-region-module>`__, and
-`NameServer Module <index_Foundational_Components.html#nameserver-module>`__.
-
-
-Dynamic Allocation Scenario (BIOS-to-BIOS only)
--------------------------------------------------
-
-To the previous scenario, you can add dynamic allocation of ListMP
-elements using one of the Heap*MP modules.
-
-.. Image:: /images/IpcUG_over_1_2_3.png
-
-In this scenario, you make API calls to the Notify and ListMP modules
-and a Heap*MP module.
-
-In addition to the modules that you configured for the previous
-scenario, the Heap*MP modules use a GateMP that you must configure. You
-may use the same GateMP instance used by ListMP.
-
-See `Heap*MP Modules <index_Foundational_Components.html#heapmp-module>`__ and
-`GateMP Module <index_Foundational_Components.html#gatemp-module>`__.
-
-
-Powerful But Easy-to-Use Messaging with MessageQ (HLOS and BIOS)
------------------------------------------------------------------
-
-Finally, to use the most sophisticated inter-processor communication
-scenario supported by IPC, you can add the MessageQ module. Note that
-the following diagram shows one particular transport (TransportShm) and
-may not apply to all devices and/or environments.
-
-.. Image:: /images/IpcUG_over_1_2_4.png
-
-In this scenario, you make API calls to the MessageQ module for
-inter-processor communication.
-
-API calls made to the Notify, ListMP, and Heap*MP modules in the
-previous scenarios are not needed. Instead, your application only needs
-to configure the MultiProc and (if the underlying MessageQ transport
-requires it) the SharedRegion modules.
-
-.. note::
-
-  Some MessageQ transports do not use SharedRegion, but instead copy the
-  message payloads. This may be done because of hardware limitations (e.g.
-  no shared memory is available) or software design (e.g. transports built
-  on Linux kernel-friendly rpmsg drivers).
-
-
-The ``Ipc_start()`` API call configures all the necessary underlying
-modules (e.g. Notify, HeapMemMP, ListMP, TransportShm, NameServer, and
-GateMP). The actual details of what modules ``Ipc_start()`` initializes
-varies from environment to environment.
-
-It is possible to use MessageQ in a single-processor SYS/BIOS
-application. In such a case, only API calls to MessageQ and
-configuration of any xdc.runtime.IHeap implementation are needed.
-
diff --git a/source/rtos/PDK_Platform_Software/Network_and_Transport/_CCLink.rst b/source/rtos/PDK_Platform_Software/Network_and_Transport/_CCLink.rst
deleted file mode 100644
index dd7a87be7..000000000
--- a/source/rtos/PDK_Platform_Software/Network_and_Transport/_CCLink.rst
+++ /dev/null
@@ -1,212 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_CCLINK
-
-Introduction
--------------
-
-CC-Link is an open-architecture network that was originally developed
-by the Mitsubishi Electric Corporation.It have been widely used in
-Process control, building automation etc. CLPA (CC-Link Partner
-Association) maintains the network technology and support many
-manufacturer supporting the application. CC-Link is available in
-multiple flavours i.e. CC-Link, CC-Link LT, CC-Link Safety, CC-Link IE
-(Industrial Ethernet) - Control and CC-Link IE Field. For further
-details regarding CCLink and its flavours please refer the CLPA
-website.\ `[1] <http://am.cc-link.org/en/index.html>`__
-
-Protocol Overview
-------------------
-
-The implementation will demonstrate how to create, run and test CC-Link
-IE Field Network Basic examples on TI platforms. The following shows the
-CC-Link IE Field Network Basic Overview:
-
--  1 Gbit/s Ethernet based network
--  Ethernet physical layer (Cat5e cable & RJ45 connectors)
--  254 stations per network
--  100 meters between stations
--  Completely deterministic without using switches
-|
-Code Organization
-------------------
-
-The Directory structure for CC-Link IE Field Network Basic source code
-and examples for both NIMU and NIMU_ICSS is shown in the following
-table.
-
-+---------------------------------------------------------------------------------------------------------------------------+
-|                                            **CCLink for CPSW i.e. NIMU**                                                  |
-+-----------------------------------+---------------------------------------------------------------------------------------+
-+**Controller Station Source code** | $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu/example/CCLink/cclink_controller |
-+-----------------------------------+---------------------------------------------------------------------------------------+
-+**SLave Station Source code**      |$(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu/example/CCLink/cclink_device      |
-+-----------------------------------+---------------------------------------------------------------------------------------+
-+**Test Examples script**           |$(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu/example/CCLink/<SOC>              |
-+-----------------------------------+---------------------------------------------------------------------------------------+
-+**Test Examples main code**        |$(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu/example/CCLink/src                |
-+-----------------------------------+---------------------------------------------------------------------------------------+
-
-
-+--------------------------------------------------------------------------------------------------------------------------------+
-|                                            **CCLink for ICSS i.e. NIMU_ICSS**                                                  |
-+-----------------------------------+--------------------------------------------------------------------------------------------+
-+**Controller Station Source code** | $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss/example/CCLink/cclink_controller |
-+-----------------------------------+--------------------------------------------------------------------------------------------+
-+**Device Station Source code**     |$(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss/example/CCLink/cclink_device      |
-+-----------------------------------+--------------------------------------------------------------------------------------------+
-+**Test Examples script**           |$(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss/example/CCLink/<SOC>              |
-+-----------------------------------+--------------------------------------------------------------------------------------------+
-+**Test Examples main code**        |$(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss/example/CCLink/src                |
-+-----------------------------------+--------------------------------------------------------------------------------------------+
-
-|
-
-Building the Examples
-----------------------
-
-Use pdkProjectCreate.sh for Linux environment or pdkProjectCreate.bat
-for Windows.
-This can be found under the <PDK>/packages folder. The only
-modification to these scripts, if any, is to update the
-CCS_INSTALL_PATH variable to point to CCS location if its not in the
-c:\ti\ccsv6 directory . Please refer to `Rebuilding
-PDK <index_how_to_guides.html#rebuild-drivers-from-pdk-directory>`__ for details of example project
-creation and how to run the example projects using CCS.
-
-CC-Link IE Field Network Basic Example Description
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For each EVM Type supported, there is a cclink example which demonstates
-cyclic data communication between controller and device station. Once the
-application is loaded via CCS and run, you will be able to see controller
-sending cyclic data packets and device receiving the packet. For example,
-the config file for NIMU for CPSW for idkAM572x, can be found in
-ti/transport/ndk/nimu/example/CCLink/am572x/armv7/bios/cclink_idkAM572x.cfg.
-The default IP address for controller is 192.168.3.100 and for device it is
-192.168.3.4. If you wish to re-configure the IP address of the CPSW
-interface you will need to modify the following configuration
-parameters. make sure controller and device are in same network.
-
--  Ip.address = "new ip address"
--  Ip.mask = "new ip mask"
--  Ip.gatewayIpAddr = "new gatewayIpAddr"
-
-If you do change these settings, you will be required to re-build the
-Example Project using CCS.
-
-+-----------------------+-----------------------+-----------------------+
-| Name                  | Description           | EVM Configuration     |
-+=======================+=======================+=======================+
-| NIMU_CCLinkController | | Example             | | icev2AM335x:        |
-| _<evm/idk>XXXX_<arm/  |   demonstrates CCLink |   Jumpers J18 and J19 |
-| c66x/m4>Exampleprojec |   controller station  |   need to be set      |
-| t.txt                 |   sending cyclic      |   properly to select  |
-|                       |   packet to device.   |   CPSW or ICSS mode.  |
-|                       |                       |                       |
-|                       |                       | | Pin2 and Pin3 need  |
-|                       |                       |   to be connected for |
-|                       |                       |   ICSS mode and Pin1  |
-|                       |                       |   and Pin2 for CPSW   |
-|                       |                       |   mode.               |
-|                       |                       |                       |
-|                       |                       | Update \*.cfg file    |
-|                       |                       | with static IP to     |
-|                       |                       | test. NIMU for CPSW   |
-|                       |                       | test Tests requires   |
-|                       |                       | connection of         |
-|                       |                       | configured Ethernet   |
-|                       |                       | port under test to    |
-|                       |                       | external PC on same   |
-|                       |                       | subnet.               |
-+-----------------------+-----------------------+-----------------------+
-| NIMU_CCLinkDevice_<ev | | Example             | | icev2AM335x:        |
-| m/idk>XXXX_<arm/c66x/ |   demonstrates CCLink |   Jumpers J18 and J19 |
-| m4>Exampleproject.txt |   device station      |   need to be set      |
-|                       |   receiving cyclic    |   properly to select  |
-|                       |   packet from         |   CPSW or ICSS mode.  |
-|                       |   controller and      |                       |
-|                       |   sending a response  | | Pin2 and Pin3 need  |
-|                       |   back.               |   to be connected for |
-|                       |                       |   ICSS mode and Pin1  |
-|                       |                       |   and Pin2 for CPSW   |
-|                       |                       |   mode.               |
-|                       |                       |                       |
-|                       |                       | Update \*.cfg file    |
-|                       |                       | with static IP to     |
-|                       |                       | test. NIMU for CPSW   |
-|                       |                       | test Tests requires   |
-|                       |                       | connection of         |
-|                       |                       | configured PRU-ICSS   |
-|                       |                       | Ethernet port under   |
-|                       |                       | test to external PC   |
-|                       |                       | on same subnet.       |
-+-----------------------+-----------------------+-----------------------+
-| NIMU_ICSS_CCLinkMaste | | Example             | | icev2AM335x:        |
-| r_<evm/idk>XXXX_<arm/ |   demonstrates CCLink |   Jumpers J18 and J19 |
-| c66x/m4>Exampleprojec |   controller station  |   need to be set      |
-| t.txt                 |   sending cyclic      |   properly to select  |
-|                       |   packet to device.   |   CPSW or ICSS mode.  |
-|                       |                       |                       |
-|                       |                       | | Pin2 and Pin3 need  |
-|                       |                       |   to be connected for |
-|                       |                       |   ICSS mode and Pin1  |
-|                       |                       |   and Pin2 for CPSW   |
-|                       |                       |   mode.               |
-|                       |                       |                       |
-|                       |                       | Update \*.cfg file    |
-|                       |                       | with static IP to     |
-|                       |                       | test. NIMU for CPSW   |
-|                       |                       | test Tests requires   |
-|                       |                       | connection of         |
-|                       |                       | configured Ethernet   |
-|                       |                       | port under test to    |
-|                       |                       | external PC on same   |
-|                       |                       | subnet.               |
-+-----------------------+-----------------------+-----------------------+
-| NIMU_ICSS_CCLinkDevic | | Example             | | icev2AM335x:        |
-| e_<evm/idk>XXXX_<arm/ |   demonstrates CCLink |   Jumpers J18 and J19 |
-| c66x/m4>Exampleprojec |   device station      |   need to be set      |
-| t.txt                 |   receiving cyclic    |   properly to select  |
-|                       |   packet from         |   CPSW or ICSS mode.  |
-|                       |   controller and      |                       |
-|                       |   sending a response  | | Pin2 and Pin3 need  |
-|                       |   back.               |   to be connected for |
-|                       |                       |   ICSS mode and Pin1  |
-|                       |                       |   and Pin2 for CPSW   |
-|                       |                       |   mode.               |
-|                       |                       |                       |
-|                       |                       | Update \*.cfg file    |
-|                       |                       | with static IP to     |
-|                       |                       | test. NIMU for CPSW   |
-|                       |                       | test Tests requires   |
-|                       |                       | connection of         |
-|                       |                       | configured PRU-ICSS   |
-|                       |                       | Ethernet port under   |
-|                       |                       | test to external PC   |
-|                       |                       | on same subnet.       |
-+-----------------------+-----------------------+-----------------------+
-
-|
-
-Running CC-Link IE Field Network Basic example
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The following is the test setup needed to run the example for CCLink
-demonstration on TI platform. Connect the tested eth port of the evm to
-a switch for controller station. Do the same connection for device station to
-same switch.
-
-.. Image:: /images/Cclink_setup_pic.PNG
-
-|
-| Once the connection is done, load controller and device station code on
-  both evm and run them simultaneously. You would see following output
-  on uart port of controller station.
-
-.. Image:: /images/Cclink_master_screeshot_linux.png
-
-You would see following output on uart port of device station.
-
-.. Image:: /images/Cclink_slave_screenshot_linux.png
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/Network_and_Transport/_NDK.rst b/source/rtos/PDK_Platform_Software/Network_and_Transport/_NDK.rst
deleted file mode 100644
index a5fe319e5..000000000
--- a/source/rtos/PDK_Platform_Software/Network_and_Transport/_NDK.rst
+++ /dev/null
@@ -1,549 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_NDK
-
-NDK Overview
---------------
-
-The Network Development Kit (NDK) is a platform for development and
-demonstration of network enabled RTOS applications on TI processors and
-includes demonstration software showcasing capabilities across a range
-of network enabled applications. The NDK serves as a rapid prototype
-platform for the development of network and packet processing
-applications, or to add network connectivity to existing applications
-for communications, configuration, and control. Using the components
-provided in the NDK, developers can quickly move from development
-concepts to working implementations attached to the network.
-
-The NDK provides an IPv6 and IPv4 compliant TCP/IP stack working with
-the TI-RTOS Kernel real-time operating system. Its primary focus is on
-providing the core Layer 3 and Layer 4 stack services along with
-additional higher-level network applications such as HTTP server and
-DHCP.
-
-The NDK itself does not include any platform or device specific
-software. The NDK interfaces through well-defined transport interface,
-Network Interface Management UNIT(NIMU) to the PDK and platform
-software elements needed for operation. NIMU support. NIMU provides an
-interface between the stack and the device drivers through which the
-stack can talk to multiple instances of a single or various device
-drivers concurrently.
-
-+-------------------------------------------------------------------------------------------------------+
-|                                   **Network Development Kit Summary**                                 |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Component Type**             | Library                                                               |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Install Package**            |  NDK                                                                  |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Install Directory**          | ndk_<version>\packages\ti\ndk                                         |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Project Type**               |`Eclipse RTSC <http://www.eclipse.org/rtsc/>`__                        |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Endian Support**             | Little                                                                |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Library Name**               | For details of the libraries delivered as part of the NDK component,  |
-|                               | please refer to `[1] <http://www-s.ti.com/sc/techlit/spru523.pdf>`__  |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Library Path**               | $(NDK_INSTALL_DIR)\packages\ti\ndk                                    |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Include Paths**              | NDK_INSTALL_DIR is set automatically by CCS based on the version of   |
-|                               | NDK you have checked to build with.                                   |
-|                               | ${NDK_INSTALL_DIR}\packages\ti\ndk\inc                                |
-|                               | ${NDK_INSTALL_DIR}\packages\ti\ndk\inc\tools                          |
-+-------------------------------+-----------------------------------------------------------------------+
-
-|
-
-NIMU Transport
----------------
-
-The NDK transport component of the PDK currently provided 2
-implementations for the NIMU layer as described in the sections below.
-The following diagram is a high level depiction of the NDK/NIMU
-architecture with reference to the NIMU implementations. For details
-for the NDK/NIMU architecture, please refer to NDK Programmer's
-Reference Guide `[2] <http://www-s.ti.com/sc/techlit/spru524.pdf>`__
-
-.. Image:: /images/NDK_ARCH.png
-
-NIMU for CPSW
--------------
-
-NIMU for CPSW provides a common CPSW interface library for NDK to
-communicate with when network stack is being implemented in the TI's
-Common Platform Ethernet Switch for ethernet packet processing. The
-library uses the CSL-R based API interfaces to provide NIMU interface
-for NDK. This package has NDK unit test examples for all supported EVMS
-as indicated in the table above.
-
-.. note::
-
-  This module is only intended to be used with NDK. As such,
-  users should not tie up to its API directly.
-
-
-+-------------------------------------------------------------------------------------------------------+
-|                                       **NIMU for CPSW Summary**                                       |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Component Type**             | Library                                                               |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Install Package**            | PDK                                                                   |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Install Directory**          | $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu                  |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Project Type**               |`Eclipse RTSC <http://www.eclipse.org/rtsc/>`__                        |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Endian Support**             | Little                                                                |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Library Path**               | $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu/lib              |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Reference Guides**           | None                                                                  |
-+-------------------------------+-----------------------------------------------------------------------+
-
-|
-
-NIMU for ICSS
--------------
-
-NIMU for ICSS (PRU-ICSS is Programmable Real-Time Unit Industrial
-Communications Subsystem) provides a common PRU-ICSS interface library
-for NDK to communicate with when network stack is being implemented in
-the PRU-ICSS subsytem for ethernet packet processing (firmware based
-switch running on PRU's which are part of the ICSS). The library used
-the ICSS_EMAC LLD to provide NIMU interface for NDK. This package has
-NDK unit test examples for all supported Devices as indicated in the
-table above. For details of the PRU-ICSS, please refer to
-`ICCS-EMAC </index.php/Processor_SDK_RTOS_ICSS-EMAC>`__.
-
-| **Note**: This module is only intended to be used with NDK and
-  requires ICSS-EMAC low level driver. As such, users should not tie up
-  to its API directly.
-
-
-+-------------------------------------------------------------------------------------------------------+
-|                                       **NIMU for ICSS Summary**                                       |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Component Type**             | Library                                                               |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Install Package**            | PDK                                                                   |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Install Directory**          | $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss             |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Project Type**               |`Eclipse RTSC <http://www.eclipse.org/rtsc/>`__                        |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Endian Support**             | Little                                                                |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Library Path**               | $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss/lib         |
-+-------------------------------+-----------------------------------------------------------------------+
-|**Reference Guides**           | None                                                                  |
-+-------------------------------+-----------------------------------------------------------------------+
-
-|
-
-Examples
----------
-
-PING Example
-^^^^^^^^^^^^^
-
-All NDK examples using CPSW interface can be found at the following
-location:
-
--  $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu/example
-
-All NDK examples using PRU-ICSS interface can be found at the following
-location:
-
--  $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss/example
-
-Building the NDK examples
-"""""""""""""""""""""""""""
-
-| Use pdkProjectCreate.sh for Linux environment or pdkProjectCreate.bat
-  for Windows.
-| This can be found under the <PDK>/packages folder. The only
-  modification to these scripts, if any, is to update the
-  CCS_INSTALL_PATH variable to point to CCS location if its not in the
-  c:/ti/ccsv6 directory . Please refer to `Rebuilding
-  PDK <index_how_to_guides.html#rebuild-drivers-from-pdk-directory>`__ for details of example project
-  creation and how to run the example projects using CCS.
-
-NDK Example Description
-""""""""""""""""""""""""
-
-For each EVM Type supported, there is a example which demonstates "ping"
-use case. Once the application is loaded via CCS and run, you will be
-able to ping the configured IP address as specificed int he examples
-config file. For example, the config file for NIMU for CPSW for
-idkAM572x, can be found in
-ti/transport/ndk/nimu/example/am572x/armv7/bios/nimu_idk.cfg. If you
-wish to re-configure the IP address of the CPSW interface you will need
-to modify the following configuration parameters
-
--  Ip.address = "new ip address"
--  Ip.mask = "new ip mask"
--  Ip.gatewayIpAddr = "new gatewayIpAddr"
-
-| If you you do change these settings, you will be required to re-build
-  the Example Project using CCS.
-
-.. list-table::
-   :header-rows: 1
-
-   * - Name
-
-     - Description
-
-     - EVM Configuration
-
-     - Expected Results
-
-     - SOC Supported
-
-   * - NIMU_BasicExample_evmXXXX_<core>exampleproject
-
-     - Example demonstrates ping from external source to Gigabit Ethernet port
-       on EVM.
-
-     - icev2AM335x: Jumpers J18 and J19 need to be set properly to select CPSW
-       or ICSS mode. Pin2 and Pin3 need to be connected for ICSS mode and Pin1
-       and Pin2 for CPSW mode. Update \*.cfg file with static IP to test. NIMU
-       for CPSW test requires connection of configured Ethernet port under test
-       to external PC on same subnet.
-
-     - Run ping from any other PC in the same subnet.
-
-       Ping response from the EVM verifies successful execution of example.
-
-     - AM335x
-
-       AM437x
-
-       AM57x
-
-       K2G
-
-   * - NIMU_ICSS_BasicExample_evmXXXX_<core>Exampleproject
-
-     - Example demonstrates ping from external source to PRU-ICSS Ethernet port
-       on EVM.
-
-     - icev2AM335x: Jumpers J18 and J19 need to be set properly to select CPSW
-       or ICSS mode. Pin2 and Pin3 need to be connected for ICSS mode and Pin1
-       and Pin2 for CPSW mode. Update \*.cfg file with static IP to test. NIMU
-       for CPSW test requires connection of configured Ethernet port under test
-       to external PC on same subnet.
-
-     - Run ping from any other PC in the same subnet . Ping response from the
-       EVM verifies successful execution of example.
-
-     - AMIC110
-
-       AM335x
-
-       AM437x
-
-       AM57x
-
-       K2G
-
-   * - NIMU_Cpsw_ExampleApp
-
-     - Example demonstrates ping from external source to Gigabit Ethernet port
-       on EVM.
-
-     - Update \*.cfg file with static IP to test. NIMU for CPSW test requires
-       connection of configured Ethernet port under test to external PC on same
-       subnet.
-
-     - Run ping from any other PC in the same subnet. Ping response from the
-       EVM verifies successful execution of example.
-
-     - AM65x
-
-       J721E
-
-   * - NIMU_IcssgExampleApp
-
-     - Example demonstrates ping from external source to PRU-ICSS Ethernet port
-       on EVM.
-
-     - Update \*.cfg file with static IP to test. NIMU for CPSW test requires
-       connection of configured Ethernet port under test to external PC on same
-       subnet.
-
-     - Run ping from any other PC in the same subnet . Ping response from the
-       EVM verifies successful execution of example.
-
-     - AM65x
-
-   * - NIMU_BasicClientExample_evmXXXX_<core>Exampleproject
-
-     - Example demonstrates creating local servers: TCP, UDP, data, null and
-       OOB.
-
-     - Same as above. Use DHCP by default.
-
-     - See TI NDK user guide, section 2 Example Applications for how to test.
-
-     - AM57x
-
-   * - NIMU_emacExampleClient_evmXXXX_<core>Exampleproject
-
-     - Example demonstrates creating local servers: TCP, UDP, data, null and
-       OOB.
-
-     - Same as above. Use DHCP by default.
-
-     - See TI NDK user guide, section 2 Example Applications for how to test.
-
-     - C665x
-
-       C667x
-
-       OMAP-L137/8
-
-   * - NIMU_BasicHelloWorldExample_evmXXXX_<core>Exampleproject
-
-     - Example demonstrates UDP helloworld echo test.
-
-     - Same as above. Use DHCP by default.
-
-     - See TI NDK user guide, section 2 Example Applications for how to test.
-
-     - AM57x
-
-   * - NIMU_emacExampleevmXXXX_<core>Exampleproject
-
-     - Example demonstrates UDP helloworld echo test.
-
-     - Same as above. Use DHCP by default.
-
-     - See TI NDK user guide, section 2 Example Applications for how to test.
-
-     - C665x
-
-       C667x
-
-       K2H/K/E/L
-
-       OMAP-L137/8
-
-   * - NIMU_DualMacExample_evmXXXX_<core>Exampleproject
-
-     - Example demonstrates using two EMAC ports with different subnets.
-
-     - Same as above. Use DHCP by default.
-
-     - Run ping from any other PC in the same subnet. Ping response from the
-       EVM verifies successful execution of example.
-
-     - AM57x
-
-   * - NIMU_FtpExample_evmXXXX_<core>Exampleproject
-
-     - Example demonstrates FTP server with put and get.
-
-     - Same as above. Use DHCP by default.
-
-     - From host PC make a FTP connection to EVM: ftp <EVM IP address>.
-       User:user Password:password Test put and get command and show the
-       throughput.
-
-     - AM335x
-
-       AM437x
-
-       AM57x
-
-       K2G
-
-   * - NIMU_ICSSFtpExample_evmXXXX_<core>Exampleproject
-
-     - Example demonstrates FTP server with put and get.
-
-     - Same as above. Use static IP by default.
-
-     - From host PC make a FTP connection to EVM: ftp <EVM IP address>.
-       User:user Password:password Test put and get command and show the
-       throughput.
-
-     - AM335x
-
-       AM437x
-
-       AM57x
-
-       K2G
-
-   * - NIMU_FtpCpsw_ExampleApp
-
-     - Example demonstrates FTP server with put and get.
-
-     - Same as above. Use static IP by default.
-
-     - From host PC make a FTP connection to EVM: ftp <EVM IP address>.
-       User:user Password:password Test put and get command and show the
-       throughput.
-
-     - AM65x
-
-       J7
-
-   * - NIMU_FtpIcssg_ExampleApp
-
-     - Example demonstrates FTP server with put and get.
-
-     - Same as above. Use static IP by default.
-
-     - From host PC make a FTP connection to EVM: ftp <EVM IP address>.
-       User:user Password:password Test put and get command and show the
-       throughput.
-
-     - AM65x
-
-.. note:: Not all the test examples are supported on all the platforms. The NDK
-   code is hardware agnostic, the NIMU driver however depends on the specific
-   SOC. The NDK code can be ported to different platforms. Some Windows host
-   test applications are available under ndk_3_xx_xx_xx\packages\ti\ndk\winapps.
-
-
-Running NDK example on ARM core of Keystone II devices
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-Before running the NDK example on ARM core of Keystone II
-devices(K2H/L/E/G), the following steps need to be performed.
-
--  Increase the NS_BootTask stack from 2048 to 4096 in netctrl.c:
-
-::
-
-    TaskCreate( NS_BootTask, "ConfigBoot", OS_TASKPRINORM, 4096,(UINT32)hCfg, 0, 0 );
-
--  Rebuild the NDK
--  Rebuild NIMU driver
-
-|
-
-CCLink Example
----------------
-
-Refer
-`Processor_SDK_RTOS_CCLINK <index_Foundational_Components.html#cclink>`__ for
-details on steps for running cclink controller and device examples on NDK.
-
-FAQ
----
-
-How to check which versions of NIMU driver is for my SOC?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-There are several versions of NIMU driver for different SOCs. Please
-check packages\ti\transport\ndk\nimu\build\makefile.mk
-
--  V0: C6657
--  V1: C6678
--  V2: K2H, K2K
--  V3: K2L, K2E
--  V4: AM572x, AM571x, AM437x, AM335x
--  V5: K2G
--  V6: OMAP-L137/138
--  V7: AM65x, J7
-|
-
-Is there any multicast streams limitation using the NDK?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In the NDK, the limit is defined by a macro at ti/ndk/stack/igmp/igmp.c:
-#define IGMP_MAX_GROUP 32 It is then used to create an array of IGMP
-records: static IGMP_REC igmp[IGMP_MAX_GROUP]; The IGMP_MAX_GROUP value
-can be increased, then rebuild the NDK stack.
-
-
-How to share a TCP/IP socket across tasks?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The basic building block of NDK stack code internally is an object handle.
-Internally to the stack, both sockets and pipes are addressed by object handles.
-However, at the application level, sockets and pipes are treated as file
-descriptors. To share a SOCKET, i.e. a file descriptor, a task must first
-allocate a file descriptor table by calling the function fdOpenSession(), then
-use the function fdShare() to share the file descriptor among multiple tasks.
-As described in NDK API reference guide, fdShare() is useful in a case where
-Task A opens a session and calls recv() in a loop on a socket. Task B has a
-loop that calls send() on the same socket. The call to send() from Task B will
-fail and then fdError() will return -1 if you do not call fdOpenSession() and
-then fdShare() from the second Task after the first Task has opened the socket.
-For an example that calls fdShare(), see the contest.c file in the
-<NDK_INSTALL_DIR>/packages/ti/ndk/tools/console directory.
-
-
-How to tune TCP buffer size for an optimal throughput?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The default TCP buffer size, CFGITEM_IP_SOCKTCPTXBUF/CFGITEM_IP_SOCKTCPRXBUF
-is 8192 defined in packages/ti/ndk/inc/stack/inc/resif.h of NDK package and
-can be re-configured in RTOS config file,e.g.
-Tcp.transmitBufSize = 16384;
-Tcp.receiveBufSize = 65536;
-NDK also provides a global TCP statistics counter structure NDK_tcps
-(ti/ndk/inc/stack/inc/tcpif.h) that can be analyzed in CCS View Expressions
-window, similaly, there is a global IP statistics counter structure NDK_ips
-(ti/ndk/inc/stack/inc/ipif.h).
-
-
-Why a pipe creation fails and fdError() returns -1?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Although sockets can be used for inter-task communications, it is not the most
-efficient method. The stack provides a second data communications model called
-pipes, which allow for local connection oriented communications.
-As a pipe is a full duplex connection oriented file descriptor, fdOpenSession()
-needs to be called, which opens a file descriptor session on a task thread so
-that the task can begin using file descriptor and other stream IO functions.
-
-How do I change the PBM buffer?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can configure the PBM buffer used by the NDK by opening the .cfg file with XGCONF, then clicking the Buffers button. This page lets you configure the buffer size, number of buffers and locations of the NDK Packet Buffer Manager (PBM) and the Memory Manager Buffer. Or, you can edit ndk_3_xx_xx_xx\packages\ti\ndk\stack\pbm\pbm_data.c (PKT_NUM_FRAMEBUF and PKT_SIZE_FRAMEBUF) and rebuild the NDK.
-
-Do you have any raw packet example?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-A raw socket is used to receive raw packets. This means packets received at the Ethernet layer will directly pass to the raw socket. Stating it precisely, a raw socket bypasses the normal TCP/IP processing and sends the packets to the specific user application. Please check the TI Network Developer's Kit (NDK) API Reference Guide http://www-s.ti.com/sc/techlit/spru524.pdf A.15 Raw Ethernet Module for details. Code example available in NIMU_emacClientExample_evmXXXX_<CPU>ExampleProject
-
-How do I enable the jumbo packet support?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Jumbo frames have packet sizes larger than 1500 bytes. Jumbo frame support can be built into an application by linking with libraries compiled for Jumbo frame support.  Two parts of changes are needed for NDK/NIMU example:
-1. NDK libraries: The NDK libraries would have to be recompiled with the following pre-processor definition added: _INCLUDE_JUMBOFRAME_SUPPORT.
-2. NIMU library: the CPSW switch has to be configured to support jumbo packet size and rebuilt. The coding is SOC specific, V0, V4, V5, V6 and V7 NIMU drivers use structure EMAC_OpenConfigInfo and pass the maximum packet size into max_pkt_size field. V1, V2 and V3 NIMU drivers use structure NETIF_DEVICE and pass the maximum packet size into mtu field.
-Finally, please rebuild the test application with updated NDK and NIMU libraries. A reference example for C6678 is available at: http://processors.wiki.ti.com/index.php/Enabling_Jumbo_Packet_Support_for_C6678. Note the work was implemented on earlier BIOS MCSDK package which was obsolete.
-
-Keystone PA or NDK example doesn’t work in other boot mode than no-boot mode using CCS/JTAG?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When running the program with CCS/JTAG, the default GEL file initializes the SOC. Same initialization, like turning on all the relevant power domains, and configuring the SGMII, Serdes, may not be implemented in other boot modes. First check GEL file under ccs_base\emulation\boards\<boards>\gel, function Global_Default_Setup() function to add the missing initializations into the application. Next, look for any boot mode dependent code in the application.  For example, passPowerUp() is called in no_boot mode to turn on PA, this has to be executed in your application when booting from other boot modes as well.
-
-
-
-Additional Documentation References
---------------------------------------
-
-+-----------------------------------+--------------------------------------------+
-| **Document**                      | **Location**                               |
-+-----------------------------------+--------------------------------------------+
-| NDK Programmer's Reference Guide  | http://www-s.ti.com/sc/techlit/spru524.pdf |
-+-----------------------------------+--------------------------------------------+
-| NDK User's Guide                  | http://www-s.ti.com/sc/techlit/spru523.pdf |
-+-----------------------------------+--------------------------------------------+
-| Network Developers Kit FAQ        | `Network Developers Kit FAQ`_              |
-+-----------------------------------+--------------------------------------------+
-| NDK Support Package Ethernet      | http://www-s.ti.com/sc/techlit/sprufp2.pdf |
-| Driver Design Guide               |                                            |
-+-----------------------------------+--------------------------------------------+
-| Rebuilding_the_NDK_Core           | http://processors.wiki.ti.com/index.php/   |
-| Rebuilding NDK Core               | Rebuilding_the_NDK_Core                    |
-+-----------------------------------+--------------------------------------------+
-
-.. _Network Developers Kit FAQ: http://processors.wiki.ti.com/index.php/Network_Developers_Kit_FAQ
-
diff --git a/source/rtos/PDK_Platform_Software/Network_and_Transport/_TimeSync.rst b/source/rtos/PDK_Platform_Software/Network_and_Transport/_TimeSync.rst
deleted file mode 100644
index ecb8b94a3..000000000
--- a/source/rtos/PDK_Platform_Software/Network_and_Transport/_TimeSync.rst
+++ /dev/null
@@ -1,214 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_TIMESYNC(PTP)
-
-Overview
---------
-
-Terms and Abbreviations
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-+-------------------------------+----------------------------------+
-| Acronym                       | Description                      |
-+===============================+==================================+
-| PTP                           |  Precision Time Protocol         |
-+-------------------------------+----------------------------------+
-| P2P                           |  Peer to Peer                    |
-+-------------------------------+----------------------------------+
-| E2E                           |  End to End                      |
-+-------------------------------+----------------------------------+
-| TC                            |  Transparent Clock               |
-+-------------------------------+----------------------------------+
-| OC                            |  Ordinary Clock                  |
-+-------------------------------+----------------------------------+
-| BC                            |  Boundary Clock                  |
-+-------------------------------+----------------------------------+
-| Controller                    |  PTP controller                  |
-+-------------------------------+----------------------------------+
-| Device                        |  PTP Device                      |
-+-------------------------------+----------------------------------+
-| BMCA                          |  Best Controller Clock Algorithm |
-+-------------------------------+----------------------------------+
-| RCF                           |  Synchronization/(Frequency      |
-|                               |  Compensation) Factor            |
-+-------------------------------+----------------------------------+
-| IEC 61558                     |  PTP profile for network control |
-|                               |  systems                         |
-+-------------------------------+----------------------------------+
-
-Introduction
-^^^^^^^^^^^^
-
-This document details the user guide aspects of PTP/1588 v2 controller/device implementation on PRU-ICSS.
-
-Dual EMAC firmware implementation supports P2P and the implementation is unique to Emac.
-The controller capability added to the TimeSync driver is currently limitted to sending Sync and
-Announce frames. The BMCA/Management part of PTP controller is not implemented.
-
-
-TimeSync (PTP) driver does the task of
-
-#. Running BMCA
-#. Calculating RCF and Sync packet interval.
-#. Performing clock synchronization
-#. Calculating peer and line delay
-#. Sending Delay Request and Delay Response frames (includes Pdelay Req and Pdelay Res)
-
-
-.. rubric:: Driver Configuration
-   :name: driver-configuration-timesync
-
-.. rubric:: **Board Specific Configuration**
-   :name: board-specific-configuration
-
-All board specific configurations like enabling clock and pin-mux are
-required before calling any driver APIs. By default Board_Init() API
-available under board module supports all initialization sequence for TI
-supported EVMs. In addition it initializes UART instance for
-Console/STDIO. Refer `Processor SDK RTOS Board
-Support <index_board.html#board-support>`__ for additional
-details.
-
-.. rubric:: **TimeSync Configuration Structure**
-   :name: timesync-configuration-structure
-
-The TimeSync driver needs to be initialized/configured with initial parameters during the driver initialization.
-
-icss_timeSync_init.c binds driver with TimeSync parameters.
-
-TimeSync_drvInit() API triggers all static configuration information available through parameters. Once initialization is complete the driver is ready for use.
-
-Please refer to TimeSync_ParamsHandle structure defined under '<pdk>/packages/ti/transport/timeSync/include/icss_timeSyncApi.h'
-
-
-APIs
-^^^^^
-
-API reference for Application:
-
-::
-
-    #include <ti/transport/timeSync/icss_timeSync.h>
-
-Below sequence indicates API calling sequence for a simple use case of
-timeSync controller operation
-
-.. code-block:: c
-
-    ...
-    Board_init(boardCfg);
-    timeSync_example_configureInterrupts(EMAC_PORT_NUM, &emacCfg);
-    ICSS_EmacSocSetInitCfg(instance, emacBaseAddr);
-    ICSS_EmacInit();
-    /* Assumption: firmware is downloaded and ICSS_EMAC driver is initialized */
-    TimeSync_drvInit(timeSyncHandle);
-    TimeSync_drvEnable(timeSyncHandle);
-    TimeSync_enableController();
-    While(1)
-    {
-        Delay();
-    }
-
-Below sequence indicates API calling sequence for a simple use case of
-timeSync device operation
-
-.. code-block:: c
-
-    ...
-    Board_init(boardCfg);
-    timeSync_example_configureInterrupts(EMAC_PORT_NUM, &emacCfg);
-    ICSS_EmacSocSetInitCfg(instance, emacBaseAddr);
-    ICSS_EmacInit();
-    /* Assumption: firmware is downloaded and ICSS_EMAC driver is initialized */
-    TimeSync_drvInit(timeSyncHandle);
-    TimeSync_drvEnable(timeSyncHandle);
-    TimeSync_disableController();
-    While(1)
-    {
-        Delay();
-    }
-
-**NOTE**
-:
-
-#. The TimeSync Tx callback interrupt is mapped to the ISR TimeSync_txTSIsr(), where the two PRU interrupts configured to ARM interrupt txIntNum are PRU_ARM_EVENT_6 and PRU_ARM_EVENT_7.
-#. The PTP frames are received via the Real Time (RT) call back from ICSS_EMAC driver and hence RT call back needs to be implemented at the application for ICSS-EMAC driver.
-
-Tasks Internally created from TimeSync_drvInit()
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Below tasks would be created after Application calls TimeSync_drvInit() function. The sample osal implementation is provided under <pdk>/packages/ti/transport/timeSync/example/src/common/timeSync_example_osal.c implementing these tasks.
-
-
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-| Handle Name                   | | Function Name                  | | What it does                                                  |
-+===============================+==================================+=================================================================+
-| timeSync_pDelayReqSendTask    | TimeSync_PdelayReqSendTask()     | | Send Peer Delay Requests periodically on both ports.          |
-|                               |                                  |   Delay is configurable. Only applicable for P2P configuration  |
-+-------------------------------+----------------------------------+-----------------------+-----------------------------------------+
-| timeSync_delayReqSendTask     | TimeSync_delayReqSendTask()      | | Send Delay requests to PTP Controller. This is currently done |
-|                               |                                  |   for every Sync frame. Pends indefinitely on a semaphore.      |
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-| timeSync_TxTSTaskP1           + TimeSync_TxTSTask_P1()           | | Process Tx timestamp for Port 1. Pends on an event posted by  |
-|                               |                                  |   Tx ISR indefinitely.                                          |
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-| timeSync_TxTSTaskP2           + TimeSync_TxTSTask_P2()           | | Process Tx timestamp for Port 2. Pends on an event posted by  |
-|                               |                                  |   Tx ISR indefinitely.                                          |
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-| timeSync_syncTxTask           + TimeSync_SyncTxTask()            | | Sends Sync frames on both ports in Controller mode.           |
-|                               |                                  |   Pends indefinitely on a semaphore posted by the DM Timer ISR  |
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-| timeSync_announceTxTask       | TimeSync_AnnounceTxTask()        | | Sends Announce frames on both ports periodically              |
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-| timeSync_NRT_Task             | TimeSync_NRT_Task()              | | NRT stands for non real time. Processes Peer delay frames in  |
-|                               |                                  |   the background and calculate peer delay.                      |
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-| timeSync_backgroundTask       | TimeSync_BackgroundTask()        | | Checks for Sync timeout and performs offset stabilization.    |
-+-------------------------------+----------------------------------+-----------------------------------------------------------------+
-
-
-Building timeSync Examples/Unit Test
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Setup the build environment `SetupBuildEnvironment <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#setup-environment>`__
-- Follow the steps as mentioned under `SDK example and test CCS Project Creation <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#pdk-example-and-test-project-creation>`__  for creating the CCS based example and test projects creation
-
-
-Sample Examples
-^^^^^^^^^^^^^^^
-
-
-+--------------------------+-----------------------+-----------------------+
-|       Name               |      Description      || Expected Results     |
-+==========================+=======================+=======================+
-| timeSync_BasicExample    | Simple timeSync       || Clock Sync           |
-|                          | example demonstrating |  results at Device    |
-|                          | sync between          |                       |
-|                          | Controller and Device |                       |
-+--------------------------+-----------------------+-----------------------+
-
-Additional References
----------------------
-
-+----------------------------+---------------------------------------------+
-| **Document**               | **Location**                                |
-+----------------------------+---------------------------------------------+
-| API Reference Manual       | $(TI_PDK_INSTALL_DIR)/packages/ti           |
-|                            | /transport/timeSync/docs/doxygen/html/index |
-|                            | .html                                       |
-+----------------------------+---------------------------------------------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/ICSS_EMAC_LLD/_Debug_with_ICSS_EMAC_LLD.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/ICSS_EMAC_LLD/_Debug_with_ICSS_EMAC_LLD.rst
deleted file mode 100644
index 41bc8b4a9..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/ICSS_EMAC_LLD/_Debug_with_ICSS_EMAC_LLD.rst
+++ /dev/null
@@ -1,621 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/ICSS_EMAC_LLD_debug_guide
-
-Introduction
-^^^^^^^^^^^^^^
-
-This is a companion guide to `ICSS EMAC Developer
-Guide <index_device_drv.html#development-with-icss-emac-driver>`__,
-if you have not read the developer guide it's highly suggested that you
-do so.
-
-Based upon the combined experience of development team, this document
-covers the most obvious use cases and debug scenarios present in ICSS
-EMAC LLD. Frequently asked questions from `E2E <https://e2e.ti.com/>`__
-forums which are relevant have also been added here.
-
-For individual protocols like Ethernet/IP, Profinet, EtherCat etc
-separate debugging guides are available which discuss specific use
-cases.
-
-As mentioned previously in developer guide, a discussion of EMAC LLD
-covers most of the ethernet driver/firmware issues and goes a long way
-in the understanding of other industrial protocol implementations. This
-applies to debug guide as well.
-
-Assumption
-"""""""""""
-
-Assumptions are same as those in developer guide. A basic understanding
-of ICSS Architecture and SoC is assumed, some level of familiarity with
-Ethernet driver development is also assumed. In addition to this a basic
-familiarity with the following tools is also assumed.
-
--  Code Composer Studio
--  Any serial terminal (Putty/Tera Term)
--  Wireshark or any other packet sniffing tool
--  Any PC based tool capable of sending packets
-
-Scope of the document
-""""""""""""""""""""""
-
-This document is meant to help the developer
-
--  Familiarize with common debugging tools and techniques
--  Identify and resolve frequently faced issues
-
-Common Debugging Tasks
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Loading and running on CCS
-""""""""""""""""""""""""""""
-
-1. Connect JTAG Emulator to EVM in-case of IDK or Connect USB cable to
-board in-case of ICE
-
-2. Select View->Target Configurations. Right click on the required
-configuration in the list and Select Launch Selected Configuration
-
-3. Right Click on the Cortex A9/A8 listed in Debug view and select
-Connect. (Click View->Debug to view debug window, if not visible)
-
-4. Select System Reset
-
-5. Select Suspend
-
-6. Load the GEL file and execute initialization script.
-
-7. Once the initialization is completed, Select Run->Load ->Load
-Program. Here browse to the required executable and click OK
-
-8. After a successful load, the program is expected to be in suspended
-state and program counter is pointing to main function. If the program
-is not in suspended state :
-
-i. Suspend the application by selecting Run->Suspend
-
-ii. Restart the application by selecting Run->Restart
-
-9. Run the application by selecting Menu->Run->Resume. This will execute
-the application.
-
-.. Image:: /images/De1.png
-
-NOTE
-
-• While launching a debug session for the first time, CCS will ask for
-the CPU to which the program needs to be loaded. Please select
-Cortex-A9/A8 and continue.
-
-• If TeraTerm does not display an output upon program execution.
-TeraTerm can be initialized just prior to program execution by
-performing steps 1-8 and then
-
-Disconnect the terminal session using File -> Disconnect
-
-Reconnect the terminal session with File -> New Connection
-
-• If there is a valid application in SPI or NOR flash(in their
-corresponding boot mode), on "System Reset" the application loads right
-away. This might cause issues on the application you load via JTAG. To
-avoid this, put a hardware breakpoint at 0x402f_0400(in case of MMSCD
-boot mode) or 0x30000000(in case of qSPI boot mode) and then do a
-"System Reset". You can then continue with Step 4 after this step.
-
-Connecting the PRU's
-"""""""""""""""""""""
-
-Check Link Status
-""""""""""""""""""
-
-Link Status is available as an array **linkStatus** in
-**ICSSEMAC_Object**. The status is updated in the Link ISR
-**ICSS_EmacLinkISR**. It's possible that the link interrupt is
-configured incorrectly or MDIO is not triggering the interrupts. (see
-`here <index_device_drv.html#link-interrupt>`__
-on how to configure Link Interrupt) In which case one needs to put a
-breakpoint in the ISR **ICSS_EmacLinkISR** and disconnect or connect the
-cable on any one port. The breakpoint should get hit, if it does not
-then there is some issue with the interrupt configuration.
-
-PHY status is read and status updated as shown below
-
-::
-
-    /*Read Link status for Port 0*/
-    linkStatus = ENETPhyDevLinkStatus(DEVICE_ID_ENET_PHY_MII, 0, 3);
-    ((ICSSEMAC_Object*)icssEmacHandle->object)->linkStatus[0]=(uint8_t)linkStatus;
-
-Even if the ISR is hit it's also possible; in case different PHY's
-(compared to those on EVM) are used that the PHY status registers are
-read incorrectly, if that's the issue then please consult the porting
-guide and reference manual for your PHY to figure out where the issue
-could be.
-
-Checking if Receive is working
-"""""""""""""""""""""""""""""""
-
-The receive path has been explained previously in the developer guide.
-See `here <index_device_drv.html#rx-data-path>`__.
-Rx issues can manifest themselves in several ways, the following table
-covers most of them (not exhaustively!)
-
-.. table::  **Receive issues and causes**
-
-   +-----------------------------------+-----------------------------------+
-   | Issue                             | Probable Cause                    |
-   +===================================+===================================+
-   | Host not receiving                | Rx interrupt not configured       |
-   | Multicast/Broadcast frames        | correctly,                        |
-   |                                   | Firmware not receiving, Storm     |
-   |                                   | Prevention enabled Rx is disabled |
-   +-----------------------------------+-----------------------------------+
-   | Unicast Packets (for Host)being   | Same as above except Storm        |
-   | dropped                           | Prevention                        |
-   |                                   | Interface MAC not configured      |
-   |                                   | correctly                         |
-   +-----------------------------------+-----------------------------------+
-   | Multicast/Broadcast frames not    | Storm Prevention enabled          |
-   | being forwarded                   | Firmware not receiving, Rx is     |
-   |                                   | disabled                          |
-   +-----------------------------------+-----------------------------------+
-   | Unicast frames (not for Host) not | Firmware not receiving            |
-   | being forwarded                   | Rx is disabled                    |
-   +-----------------------------------+-----------------------------------+
-   | Driver receiving packets but Raw  | NDK issues (there is a known      |
-   | socket not receiving frames       | issue, please see below)          |
-   +-----------------------------------+-----------------------------------+
-   | Packets are getting dropped       | Storm Prevention enabled          |
-   |                                   | Data is coming in too fast. See   |
-   |                                   | Interrupt pacing                  |
-   |                                   | `section <http://processors.wiki. |
-   |                                   | ti.com/index.php/ICSS_EMAC_LLD_de |
-   |                                   | velopers_guide#Interrupt_Pacing>` |
-   |                                   | __                                |
-   |                                   | to understand this behavior       |
-   +-----------------------------------+-----------------------------------+
-
-The first step is to identify the exact problem, to do that please
-perform these steps in order.
-
-#. **Check if Rx is disabled** : It's possible to disable Rx in firmware
-   through IOCTL. This is controlled through a location in ICSS memory.
-   See `memory map <index_device_drv.html#memory-map>`__.
-   Check this as a very first step. It's not a common error but it's
-   possible that user is invoking the IOCTL by mistake.
-#. **Check if firmware is receiving packets** : See statistics `this <index_device_drv.html#statistics>`__
-   and `this <index_device_drv.html#check-statistics>`__
-   and find out if PRU is receiving the frames. Failure to receive
-   frames in firmware can indicate other issues like corrupted frames,
-   link negotiation failure or PHY related issues.
-#. **Check if Rx interrupt is being asserted** : This can be one of the
-   reasons why Host would not receive packets. Put a break point in
-   **ICSS_EmacRxInterruptHandler** and send a single packet using any PC
-   based tool. The ISR should get hit. Refer to this
-   `section <index_device_drv.html#rx-interrupt>`__
-   on how to configure the interrupt properly if interrupt is not being
-   asserted.
-#. **Check if Packets are being copied in driver** : If the interrupt is
-   asserted but packets do not reach the application, check Host
-   statistics to verify if packets are being received correctly in the
-   driver. Refer to the
-   `section <index_device_drv.html#rx-data-path>`__\ on
-   Rx data path and put a breakpoint in **RxTask**. Step through to
-   verify that the priority is set correctly and packets are being
-   copied properly. If interrupt is being asserted correctly but packet
-   length is zero it indicates some data corruption in the receive
-   queues or firmware behaving incorrectly, this scenario should not
-   occur.
-#. **Check if NDK is receiving the frames** : If driver is receiving the
-   frames and user cannot see frames in socket then it indicates issues
-   with TCP/IP stack. Refer to `NDK User's
-   guide <http://www.ti.com/lit/ug/spru523i/spru523i.pdf>`__ on correct
-   usage of sockets. The example socket application provided in the
-   developer guide `here <index_device_drv.html#usage>`__
-   is known to work though. In addition to this check if NDK buffers
-   have been allocated correctly. If you are using your own TCP/IP stack
-   refer to the Porting Guide and double check.
-#. **Check if Storm prevention is enabled** : This is one of the most
-   common reasons why throughput may get lowered or if the threshold is
-   set incorrectly packets may not reach Host at all. Check if storm
-   prevention module is enabled by checking the variable
-   **suppressionEnabled** for both ports. Refer to
-   `this <index_device_drv.html#id59>`__
-   for more details. Additionally one should check the statistics to see
-   if the PRU statistics **stormPrevCounter** is getting incremented.
-#. **Check Interface MAC** : The firmware compares the interface MAC
-   written to the PRU memory by the Host against the incoming packets
-   destination MAC to verify if the packet must be forwarded to Host or
-   cut-through. Please refer to the `memory
-   map <index_device_drv.html#memory-map>`__
-   and check if the MAC value is what you are expecting it to be.
-#. **Queue Overflow** : If too many packets are received on a single
-   queue without Host emptying them out then overflow may occur, packets
-   will be lost in such a scenario. This is somewhat related to
-   throughput issues but may occur independently as well.
-#. **Check throughput** : This is applicable in case everything else
-   appears to be correct but the number of packets reaching the Host is
-   not 100% of the transmitted value. This can happen because of two
-   reasons. 1. Data rate is too fast and interrupt pacing is disabled.
-   2. Processing on Host is too slow and driver cannot cope with the
-   rate at which firmware is putting data in the queue. In such a
-   scenario first turn on Interrupt pacing to find if it solves the
-   issue (interrupt pacing has it's own limitations, refer to
-   `this <index_device_drv.html#interrupt-pacing>`__
-   to know more about it), if issue is still not resolved then try to
-   find the throughput by comparing the number of packets received on
-   the Host vs that in the firmware.
-
-**More on Throughput** : If throughput is low then try to find out how
-the Rx processing on Host can be sped up or if any other high priority
-task is blocking the execution of **RxTask**. The EMAC and switch are
-tested during release to cope with 100% throughput at line rate (960 IPG
-and 64 byte size packet) so any drop in throughput can only be caused by
-additional loading on the CPU. Use UIA which comes SYSBIOS for this
-purpose. Usage given
-`here <index_device_drv.html#checking-the-system-performance-using-uia>`__
-
-Checking if Transmit is working
-""""""""""""""""""""""""""""""""
-
-Because of it's nature Tx is much more reliable and there are far fewer
-issues related to it when compared to Rx. Transmit issues can be
-classified into two types. See `Tx data
-path <index_device_drv.html#tx-data-path>`__ for
-more information.
-
-#. **Cut-through issues** : Packets received on one port and meant to go
-   out of the opposite port. (Not applicable to EMAC)
-#. **Transmit from Host** : Packets sent out from the Host on any one
-   port.
-
-As a first step please check the statistics on firmware as well as Host
-to see if any packets have been sent out. Try to trace where the issue
-is by comparing transmit statistics for Host and firmware.
-
-The probable causes for transmit not working are listed below. This can
-also be used as a checklist for debugging.
-
-#. **Link down** : The link event is mapped to an ISR
-   **ICSS_EmacLinkISR** which in turn calls another API
-   **ICSS_EmacUpdatePhyStatus** to update the link status in firmware.
-   If this is not done correctly then it's possible that firmware will
-   read the event as link down even though physically the link is up.
-   Please check the link status to make sure that this is not the case.
-   The Tx API checks for link and will not transmit if the link is down
-   so this issue is more relevant to cut-through/store-forward. More on
-   Link status `here <index_device_drv.html#check-link-status>`__.
-#. **Incorrect speed** : The link ISR also checks for speed and
-   duplexity values. The values are written to in the same ISR
-   **ICSS_EmacUpdatePhyStatus**, if the speed is read incorrectly then
-   it's possible that firmware will not send out packets or may send out
-   garbage. In such a scenario firmware statistics will count the
-   packets as successful transmit but Tx might not actually happen. The
-   quickest way to debug this issue is to read the ICSS memory directly
-   in CCS memory window. Interface speed is written directly in memory
-   at the offset mentioned in `memory map <index_device_drv.html#memory-map>`__, please
-   verify the value (as mentioned in memory map) and compare with the
-   actual interface speed.
-#. **Incorrect pinmux for Collision/Carrier Sense** : This is applicable
-   in case of developers using their custom boards, it's important that
-   the collision and carrier sense signals be wired correctly (see ICEv2
-   `layout <http://www.ti.com/tool/tmdsice3359#Technical%20Documents>`__)
-   because the transmit code relies on these two signals to implement
-   half duplex functionality and wrong values may result in transmit
-   problems. If there is an issue with pinmuxing these two pins it's
-   recommended that half duplex functionality be disabled. Half Duplex
-   functionality is controlled by the variable **halfDuplexEnable**
-#. **Queue contention issues** : Looking at the QoS
-   `scheme <index_device_drv.html#quality-of-service-and-queues>`__
-   it's possible that there is a contention for the transmit queue when
-   both Host and the opposite port are trying to transmit on the same
-   port. In such cases if there are too many packets vying for the
-   contention queue they will be dropped. Such conditions are rare.
-#. **Queue overflow** : As the name suggests if too many packets are
-   sent out on a single queue then overflow can happen and packets may
-   get lost.
-#. **NDK transmit** : Issues with NDK buffers may cause issues with Tx,
-   in such cases put a breakpoint in **ICSS_EmacTxPacket** to see if NDK
-   is calling it.
-
-Check Statistics
-"""""""""""""""""
-
-Statistics form the core of debugging so this section is very important.
-A brief introduction to statistics has been provided previously in the
-statistics
-`section <index_device_drv.html#statistics>`__ of
-developer guide. This part explains how to use it for the purpose of
-debugging.
-
-As previously explained, statistics can be divided into two groups
-
--  On Firmware
--  Host based
-
-Host statistics are a subset of Firmware based statistics except some
-specialized statistics like **rxUnknownProtocol** and **linkBreak**.
-This property can be used to find out how many packets are being
-received in the firmware and how many are reaching Host.
-
-Getting the values
-''''''''''''''''''''
-
-Statistics are accessible in three ways
-
--  **IOCTL calls** : IOCTL calls (including an example) have been
-   previously explained
-   `here <index_device_drv.html#ioctl>`__ in
-   developer guide.
--  **Reading directly in memory window** : (This applies only to PRU
-   based statistics). Use the statistics `memory
-   map <index_device_drv.html#id63>`__ to find
-   out the offset and look at the memory directly. Information on how to
-   access the ICSS memory is provided
-   `here <index_device_drv.html#accessing-memory>`__.
--  **In CCS watch window** : When using CCS the statistics can be read
-   directly through the ICSS EMAC handle. Host statistics are available
-   through **hostStat** while PRU statistics are available through
-   **pruStat**. An example code snippet from **TxPacketEnqueue** API
-   shows host statistics being accessed.
-
-::
-
-    hostStatistics_t* hostStatPtr;
-    hostStatPtr = (hostStatistics_t*)((((ICSSEMAC_Object*)icssEmacHandle->object)->hostStat));
-    /*Access port specific statistics by incrementing the pointer*/
-    hostStatPtr += (portNumber - 1);
-    ICSS_EmacUpdateTxStats(macAddr,(unsigned int)lengthOfPacket, hostStatPtr);
-
-**NOTE :** Since they are void members they need to be typecast to
-access the members in CCS watch window.
-
-Example Usage
-'''''''''''''''
-
-Described below are some scenarios which involve multiple statistics,
-this will help the developer understand how to use statistics.
-
-**Example 1:** For example assume that 100k multicast packets of size 64
-bytes each are sent to Port 1 of switch (EtherNet/IP adapter example)
-and storm prevention is enabled such that 10k out of those 100k packets
-are dropped, out of those 990k, 10k packets have CRC error so the total
-number of packets reaching Host is only 980k but 990k packets get
-cut-through (multicast packets are cut-through except some protocol
-specific packets) because CRC is not verified for cut-through frames.
-For this example the statistics will look like this (only relevant
-fields have been populated)
-
-+--------------------+------------+--------------+--------------+
-| Member             | Host Stats | Port 0 Stats | Port 1 Stats |
-+====================+============+==============+==============+
-| *rxMcast*          | 980,000    | Example      | Example      |
-+--------------------+------------+--------------+--------------+
-| *txMcast*          | 0          | Example      | Example      |
-+--------------------+------------+--------------+--------------+
-| *rxCRCFrames*      | NA         | 10,000       | 0            |
-+--------------------+------------+--------------+--------------+
-| *stormPrevCounter* | NA         | 10,000       | 0            |
-+--------------------+------------+--------------+--------------+
-
-Accessing Memory
-^^^^^^^^^^^^^^^^^^
-
-ICSS Shared RAM
-"""""""""""""""""
-
-This section explains how to access ICSS memory. The icss_emacSwitch.h
-file contains the offset information.
-
-The DRAM base addresses for Port 1 and Port 2 can be obtained by adding
-emacHandle1 to Expressions tab in CCS and typecasting it to
-ICSSEMAC_HwAttrs.
-
-For AM335x, the addresses are:
-
-.. Image:: /images/Dramaddr.png
-
-|
-| **Example:** For example, if storm prevention counter location needs
-  to be accessed for Port 1 of ICEv2 EVM, the following steps give the
-  value of the location to be entered in the Memory Browser of CCS:
-
-::
-
-    #define STORM_PREVENTION_OFFSET      STATISTICS_OFFSET + STAT_SIZE
-
-where, STATISTICS_OFFSET is 0x1f00 and STAT_SIZE is
-RX_1024_MAX_BYTE_FRAME_OFFSET + 4, RX_1024_MAX_BYTE_FRAME_OFFSET is
-defined as 0x88. This gives 0x1f00 + 0x88 + 4 = 0x1f8c
-
-Hence enter 0x4a301f8c in the Memory Browser and check the content. If
-the value is 01, storm prevention functionality is enabled and if it is
-00, it is disabled.
-
-.. Image:: /images/Stormprev.png
-
-|
-| Similarly, the value would be 0x4a302000 + 0x1f8c (DRAM base address
-  for Port 2 + Storm Prevention Offset) = 0x4a303f8c for Port 2 of
-  ICEv2.
-
-For AM437x, the DRAM base addresses are as follows:
-
-.. Image:: /images/Dramaddram4.png
-
-|
-
-System Debug
-^^^^^^^^^^^^^^
-
-SYS/BIOS
-"""""""""
-
-Using ROV to Debug RTOS
-'''''''''''''''''''''''''
-
-To view ROV tab, goto Tools -> RTOS Object View (ROV) and halt the debug
-session.
-
-.. Image:: /images/Rov.png
-
-|
-
-Checking the system performance using UIA
-'''''''''''''''''''''''''''''''''''''''''''
-
-The UIA (Unified Instrumentation Architecture) is a target-side package
-that provides instrumentation services which can be downloaded from
-`[1] <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/uia/index.html>`__.
-System Analyzer is a suite of host-side tools that use data captured
-from software instrumentation, hardware instrumentation, and CPU trace
-to provide visibility into the real-time performance of the target
-application, which includes the menu commands in Tools > RTOS Analyzer
-menu of CCS.
-
-The following code needs to be added to the configuration file to enable
-performance tests on AM335x/AM437x using UIA 2.x version:
-
-::
-
-    var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
-    var SysStd = xdc.useModule('xdc.runtime.SysStd');
-
-::
-
-    System.SupportProxy = SysStd;
-
-::
-
-    /* Enable CPU Load logging */
-    LoggingSetup.loadLogging = true;
-
-::
-
-    /*
-     *  Enable Task, Swi, and Hwi Load logging. This allows the Idle Task
-     *  usage to make more sense. Otherwise Hwi and Swi load is factored into
-     *  each task's usage.
-     */
-    LoggingSetup.loadTaskLogging = true;
-    LoggingSetup.loadSwiLogging = true;
-    LoggingSetup.loadHwiLogging = true;
-
-::
-
-    LoggingSetup.sysbiosHwiLogging = true;
-    LoggingSetup.sysbiosSwiLogging = true;
-    LoggingSetup.sysbiosLoggerSize = 65536;
-    Main.common$.diags_ENTRY = Diags.ALWAYS_ON;
-    Main.common$.diags_EXIT = Diags.ALWAYS_ON;
-    LoggingSetup.disableMulticoreEventCorrelation = true;
-
-For new log records, the ARM should be paused. The CPU load graph gives
-the loading percentage which can be used to determine the additional
-task needed to load CPU to a specific level to perform NDK tests at
-different loads.
-
-|
-
-Using SYS/BIOS Timer to measure performance
-'''''''''''''''''''''''''''''''''''''''''''''
-
-NDK
-""""""
-
-Performing NDK tests
-''''''''''''''''''''''
-
-The steps to be followed in order to enable NDK Performance Tests are:
-
-1. Add this code snippet to the respective configuration files
-(am335x_app.cfg or am437x_app.cfg)
-
-::
-
-    Global.networkOpenHook = "&netOpenHook";
-    Global.networkCloseHook = "&netCloseHook";
-
-2. Ensure that nethooks.c file is present in the application folder. (If
-not, copy it from \\ti_internal\examples\ethernet_switch\Tcp)
-
-3. Build and load the application.
-
-4. In windows command prompt, navigate to the location where send.exe
-resides in the test PC (e.g.,
-C:\ti\ndk_2_24_02_31\packages\ti\ndk\winapps).
-
-5. Enter this command: send.exe %DUT_IP_ADDRESS% 100
-
-where,
-
-DUT_IP_ADDRESS=192.168.2.3 for Port 1 and 192.168.1.3 for Port 2 in case
-of EMAC application
-
-100 is the console print interval, i.e., a console print appears for
-every 100 packets transmitted
-
-6. Similarly, recv.exe, echoc.exe and testudp.exe applications are run
-to test performance.
-
-|
-
-Measuring network performance
-'''''''''''''''''''''''''''''''
-
-The network performance can be measured from the console output upon
-running the above tests. Consider the log when send.exe application is
-run for a few minutes till it stabilizes as below:
-
-.. Image:: /images/Ndksend.png
-
-Here, 8192 bytes are being sent at 12800000 bytes/s. As NDK performance
-is measured at MBPS (Megabits per second), conversion is:
-
-1 byte = 7.6294e-6 megabits
-
-which gives (12800000*8/1024)/1024 = 97.65 MBPS
-
-**Note:** The above procedure is applicable for send.exe, recv.exe and
-echoc.exe tests. The testudp.exe application tests UDP packet payloads
-from 1 to 1472 bytes and test loop should pass.
-
-|
-
-Checking NDK Buffers
-'''''''''''''''''''''
-
-Frequently Encountered Issues
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Build Issues
-"""""""""""""
-
-Tools compatibility
-'''''''''''''''''''''
-
-One of the frequent issues faced during build are issues of tools
-compatibility. The SDK build is dependent on NDK, SysBIOS and XDC Tools.
-While we try to maintain backward compatibility it's not always possible
-to do so, hence it's recommended that the correct versions of the tools
-are downloaded and used. The compatible versions are listed in the user
-guide
-(`sample <http://processors.wiki.ti.com/index.php/SYSBIOS_Industrial_SDK_02.01.00.01_User_Guide>`__)
-of every SDK release.
-
-System Variables
-''''''''''''''''''
-
-The variable *IA_SDK_HOME* must point to *(place where SDK is
-installed)/public/sdk*, most often than not this is the main reason for
-build issues, especially when multiple SDK's are installed. This
-variable is used everywhere during the build process to select include
-files, libraries, tools etc.
-
-Migration from 1.1 to 2.1 Industrial SDK
-'''''''''''''''''''''''''''''''''''''''''
-
-There is a possibility of build issue while migrating from 1.1 to 2.1
-Industrial SDK. The “Debug” folder needs to be removed from the project
-as separate build configurations are available for AM335x and AM437x
-EVMs in 2.1 SDK.
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/ICSS_EMAC_LLD/_Develop_with_ICSS_EMAC_LLD.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/ICSS_EMAC_LLD/_Develop_with_ICSS_EMAC_LLD.rst
deleted file mode 100644
index a38709151..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/ICSS_EMAC_LLD/_Develop_with_ICSS_EMAC_LLD.rst
+++ /dev/null
@@ -1,2412 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/ICSS_EMAC_LLD_developers_guide
-
-Terms and Glossary
-^^^^^^^^^^^^^^^^^^^
-
-.. table::  **Glossary**
-
-   +-----------------+-----------------+-----------------+-----------------+
-   | Abbreviation    | Meaning         | Abbreviation    | Meaning         |
-   +=================+=================+=================+=================+
-   | ICSS            | Industrial      | SDK             | Industrial      |
-   |                 | Communicatin    |                 | Software        |
-   |                 | Sub-System      |                 | Development Kit |
-   +-----------------+-----------------+-----------------+-----------------+
-   | PRU             | Programmable    | INTC            | Interrupt       |
-   |                 | Real Time Unit  |                 | Controller      |
-   +-----------------+-----------------+-----------------+-----------------+
-   | LLD             | Low Level       | SoC             | System On Chip. |
-   |                 | Driver          |                 | Platforms like  |
-   |                 |                 |                 | AM335x/AM437x   |
-   |                 |                 |                 | etc             |
-   +-----------------+-----------------+-----------------+-----------------+
-   | EMAC            | Ethernet MAC    | RTOS            | Real Time       |
-   |                 |                 |                 | Operating       |
-   |                 |                 |                 | System          |
-   +-----------------+-----------------+-----------------+-----------------+
-   | TRM             | Technical       | DLR             | Device Level    |
-   |                 | Reference       |                 | Ring - a        |
-   |                 | Manual for an   |                 | redundancy      |
-   |                 | SoC. Such as    |                 | protocol for    |
-   |                 | `this <http://w |                 | EtherNet/IP.    |
-   |                 | ww.ti.com/lit/u |                 |                 |
-   |                 | g/spruh73l/spru |                 |                 |
-   |                 | h73l.pdf>`__.   |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | Rx/Tx           | Packet          | Host/CPU/Cortex | Used            |
-   |                 | Receive/Packet  |                 | interchangeably |
-   |                 | Transmit        |                 | and refers to   |
-   |                 |                 |                 | the Application |
-   |                 |                 |                 | Processor       |
-   +-----------------+-----------------+-----------------+-----------------+
-
-|
-
--  **Bold** typeface refers to name of function/API/variable/structure.
--  Code snippets are shown as below
-
-::
-
-    Sample code snippet
-
-Document Revision Table
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. table::  Document Revision
-
-   +--------------+----------+-----------------------------------+
-   | Date         | Revision | Comments                          |
-   +==============+==========+===================================+
-   | 02-Oct-2015  | v.1.0    | Initial Release                   |
-   +--------------+----------+-----------------------------------+
-   | 04-Oct-2015  | v.1.1    | Fixed links and images            |
-   +--------------+----------+-----------------------------------+
-   | 04-July-2016 | v.1.2    | Added Time Triggered Send details |
-   +--------------+----------+-----------------------------------+
-
-Introduction
-^^^^^^^^^^^^^^
-
-The `Industrial SDK <http://www.ti.com/tool/sysbiossdk-ind-sitara>`__
-release from Texas Instruments enables the use of the PRU-ICSS for
-ethernet packet processing. This is used to implement several Industrial
-Ethernet based protocols including Profinet, EtherNet/IP, EtherCAT etc.,
-The SDK contains one example for each protocol. These are available
-under *SDK/public/examples*. For more information on protocols,
-examples, folder structure and information on how to use the SDK, please
-refer to the `Getting Started
-Guide <http://processors.wiki.ti.com/index.php/AM335x_SYSBIOS_Industrial_SDK_Getting_Started_Guide>`__.
-
-In addition to these, the SDK comes with an Ethernet MAC example. This
-example uses two PRU's to implement two independent MAC's with two
-different MAC addresses and two different IP addresses. To provide an
-analogy, this is somewhat similar to a two port Ethernet PCIe NIC card
-on a PC, only here, the Ethernet interface is available along with the
-Host processor on a single SoC.
-
-Since all the Industrial protocols and Ethernet MAC share the same basic
-software architecture a discussion of Ethernet MAC goes a long way in
-understanding the implementation of other protocols. This is a
-recommended reading for anyone trying to develop or use other Ethernet
-based protocols provided in the SDK.
-
-Assumption
-"""""""""""""
-
-The guide is geared towards helping developers with starting to build
-applications using the Ethernet MAC and as such does not contain
-extensive architectural and design information. Readers are expected to
-be well versed with PRU-ICSS hardware architecture and peripherals. A
-description of the PRU-ICSS can be found
-`here <http://processors.wiki.ti.com/index.php/PRU-ICSS>`__.
-
-This guide also assumes general familiarity with the SDK structure and
-Industrial EVM's. If you are not familiar with this then please go
-through the Getting Started Guide mentioned previously.
-
-Current SDK release
-`2.1.0.1 <http://downloads.ti.com/sitara_indus/esd/SYSBIOSSDK-IND-SITARA/latest/index_FDS.html>`__
-covers both AM335x and AM437x platforms, please refer to the TRM's for
-details on the SoC. The TRM's can be found here.
-`AM335x <http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf>`__/`AM437x <http://www.ti.com/lit/ug/spruhl7d/spruhl7d.pdf>`__.
-
-Scope of the Document
-""""""""""""""""""""""
-
-This document:
-
--  Enables a developer to build simple applications using the Ethernet
-   Driver and the sample Ethernet MAC application
--  Explains the components, software organization and architecture of
-   the Ethernet driver briefly. This is only to enable developers to use
-   and debug the modules. A detailed discussion of the architecture is
-   beyond the scope of this document.
--  Explains usage and simple tasks through use cases and examples
--  Helps port another TCP/IP Stack or RTOS for the Ethernet MAC example
-
-The document follows a hands on approach and different aspects are
-explained through examples and code snippets, these in turn are derived
-from questions on the forum and field.
-
-To prevent the guide from becoming too big and to limit it's scope a
-separate `debugging
-guide <index_device_drv.html#debug-with-icss-emac-driver>`__
-has been written which covers various other aspects such as Q&A's and
-Debug examples with screenshots. The two documents must be used in
-conjunction to utilize them fully.
-
-.. note::
-   The code snippets in this guide are only informative, they may or may
-   not compile if taken as it is. Developers are requested to consult the
-   API guide and other relevant user guides for exact coding details.
-
-Software Architecture
-^^^^^^^^^^^^^^^^^^^^^^
-
-The ICSS EMAC consists of driver + firmware implementation. Firmware
-refers to the code running on the two PRU's which are part of ICSS while
-driver refers to that portion of code running on host which is directly
-associated with the firmware. The two PRU's are responsible for
-reception of packets while Host runs higher level tasks.
-
-Logically the software on host can be partitioned into
-
--  Ethernet Driver - Copying packet data and providing to upper layers.
-   Managing PRU/ICSS.
--  TCP/IP and other network stack. NDK in this case.
--  RTOS code. SYS/BIOS in this case.
--  Peripheral initialization and management.
-
-Out of these the first three are relevant to this discussion. Only the
-driver is discussed in depth while NDK and SYS/BIOS are mentioned in
-passing whenever relevant.
-
-File Organization
-""""""""""""""""""
-
-SDK Folder structure is covered in the SDK User Guide
-`here <http://processors.wiki.ti.com/index.php/SYSBIOS_Industrial_SDK_02.01.00.01_User_Guide#SDK_Directory_Structure>`__.
-This guide only covers the contents of the folder referred to as
-*os_drivers* in the user guide.
-
-The contents of the folder *os_drivers* are discussed briefly:
-
--  ***lld*** - Refers to Link Layer Driver. This contains the core of
-   the driver which implements the following:
-
-   -  Rx - Copying the packet received from the firmware and providing
-      it to the TCP/IP stack
-   -  Tx - Providing packet from TCP/IP stack to the firmware
-   -  Learning/Forwarding Data Base - refer `here <index_device_drv.html#learning-fdb>`__
-   -  Storm Prevention implementation - refer `here <index_device_drv.html#storm-control>`__
-   -  Host Statistics implementation - refer `here <index_device_drv.html#statistics>`__
-
--  ***pruss*** - Refers to the software which manages the PRU. It
-   performs the following tasks
-
-   -  Initializing the PRU memory
-   -  Populating memory offsets, MAC addresses in PRU memory
-   -  Managing PRU Interrupt Controller
-
--  ***ICSS*** - Contains software related to the NDK (TCP/IP) Interface.
-
-   -  TCP/IP stack related initialization
-   -  Configuring IP address
-   -  ARM interrupt management
-
-EMAC and Switch
-"""""""""""""""""
-
-It is important to differentiate between the two different types of
-implementations in SDK context because this keeps coming up while
-discussing SDK and it's components. An EMAC example implements two
-independent Ethernet MAC's using PRU 0/1, they have two different MAC,
-IP addresses and two different instances of the TCP/IP stack while a
-Switch presents a single IP and MAC address for any external entity.
-Another important difference which is obvious from the name is that an
-EMAC does not forward a packet from one port to another like a Switch.
-
-SDK only provides a separate EMAC example, right now there is no example
-in the SDK for a standalone Switch on the lines of EMAC. The example
-that comes close to it is the EtherNetIP adapter which is a standalone
-Ethernet Switch running a EtherNet/IP protocol stack. Instructions on
-how to remove the EtherNet/IP part of it are given
-`here <http://processors.wiki.ti.com/index.php/SYSBIOS_ISDK_Steps_for_creating_stand_alone_switch_example>`__.
-
-There are some important differences between an EMAC and Switch
-
-|
-
-.. table::  Differences between EMAC and Switch
-
-   +-----------------------------------+-----------------------------------+
-   | EMAC                              | Ethernet Switch                   |
-   |                                   | (Profinet and EtherNet/IP)        |
-   +===================================+===================================+
-   | Two interface MAC addresses       | Single interface MAC address      |
-   +-----------------------------------+-----------------------------------+
-   | PRU0 transmits on Port0 and PRU1  | PRU0 transmits on Port1 and PRU1  |
-   | on Port1                          | on Port0                          |
-   +-----------------------------------+-----------------------------------+
-   | Two TCP/IP instances and two IP   | One TCP/IP instance and one IP    |
-   | addresses                         | address                           |
-   +-----------------------------------+-----------------------------------+
-   | Two Rx interrupts, semaphores and | Single Rx interrupt, semaphore    |
-   | tasks for two ports               | and task                          |
-   +-----------------------------------+-----------------------------------+
-   | Two ICSS EMAC Handles             | Single ICSS EMAC Handle           |
-   +-----------------------------------+-----------------------------------+
-   | No collision handling             | Collision buffer with Collision   |
-   | (independent MAC's)               | Handling                          |
-   |                                   | Collision refers to Queue         |
-   |                                   | Contention                        |
-   +-----------------------------------+-----------------------------------+
-   | No forwarding of packets          | Packets forwarded depending on    |
-   |                                   | forwarding rules                  |
-   +-----------------------------------+-----------------------------------+
-
-Ports in Driver context
-""""""""""""""""""""""""""
-
-Before beginning it’s important to explain the conventions used in this
-document, although there are two physical ports for every ICSS for the
-sake of convenience the Host is considered as a third port. In fact for
-some protocols this is the logical partitioning used. The convention
-used here is two physical ports and one host port.
-
-The ports are referred to as
-
--  Host Port - *ICSS_EMAC_PORT_0*
--  Physical Port 0 - *ICSS_EMAC_PORT_1*
--  Physical Port 1 - *ICSS_EMAC_PORT_2*
-
-This convention is followed throughout the document as well as inside
-the driver and firmware.
-
-Driver Architecture and Memory Map
-"""""""""""""""""""""""""""""""""""
-
-A detailed discussion of the architecture is beyond the scope of this
-document. A brief summary is provided below to explain where the data is
-copied to, how and why.
-
-While discussing the ICSS Switch we are mainly concerned with 4 types of
-memories.
-
-DDR
-'''''
-
-This is the memory from where ARM core operates. It's not on the SoC and
-hence has a lower performance. This is cached.
-
-This contains
-
--  TCP/IP Buffers.
--  Learning/FDB tables.
--  Host Statistics.
--  Control structures and variables.
-
-L3 OCMC RAM
-''''''''''''
-
-This is where the actual packet buffers or queues are located. There are
-15 queues (Switch) or 12 queues (EMAC) in total. 4 queues for each port
-(including host) and 1 additional queue for each port to handle
-collision. This is covered later in QoS section. Developer needs to know
-that firmware copies the packet data here after receiving them and this
-is where the driver writes the packet data meant for transmission using
-the firmware. So this acts as a place holder for packet data before it
-received or transmitted. This memory resides inside the SoC (but outside
-ICSS) and is faster than DDR. It's buffered but non-cached. Size varies
-from SoC to SoC, please refer to the TRM for more details. The L3 OCMC
-RAM contains:
-
--  Host receive queues
--  Port transmit queues
--  Collision queues (not in EMAC mode)
-
-.. note::
-   This memory map is applicable only for EMAC application. Other
-   applications might have their own map.
-
-
-Shared Data RAM
-'''''''''''''''''
-
-This is specific to the PRU subsystem although access is possible from
-Host albeit slowly. Data common to both PRU's such as Host queue
-descriptors are stored here. A lot of the memory is available for
-protocol or application specific usage, for more details refer to the
-memory map. Size varies from SoC to SoC, please refer to the TRM for
-more details. The Shared Data RAM contains
-
--  Host queue descriptors
--  Buffer descriptors for all 12 queues
--  Host Rx Context for 4 Host receive queues
-
-.. note::
-   This memory map is applicable only for EMAC application. Other
-   applications might have their own map.
-
-
-PRU0 Data RAM
-'''''''''''''''
-
-This is similar to Shared Data RAM though meant for use only by PRU0.
-Access from PRU1 is also possible, so the separation is only logical,
-not in hardware. Size varies from SoC to SoC, please refer to the TRM
-for more details. The PRU0 Data RAM contains:
-
--  Port 0 Time Triggered Send variables
--  Port 0 Queue descriptors for 4 Tx queues
--  Port 0 Tx Context for 4 Port Tx queues
--  Port 0 Statistics
--  Port 0 MAC ID
--  Port 0 Port, Speed and Duplex information
-
-.. note::
-   This memory map is applicable only for EMAC application. Other
-   applications might have their own map.
-
-PRU1 Data RAM
-''''''''''''''
-
-Similar to PRU0 Data RAM but for PRU1.
-
-Quality of Service and Queues
-""""""""""""""""""""""""""""""
-
-Quality of Service is very important for an Ethernet Switch/EMAC as it
-allows high priority packets to be processed separately from regular
-packets. This provides reliability for real time traffic. In EMAC this
-is done using queues which are mapped to 8 VLAN based priority levels.
-Each queue is a block of memory on L3 used to store the packet data.
-Queue sizes may vary and are build time configurable from
-*icss_emacSwitch.h*, for example host queue sizes used for default EMAC
-application are given below, the sizes are denoted by blocks. Each block
-is 32 bytes in size. The sizes are limited by L3 size which are dictated
-by SoC. For in depth information on how to re-build the icss-emac LLD
-PDK component in case your use case requires re-sizing the Queue sizes,
-refer to
-`[1] <How_to_Guides.html#rebuild-drivers-from-pdk-directory>`__.
-
-::
-
-    #define HOST_QUEUE_1_SIZE      194
-    #define HOST_QUEUE_2_SIZE       194
-    #define HOST_QUEUE_3_SIZE       194
-    #define HOST_QUEUE_4_SIZE       194
-
-The transmit queues sizes are denoted separately
-
-::
-
-    #define QUEUE_1_SIZE       97
-    #define QUEUE_2_SIZE        97
-    #define QUEUE_3_SIZE        97
-    #define QUEUE_4_SIZE        97
-
-So in total there are 15 queues (12 queues in EMAC), 4 receive queues
-for Host and 4 transmit queues for each of the two physical ports. In
-addition to these there is 1 collision queue each for Host and 2 ports
-which can hold one packet irrespective of packet size.
-
-.. note::
-   There are no collision queues in EMAC.
-
-
-The figure below is illustrative to remember this
-
-How QoS Works
-''''''''''''''
-
-Switch QoS
-~~~~~~~~~~~~
-
-When a packet is received in firmware, the 3 bit PCP field of the VLAN
-tag is read and the packet is copied to the appropriate queue based on
-fixed mapping which maps 2 levels(out of 8) of QoS to one queue. So 7 &
-6 map to Queue 4, 5 & 4 to Queue 3 and so on. On the driver this queue
-number then translates to the priority value and is used to decide how
-to process the packet. If a packet is missing VLAN tag then the lowest
-priority queue Queue 4 is chosen.
-
-EMAC QoS
-~~~~~~~~~
-
-PCP to queue mapping is different for EMAC. In EMAC, the 4 Host receive
-queues are split into two groups. Queue 1 and Queue 2 are used for
-storing packets received at PRU0/Port1 and Queue 3 and Queue 4 are used
-for storing packets received at PRU1/Port2. So, the low priority queues
-are Queue 2 and Queue 4 for Port 1 and Port 2 respectively. Queue 1 and
-Queue 3 are high priority queues for Port 1 and Port 2 respectively.
-
--  All the non-VLAN tagged frames are stored in the lowest priority
-   queue (Queue 2 for Port 1 and Queue 4 for Port 2).
--  VLAN tagged frames with “Priority Code Point (PCP)” value of 4, 5, 6
-   and 7 are stored in highest priority queue (Queue 1 for Port 1 and
-   Queue 3 for Port 2).
--  VLAN tagged frames with “Priority Code Point (PCP)” value of 0, 1, 2,
-   and 3 are stored in low priority queue (Queue 2 for Port 1 and Queue
-   4 for Port 2).
-
-More on this in the next section where driver side Rx processing is
-discussed in detail.
-
-.. note::
-   -  When a queue overflows, packets are **not** automatically copied to
-      the next free queue. So overflow can occur.
-   -  Contention/Collision queue can only handle a single packet
-      irrespective of size, anything above is dropped.
-   -  On Tx side, there is no special handling with regards to QoS. Data is
-      copied to one of the four queues based on the **queuePriority** field
-      **ICSS_EmacTxArgument** structure passed to the **ICSS_EmacTxPacket**
-      API.
-   -  At the moment driver/firmware doesn't support DSCP.
-
-
-Data Path
-"""""""""""
-
-Data path refers to the control flow which is executed on the driver and
-firmware to send or receive a packet. A basic understanding of it goes a
-long way in explaining the software architecture and if a developer is
-only trying to use the Rx and Tx capabilities of EMAC or Switch a
-knowledge of this is sufficient to build an application.
-
-Rx Data Path
-''''''''''''''
-
-Packets are received in the ICSS from where they are copied by the PRU's
-to L3 memory. The PRU's then assert an interrupt to tell the Host about
-the presence of a packet. PRU avoids corruption and does not write over
-the memory till the packet is copied by the Host.
-
-The flowchart shown above shows the sequence in very broad strokes. A
-detailed description is given below.
-
-#. PRU Posts an Rx interrupt to the ARM interrupt controller. For EMAC
-   each PRU has a separate Rx interrupt, the configuration for which is
-   done in the application (details in Interrupts).
-#. The interrupt triggers the ISR **ICSS_EmacRxInterruptHandler** which
-   in turn posts a semaphore rxSemaphoreHandle to signal **RxTask** to
-   empty the Rx queues.
-#. The **RxTask** function goes through all the queues, extracts the
-   port/queue number and provides it to an API which copies data from L3
-   to DDR. The code excerpt is shown below with explanations.
-
-.. code-block:: c
-
-    /*Read till all queues are empty*/
-    while(allQueuesEempty != 1 && numPacketsInLoop <= ((((ICSSEMAC_Object*)icssEmacHandle->object)->emacInitcfg)->pacingThreshold))
-    {
-         /*This API reads the queues and gets the queue and port number for each packet*/
-         pLength = ICSS_EmacRxPktInfo(icssEmacHandle, &port_number, &queue_number);
-         if(pLength > 0)
-         {
-              if(queue_number >= ((ICSSEMAC_Object*)(icssEmacHandle->object))->emacInitcfg->ethPrioQueue)
-              {
-                   /*Based on queue priority settings decide if the packet is to be sent to the TCP/IP stack*/
-                   /*This API is hooked to NDK*/
-                   icssEmacHwIntRx(&queue_number,icssEmacHandle);
-              }
-              else
-              {
-                   /*Protocol specific callback*/
-                   if(((((ICSSEMAC_Object*)icssEmacHandle->object)->callBackHandle)->rxRTCallBack)->callBack != NULL)
-                   {
-                        ((((ICSSEMAC_Object*)icssEmacHandle->object)->callBackHandle)->rxRTCallBack)->callBack(&queue_number,
-                        ((((ICSSEMAC_Object*)icssEmacHandle->object)->callBackHandle)->rxRTCallBack)->userArg);
-                   }
-                   else
-                   {
-                        /* just dump the packet here so we do no stall the queues*/
-                        ICSS_EmacRxPktGet(icssEmacHandle,(uint32_t)dest_address, queue_number, &port_number, &more);
-                   }
-              }
-              ...
-              ...
-    }
-
-In the code snippet above, function **ICSS_EmacRxPktInfo** goes through
-each queue one at a time, extracts the port & queue number information
-for every packet and provides it to functions below. Based on the
-priority of the packet which is decided by the queue number (refer to
-`discussion <index_device_drv.html#how-qos-works>`__
-on QoS and queues) driver decides to either forward it to NDK, done by
-**icssEmacHwIntRx** or give it to the callback function.
-
-The threshold for this decision is decided by the user settable
-parameter shown in the code above.
-
-.. code-block:: c
-
-    ((ICSSEMAC_Object*)(icssEmacHandle->object))->emacInitcfg->ethPrioQueue)
-
-Anything lower than this configured value goes to the callback function.
-If a callback is not registered then the queue is just emptied to
-prevent queues from overflowing. This is done by the function
-**ICSS_EmacRxPktGet** which takes a single packet and copies it into
-**dest_address** provided as a parameter. This is not a dummy API but a
-basic Rx API which performs the task of copying data from L3 to DDR,
-even the NDK API **icssEmacHwIntRx** internally calls
-**ICSS_EmacRxPktGet** to fetch the packet data.
-
-If a developer is building a custom API to process packets then he/she
-needs to call the API **ICSS_EmacRxPktGet** in their respective
-function, this is explained with an example below.
-
-***Doing customized packet processing:***
-
-This example is taken from EtherNet/IP adapter application where some
-DLR packets are processed different from other packets using a callback.
-For this example the value of **ethPrioQueue** is set to 4 or
-*ICSS_EMAC_QUEUEPRIO4* and in this case these DLR frames have a the
-highest priority so they go to the callback function, developers need to
-set an appropriate value for **ethPrioQueue** based on their
-requirements. The callback is configured in **main** like this (taken
-from *icss_eip_driver.c*)
-
-.. code-block:: c
-
-    /*Packet processing callback*/
-    ((((ICSSEMAC_Object*)icssEmacHandle->object)->callBackHandle)->rxRTCallBack)->callBack = (ICSS_EmacCallBack)processProtocolFrames;
-    ((((ICSSEMAC_Object*)icssEmacHandle->object)->callBackHandle)->rxRTCallBack)->userArg = icssEmacHandle;
-
-Where **icssEmacHandle** is the main driver handle and
-**processProtocolFrames** is the callback function whose outline is
-given below
-
-.. code-block:: c
-
-    void processProtocolFrames(uint32_t* queue_number, void* userArg) {
-    ...
-    ...
-    uint8_t *dstMacId = tempFrame;
-    ICSSEMAC_Handle eipIcssEmacHandle = (ICSSEMAC_Handle)userArg;
-    /*Fetch the packet*/
-    size = ICSS_EmacRxPktGet(eipIcssEmacHandle,(uint32_t)tempFrame, *queue_number, &port, &more);
-    ...
-    /*Compare Destination MAC ID and determine if this is a DLR packet*/
-    if(COMPARE_MAC(dstMacId, dlrMAC)) {
-      processDLRFrame(eipIcssEmacHandle, tempFrame, port-1, size);
-    ...
-    ...
-    }
-
-As can be seen **processProtocolFrames** function calls
-**ICSS_EmacRxPktGet** internally and passes the data to
-**processDLRFrame** for further processing.
-
-Tx Data Path
-'''''''''''''''
-
-The Transmit path on host is simpler than the Rx path. As far as the
-developer is concerned the main API call is **ICSS_EmacTxPacket**. This
-API implements the Learning/FDB functionality. **ICSS_EmacTxPacket** in
-turn calls another API **ICSS_EmacTxPacketEnqueue** which performs the
-actual task of copying data from DDR to L3 and signals the PRU to
-transmit the data. **ICSS_EmacTxPacket** when called with the parameter
-*ICSS_EMAC_PORT_0* in **portNumber** field enables learning/FDB and
-calls the **ICSS_EmacTxPacketEnqueue** with the correct port number and
-when called with parameter *ICSS_EMAC_PORT_1* or *ICSS_EMAC_PORT_1* the
-API directly calls the underlying API. To avoid confusion developers
-must always call the API **ICSS_EmacTxPacket** (NOT
-[STRIKEOUT:**ICSS_EmacTxPacketEnqueue**]) with **portNumber** as
-
--  *ICSS_EMAC_PORT_0* : If they do not know the port number on which to
-   transmit.
--  *ICSS_EMAC_PORT_1* or *ICSS_EMAC_PORT_2* : If they know the port
-   number
-
-.. note::
-   Firmware automatically appends CRC to the packet on Transmit path.
-
-
-Usage
-'''''''
-
-For simple and/or non time critical applications, it makes more sense to
-use the NDK socket API's to perform Receive and Transmit operations. An
-example using NDK sockets which performs both Rx and Tx is given below.
-For in depth information on how to use sockets please consult `NDK
-User's guide <http://www.ti.com/lit/ug/spru523i/spru523i.pdf>`__ and
-`NDK API Reference
-guide <http://www.ti.com/lit/ug/spru524i/spru524i.pdf>`__.
-
-.. code-block:: c
-
-    /*Transmit to System with IP Address*/
-    #define DST_IP "192.168.1.64"
-    #define DST_PORT 7
-    /*Open file session*/
-    fdOpenSession( (HANDLE)Task_self() );
-    SOCKET s = INVALID_SOCKET;
-    struct sockaddr_in sin1;
-    struct timeval timeout;
-    /*Create UDP socket*/
-    s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
-    /*Prepare address for connect*/
-    IPN IPAddr;
-    IPAddr = inet_addr(DST_IP);
-    bzero( &sin1, sizeof(struct sockaddr_in) );
-    sin1.sin_family = AF_INET;
-    sin1.sin_addr.s_addr = IPAddr;
-    sin1.sin_port = htons(DST_PORT);
-     /*Configure our Tx and Rx timeout*/
-    timeout.tv_sec = 0;
-    timeout.tv_usec = 1;
-    setsockopt( s, SOL_SOCKET, SO_SNDTIMEO, &timeout, sizeof( timeout ) );
-    setsockopt( s, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof( timeout ) );
-    /*Transmit packet*/
-    sendto( s, pBuf, testsize, 0, (PSA)&sin1, sizeof(sin1) );
-    /*Receive packet*/
-    recv(s, pBuf, MAX_UDP_SIZE, 0);
-
-For time critical applications with low latency requirements directly
-calling the API's is recommended. For Transmit this can be done by
-populating the packet directly(or through a stack) in a memory buffer
-and calling **ICSS_EmacTxPacket** with the buffer in a task in
-**main()**. Shown below is an example of a periodic transmit being done
-in main function.
-
-.. code-block:: c
-
-    /**A dummy packet*/
-    uint8_t dummyPkt[ETHERNET_FRAME_SIZE_60] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x00,0x00,0x00,0x00,0x00,0x00,0x08,0x00,
-    0x45,0x00,0x00,0x2E,0x00,0x00,0x40,0x00,0x40,0x00,0x3A,0xD1};
-    Void taskSendPacket(UArg a0, UArg a1) {
-      /*wait for system to initialize*/
-      /*Send packet in a loop every 500ms*/
-      Task_sleep(5000);
-      while(1) {
-        /*Send packet on PORT 1*. Size is known previously/
-        ICSS_EmacTxPacket(emachandle,dummyPkt, ICSS_EMAC_PORT_1, 1, ETHERNET_FRAME_SIZE_60);
-        Task_sleep(500);
-      }
-    }
-
-For receive the application/stack can receive the packet data directly
-in **(uint32_t)dest_address** from **ICSS_EmacRxPktGet** inside
-**RxTask**. Modify the **ethPrioQueue** value as per requirement.
-(Explained above)
-
-Forwarding Rules
-'''''''''''''''''
-
-Forwarding Rules specify how packets are forwarded between ports and
-from the port to the Host. There are three basic types of forwarding
-scenarios. The image below shows all modes when receiving on first port.
-**HW Port** represents the physical port. These modes are not exclusive
-to each other and multiple modes are also allowed.
-
-Please note that EMAC can only forward to the Host, other modes only
-apply to switch.
-
--  **Cut Through** - In this mode the firmware copies the data from Rx
-   FIFO to Tx FIFO through the registers. No data is copied to the
-   queues, this is the fastest mode of transmit from one port to
-   another. Advantage is low latency, disadvantage is that CRC is not
-   checked before transmit since it lies at the end of the packet.
--  **Store & Forward** - In this mode the firmware copies the received
-   data to the transmit queues on opposite port, no data is sent to the
-   Host (Rx interrupt on Host is not asserted). CRC is checked before
-   transmit. Many protocols like PTP use this mode.
--  **Forward to Host** - Data is received in the Host receive queues and
-   an Rx interrupt is asserted to copy the data. This is the only mode
-   available for an EMAC.
-
-|
-
-.. table::  **Forwarding Rules**
-
-   +-----------------------------------+-----------------------------------+
-   | Packet Type                       | Forwarding Mode                   |
-   +===================================+===================================+
-   | Broadcast                         | Cut through & Forward to Host     |
-   +-----------------------------------+-----------------------------------+
-   | Multicast                         | Cut through & Forward to Host     |
-   |                                   | Multicast frames like PTP/DLR are |
-   |                                   | handled based on protocol         |
-   +-----------------------------------+-----------------------------------+
-   | Unicast (not to Host)             | Cut through                       |
-   +-----------------------------------+-----------------------------------+
-   | Unicast (to Host)                 | Forward to Host                   |
-   +-----------------------------------+-----------------------------------+
-
-|
-
-Interrupts and Tasks
-""""""""""""""""""""""
-
-This section deals with Interrupts and Tasks required to implement an
-EMAC LLD application. Since they are tied to the RTOS used, they are
-exported via the driver handle to the application as well as through the
-OSAL layer. Developers must take care to maintain correct priorities and
-order so as not to alter the behavior of the driver. All the interrupts
-and tasks enabled in an application can be checked using the SYSBIOS
-ROV. For more details on this tool refer to the
-`SYSBIOS <index_device_drv.html#sys-bios>`__ section of EMAC LLD Debug Guide.
-
-Interrupts
-'''''''''''
-
-There are six interrupts (eight if time triggered send is enabled) in an
-EMAC LLD coming from PRU. Other implementations like EtherNet/IP, PTP,
-Profinet etc may use their own interrupts. Please note that there are
-individual interrupts for each port because this is a dual MAC
-implementation, for an Ethernet switch like EtherNet/IP there are only
-two interrupts (no time triggered send in Switch mode).
-
-The eight interrupts are:
-
-#. Rx interrupt x 2 : One for each port, both mapping to same ISR. These
-   are used by PRU to tell ARM about the presence of a packet. For Port
-   0 this is interrupt number (ARM) 20 on AM335x and for Port 1 it is
-   21. In the mapping these are indicated by **PRU_ARM_EVENT0** and
-   **PRU_ARM_EVENT1** respectively. For ethernet switch it's just
-   **PRU_ARM_EVENT0**.
-#. Link interrupt x 2: One for each port, both mapping to same ISR.
-   These are used to indicate PHY state change to Host. For Port 0
-   interrupt number (ARM) is 26 and for Port 1 27. In mapping these are
-   indicated by **MII_LINK0_EVENT** and **MII_LINK1_EVENT** which map to
-   **CHANNEL7** and **CHANNEL8** respectively. For ethernet switch both
-   link events map to a single channel **CHANNEL7**.
-#. Tx Completion Interrupt x 2: One for each port, mapping to different
-   ISRs. These are used by PRU to tell ARM about the completion of
-   transmission of a packet. For Port 0 this is interrupt number (ARM)
-   22 on AM335x and for Port 1 it is 23. In the mapping these are
-   indicated by **PRU_ARM_EVENT2** and **PRU_ARM_EVENT3** respectively.
-#. TTS Insert Cyclic Frame Interrupt x 2: One for each port, mapping to
-   different ISRs. These are used by PRU to tell ARM that its time to
-   insert cyclic frame. For Port 0 this is interrupt number (ARM) 22 on
-   AM335x and for Port 1 it is 23. In the mapping these are indicated by
-   **PRU_ARM_EVENT4** and **PRU_ARM_EVENT5** respectively. These are
-   only applicable when TTS is enabled and initialized by the
-   application.
-
-.. note::
-   Tx Completion Interrupts and TTS Cyclic Frame Interrupts are different
-   PRU events, i.e., total 4 PRU events. But these map to the same
-   interrupt and ISR per port i.e., Tx Completion Interrupt and TTS Cyclic
-   Frame Interrupt share one ARM interrupt number and ISR for Port 1 and
-   share one ARM interrupt number and ISR for Port 2.
-
-There are two types of interrupts:
-
--  ***ICSS Interrupts*** : These are interrupts that are routed through
-   the ICSS Interrupt controller to the Host (Refer to section 4.4.2 of
-   `AM335x TRM <http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf>`__). It
-   consists of interrupts asserted by the PRU as well as interrupts
-   asserted by the peripherals (MDIO, ECAP etc) attached to the ICSS
-   Interrupt controller.
-
-The Host Interrupt controller has 8 usable interrupts mapped to the ICSS
-interrupt controller. This mapping is programmable and varies from
-example to example. Every example has a *x_pruss_intc_mapping.h* file in
-the *sdk/examples* folder where x stands for the example name. For EMAC
-this file is called *tiemac_pruss_intc_mapping.h*.
-
-***Mapping Explanation***
-
-The interrupt mapping consists of 3 parts:
-
-#. 8 PRU user interrupts (can be set in the firmware by writing to R31)
-   - represented by *PRU_ARM_EVENT0* to *PRU_ARM_EVENT7*. These are part
-   of the 64 system interrupts (out of which 32 are usable). This
-   includes the two link interrupts for two ports *MII_LINK0_EVENT* and
-   *MII_LINK1_EVENT*.
-#. 10 ICSS Host channels *CHANNEL0* to *CHANNEL9* out of which the first
-   two *CHANNEL0* and *CHANNEL1* are used internally.
-#. 8 ARM PRU interrupts represented by *PRU_EVTOUT0* to *PRU_EVTOUT7*.
-   These can also be seen in the ARM INTC in SoC TRM. Provided below is
-   a screenshot from AM335x TRM showing the 8 interrupts mapped to the
-   PRU.
-
-|
-
-|
-| The complete mapping follows the pattern
-
-::
-
-    PRU user interrupts --> Host Channels --> ARM PRU Interrupts
-
-To take an example of Rx interrupt for Port 0 (EMAC only). For switch
-this is the Rx interrupt for both ports.
-
-The following line maps PRU user interrupt 0 to Host channel 2.
-
-::
-
-    {PRU_ARM_EVENT0,CHANNEL2, SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_PULSE}
-
-Host channel *CHANNEL2* in turn maps to the first ARM interrupt
-*PRU_ICSS_EVTOUT_0* through this line.
-
-::
-
-    {CHANNEL2, PRU_EVTOUT0}
-
-As seen from the screenshot the interrupt number for *PRU_ICSS_EVTOUT_0*
-on AM335x is *20*, so the interrupt number that must be configured for
-this in application should be 20 if the platform is AM335x. This is done
-in the following line (defined in *main.c*)
-
-::
-
-    switchEmacCfg->rxIntNum = 20;
-
-This mapping alone determines which ARM interrupt number will be
-associated with a particular PRU user interrupt. For example the line
-above where PRU user interrupt 0 maps to Host channel 2 can be modified
-to
-
-::
-
-    {PRU_ARM_EVENT0,CHANNEL2, SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_PULSE} ---> {PRU_ARM_EVENT0,CHANNEL4, SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_PULSE}
-
-and the Channel to ARM interrupt map can be configured as, and the
-interrupt number on ARM would still remain the same i.e. 20
-
-::
-
-    {CHANNEL2, PRU_EVTOUT0} --->  {CHANNEL4, PRU_EVTOUT0}
-
-A question arises in this case as to the usefulness of *CHANNELx*. The
-answer is that channels allow us to map multiple PRU User interrupts and
-system interrupts to a single channel and in turn to a single ARM
-interrupt. For example take a look at the link interrupt mapping
-
-::
-
-    {MII_LINK0_EVENT, CHANNEL7, SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_PULSE},    \
-    {MII_LINK1_EVENT, CHANNEL7, SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_PULSE}, \
-
-and
-
-::
-
-    {CHANNEL7, PRU_EVTOUT6}
-
-This configuration maps both Port 0 and Port 1 interrupts to a single
-channel and in turn to a single ARM interrupt *PRU_ICSS_EVTOUT6*, which
-is interrupt number 26 (shown by the line below in *main.c*)
-
-::
-
-    switchEmacCfg->linkIntNum=26;
-
-The link interrupt binds to a single ISR **ICSS_EmacLinkISR** on Host.
-Inside the ISR an ICSS register **HW_ICSS_INTC_SECR1**\ is checked to
-find out which link event *MII_LINK0_EVENT* or *MII_LINK1_EVENT*
-asserted the interrupt. The advantage of such an approach is that both
-interrupts are serviced even if they are raised at the same time.
-
-These interrupt numbers can change from SoC to SoC so please consult TRM
-before making any modifications to the interrupt map. This is also one
-of the reasons for exporting these configurations to application so that
-a single driver can handle multiple SoC's others being ease of use,
-porting other operating systems etc.
-
-|
-
-.. table::  PRU Interrupt Mapping in EMAC
-
-   +-----------------+-----------------+-----------------+-----------------+
-   | PRU Interrupt   | Channel Number  | Host Interrupt  | ISR             |
-   | Number          |                 | Number          |                 |
-   +=================+=================+=================+=================+
-   | PRU_ARM_EVENT0  | CHANNEL2        | 20              | *ICSS_EmacRxInt |
-   | Port 0 RX       |                 |                 | erruptHandler*  |
-   | Interrupt       |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | PRU_ARM_EVENT1  | CHANNEL3        | 21              | *ICSS_EmacRxInt |
-   | Port 1 RX       |                 |                 | erruptHandler*  |
-   | Interrupt       |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | PRU_ARM_EVENT2  | CHANNEL4        | 22              | *ICSS_EmacTxInt |
-   | Port 0 TX       |                 |                 | erruptHandlerPo |
-   | Completion      |                 |                 | rt1*            |
-   | Interrupt       |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | PRU_ARM_EVENT3  | CHANNEL5        | 23              | *ICSS_EmacTxInt |
-   | Port 1 TX       |                 |                 | erruptHandlerPo |
-   | Completion      |                 |                 | rt2*            |
-   | Interrupt       |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | PRU_ARM_EVENT4  | CHANNEL4        | 22              | *ICSS_EmacTxInt |
-   | Port 0 TTS      |                 |                 | erruptHandlerPo |
-   | Insert Cyclic   |                 |                 | rt1*            |
-   | Frame Interrupt |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | PRU_ARM_EVENT5  | CHANNEL5        | 23              | *ICSS_EmacTxInt |
-   | Port 1 TTS      |                 |                 | erruptHandlerPo |
-   | Insert Cyclic   |                 |                 | rt2*            |
-   | Frame Interrupt |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | MII_LINK0_EVENT | CHANNEL7        | 26              | *ICSS_EmacLinkI |
-   | Port 0 Link     |                 |                 | SR*             |
-   | Interrupt       |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-   | MII_LINK1_EVENT | CHANNEL8        | 27              | *ICSS_EmacLinkI |
-   | Port 1 Link     |                 |                 | SR*             |
-   | Interrupt       |                 |                 |                 |
-   +-----------------+-----------------+-----------------+-----------------+
-
-|
-
--  ***Host Interrupts*** : Host interrupts are interrupts that are not
-   coming via ICSS Interrupt controller. These include peripherals,
-   EDMA, timers etc. A full list is present inside the Interrupt section
-   of any TRM. On AM335x a total of 128 interrupts are available through
-   this (including 8 PRU ICSS interrupts). Discussion of Host interrupts
-   is beyond the scope of this guide as we only deal with the EMAC LLD
-   driver here.
-
-Some examples of Host interrupts used in the driver are DMTimer
-interrupts and EDMA interrupts which are available through the OSAL
-layer *osdrv_edma.c* and *osdrv_osal.c*
-
-Interrupt Pacing
-'''''''''''''''''
-
-When packets are sent to the Host at a very high rate (this happens more
-often with small frames) it's possible that ARM is interrupted
-frequently by the PRU's, this results in packets getting dropped as the
-host is unable to empty the queues in time because of context switching.
-Interrupt pacing is a scheme used to cope with this situation. In this
-scheme interrupts are disabled when the first Rx interrupt is received
-(The PRU still keeps receiving the frames and putting them on the
-queues), after a certain number of packets have been processed on the
-Host, the interrupts are enabled once more. Since interrupts on PRU have
-not been disabled any pending packets will assert the interrupt again,
-this ensures that no packets are missed. The advantage of pacing is that
-a greater throughput is achieved while disadvantage is that if any
-critical packets need to be serviced immediately, it's possible that
-some delay may occur. Pacing is enabled in the driver using the variable
-**intrPacingMode**. There are two pacing modes in driver.
-
--  **INTR_PACING_MODE1** : This is entirely ARM based, i.e. interrupts
-   are disabled only on the Host. This does not require any firmware
-   support. This is the scheme supported with Ethernet MAC and Ethernet
-   IP Adapter.
--  **INTR_PACING_MODE1** : In this scheme interrupts are disabled on the
-   PRU. This requires firmware support. Only supported in Profinet right
-   now.
-
-Tasks
-''''''
-
-Tasks are the Linux equivalent of processes in SysBIOS. A simple example
-to create a task from EMAC application is given below
-
-.. code-block:: c
-
-     Task_Params_init(&taskParams);
-     taskParams.priority = 15;
-     taskParams.instance->name = "SwitchTask";
-     Task_create(taskPruss, &taskParams, &eb);
-
-Here **taskPruss** is given the job of initializing the PRU's and
-loading the firmware onto them. The task itself is a simple function
-with two arguments
-
-::
-
-    /*
-     *  ---task to initialize PRU---
-     */
-    Void taskPruss(UArg a0, UArg a1)
-    {
-      ...
-      ...
-      ...
-    }
-
-They can be used for simple tasks like sending or receiving a packet. To
-get an idea `refer <index_device_drv.html#usage>`__
-to the example usage for sending a packet through a call to transmit API
-**ICSS_EmacTxPacket** in a loop. If calling the task in an endless while
-loop developers must add a small delay inside the loop using
-*Task_sleep(time in milliseconds)* to let other tasks get some time as
-well, failure to do so is a common mistake that developers make.
-
-Learning/FDB
-"""""""""""""
-
-Learning/FDB where FDB stands for Forwarding Data Base is a module that
-learns source MAC addresses of packets addressed to the Host and thus
-maintains a list of which devices reside on which port. While
-transmitting a packet when provided with the destination MAC address the
-module returns the port number on which the device resides. This avoids
-duplication of traffic on both ports. This module is applicable only in
-Switch mode, in EMAC mode this module is disabled since there is only
-one port.
-
-Design
-''''''''
-
-Learning table is currently implemented as a Hash table. There is one
-table for each physical port. Each table has 256 buckets where a bucket
-has a size of 4. The bucket size and number of buckets are in turn
-dictated by the choice of Hashing algorithm. A detailed discussion on
-this topic is beyond the scope of this document, suffice to say that
-theoretically a hash table is capable of learning 256 \* 4 = 1024
-entries. The actual capacity may be lower owing to collisions.
-
-A single bucket has
-
--  Four entries - For storing four MAC Id's
--  Four ageing counters - One associated with each entry
--  Number of Entries - A value which tells how many entries are there in
-   the bucket.
-
-A single table has
-
--  256 buckets
--  Total number of entries - Sum of entries in all the buckets
--  Port State - A table has three states
-
-   -  Learning - This is the default state. All actions are permitted
-   -  Not Learning - No new addresses are learnt. Deletions possible.
-   -  Locked - No additions/deletions allowed
-
-Collisions are handled using ageing counters, one ageing counter is
-associated with each of the 4 entries inside a bucket. It tells the
-module which entries are old and which ones are new.
-
-API Guide & Data Structures
-'''''''''''''''''''''''''''''
-
-A learning table has the following structure
-
-.. code-block:: c
-
-    typedef struct HashTable_t{
-
-     uint32_t totalNumEntries;        /**Total number of entries in the hash table*/
-     portState state;             /**State of the hash table, see enum portState above*/
-     HashBucket_t  entries[NUMBUCKETS];  /**Number of bucket entries*/
-
-    } HashTable_t;
-
-The individual bucket which makes up the learning table has the
-following structure
-
-.. code-block:: c
-
-    typedef struct {
-
-     MAC mac[MAX_NUM_ENTRIES];            /**Four MAC Id per bucket*/
-     uint8_t timerCount[MAX_NUM_ENTRIES]; /**Timer count used for ageing and conflict resolution*/
-     uint8_t numEntries;                  /**Number of MAC entries in the bucket, 4 means it is full*/
-
-    } HashBucket_t;
-
-The default values are
-
--  NUMBUCKETS 256
--  MAX_NUM_ENTRIES 4
-
-The algorithm assumes these values and they cannot be changed at
-present.
-
-API descriptions are only for information, developers are requested to
-use corresponding `IOCTL <index_device_drv.html#ioctl>`__
-calls. The IOCTL command for Learning/FDB modules is
-***ICSS_EMAC_IOCTL_LEARNING_CTRL***
-
-***Adding A MAC address*** : The corresponding API for this is
-
-::
-
-    void updateHashTable(uint8_t* macId, uint8_t portNum, HashTable_t *tablePtr,ICSSEMAC_CallBackConfig* exceptionCallBack)
-
-The API is integrated inside **ICSS_EmacRxPktGet** so developer need not
-call it separately, if at all it is required please use the IOCTL call
-for this. IOCTL Param value is *ICSS_EMAC_LEARN_CTRL_UPDATE_TABLE*
-
-***Looking up an Entry*** : The corresponding API for this is
-
-::
-
-    uint8_t findMAC(const uint8_t * macId, HashTable_t *tablePtr)
-
-Integrated with driver inside **ICSS_EmacTxPacket**, use IOCTL Param
-value *ICSS_EMAC_LEARN_CTRL_FIND_MAC*
-
-***Removing a MAC address*** : The corresponding API for this is
-
-::
-
-    uint8_t removeMAC(uint8_t * macId, HashTable_t *tablePtr)
-
-Entries are removed automatically upon ageing, if forced removal is
-required use IOCTL Param value *ICSS_EMAC_LEARN_CTRL_REMOVE_MAC*
-
-***Ageing an Entry*** : The driver already implements this inside the
-periodic task which is called every 100 NDK Ticks ***\_HwPktPoll()***
-but users can call it as well. IOCTL Param value
-*ICSS_EMAC_LEARN_CTRL_INC_COUNTER*
-
-The corresponding API for this is
-
-::
-
-    void incrementCounter(HashTable_t *tablePtr)
-
-***Removing an Aged Entry*** : The corresponding API for this is
-
-::
-
-    void ageingRoutine(uint8_t portNum, HashTable_t *tablePtr)
-
-Integrated with driver. IOCTL Param value *ICSS_EMAC_LEARN_CTRL_AGEING*
-
-***Changing Port State*** : Change the port state to appropriate value.
-This is useful in the implementation of requirements specified by IEEE
-802.1D.
-
-The corresponding API for this is
-
-::
-
-    void changePortState(portState state, HashTable_t *tablePtr)
-
-As part of changing port state the module implements locking of a port
-(where addition/deletion of entries is not possible), ageing (age the
-entries to simulate passage of time). Not integrated with driver,
-application must do it. IOCTL Param value
-*ICSS_EMAC_LEARN_CTRL_SET_PORTSTATE*
-
-***Flushing/Clearing the entire Table*** : The corresponding API for
-this is
-
-::
-
-    void purgeTable(uint8_t portNum, HashTable_t *tablePtr)
-
-Not integrated with driver, call separately using IOCTL Param value
-*ICSS_EMAC_LEARN_CTRL_CLR_TABLE*
-
-Usage
-'''''''
-
-The module is integrated with the driver so a developer need not bother
-about calling the API's separately in the application unless there is a
-specific need to
-
--  Add a MAC ID
--  Remove a MAC ID
--  Lock the Port or change it's state
-
-The ageing module is called inside **\_HwPktPoll** (which is a periodic
-NDK task, more info in the porting guide) via an IOCTL call, to age
-faster please call the routine separately in another task. Changing the
-time period of **\_HwPktPoll** is not recommended as many other tasks
-are performed in this.
-
-Storm Control
-"""""""""""""""
-
-Strom control or Storm prevention is a feature that limits the number of
-broadcast and multicast packets going to the host and/or cutting through
-to the other port. Since broadcast and multicast packets are sent over
-all the ports of a switch they have the potential to create a storm
-which drowns all other traffic on the network, in this regard this is a
-very important feature for the switch.
-
-Design
-'''''''
-
-Storm prevention is implemented on the two PRU's as a credit based
-scheme. When the feature is enabled, every time a multicast or broadcast
-packet is received a counter referred to as storm prevention credits is
-decremented and the packet is sent to the host as well as cut through.
-If the counter value is 0 then the packet is dropped. The counter is
-stored on respective PRU DMEM's and is reset after a fixed period by the
-Host. The combination of this period and credit value decides the rate
-of acceptance/rejection.
-
-The mechanism is shown below in the diagram
-
-.. Image:: /images/Storm_Prevention_architecture_Industrial.jpeg
-
-The Storm prevention implementation is similar in both PRU's but
-implemented separately, so it's possible to turn it off selectively for
-each port. As of now the multicast and broadcast storm prevention
-functionalities are clubbed together but it is proposed to have them
-separate in the future.
-
-API Guide & Data Structures
-''''''''''''''''''''''''''''
-
-The main parent structure for Storm Prevention is
-
-.. code-block:: c
-
-    typedef struct {
-
-     uint8_t suppressionEnabled;   /** enable/disable storm prevention*/
-     uint16_t credits;             /** Number of packets allowed in a time interval*/
-
-    } stormPrevention_t;
-
-There is an instance of this structure for each port
-
-API descriptions are only for information, developers are requested to
-use corresponding `IOCTL <index_device_drv.html#ioctl>`__
-calls. The IOCTL command for Learning/FDB modules is
-***ICSS_EMAC_IOCTL_STORM_PREV_CTRL***
-
-***Enabling Storm Prevention***  : The corresponding API for this is
-
-.. code-block:: c
-
-    void ICSS_EmacEnableStormPrevention(uint8_t portnum, ICSSEMAC_Handle icssEmacHandle)
-
-Corresponding IOCTL Param value is *ICSS_EMAC_STORM_PREV_CTRL_ENABLE*
-
-***Disabling Storm Prevention*** : Similar to enablement, variable set
-to False. The corresponding API for this is
-
-::
-
-    void ICSS_EmacDisableStormPrevention(uint8_t portnum, ICSSEMAC_Handle icssEmacHandle)
-
-IOCTL Param value is *ICSS_EMAC_STORM_PREV_CTRL_DISABLE*
-
-***Resetting the counters*** : This is called inside **\_HwPktPoll**
-which is the NDK tick function. The time period of this tick function
-(default 100ms) in combination with **credits** value decides the rate
-at which Storm Prevention works. This is called by default inside the
-driver.
-
-The corresponding API for this is
-
-::
-
-    void ICSS_EmacResetStormPreventionCounter(ICSSEMAC_Handle icssEmacHandle)
-
-IOCTL Param value is *ICSS_EMAC_STORM_PREV_CTRL_RESET*
-
-***Changing the rate*** : To change how many packets are accepted or
-rejected change the value in the structure. At every iteration these
-values are written to the data RAM by the
-**ICSS_EmacResetStormPreventionCounter** API. The scheme through which
-this occurs is explained in the design description above
-
-The corresponding API for this is
-
-::
-
-    void setCreditValue(uint16_t creditValue, stormPrevention_t* stormPrevPtr)
-
-IOCTL Param value is *ICSS_EMAC_STORM_PREV_CTRL_SET_CREDITS*
-
-Usage
-''''''
-
-Most often Storm Prevention is the main reason for users not being able
-to receive a packet, esp if the rate is configured incorrectly. So first
-verify if it is enabled for that port. This can be done by
-
--  Checking structure variable : See the value of **suppressionEnabled**
-   variable in the structure.
--  Checking memory : See the memory offset STORM_PREVENTION_OFFSET in
-   the corresponding data RAM. The first bit of the byte location tells
-   you whether the logic is enabled on the port.
--  Disabling Storm Prevention : This is the easiest and preferable for
-   someone not using an emulator. Use the corresponding IOCTL call.
-
-To quickly verify if the logic is indeed dropping packets, try sending
-some broadcast packets at line rate to the device and check the value of
-PRU statistics variable **stormPrevCounter**. See statistics section on
-how to read this variable.
-
-Statistics
-""""""""""""
-
-Statistics on ICSS Switch provide a great deal of information on what's
-going on with the switch. They are enabled by default and provide
-provide port specific statistics. They are also a great debugging tool
-and should be the first thing a developer should look at if they suspect
-any issue with Rx or Tx.
-
-Design
-''''''''
-
-The Statistics are divided into
-
--  ***Statistics on PRU*** : Since the LLD functionality is implemented
-   on the PRU's the majority of statistics are implemented on them. The
-   count for each port is stored on the respective Data RAM's starting
-   at the offset STATISTICS_OFFSET. The map is shown below
--  ***Statistics on Host*** : The packets coming to the Host are counted
-   once again, this is useful for debugging purposes and to measure
-   throughput (from the PRU to Host) if required. Some statistics like
-   "Unknown protocol type" are only implemented on the Host.
-
-Functionally the statistics are classified into
-
--  ***Rx/Tx related statistics*** : This includes count of broadcast,
-   multicast and unicast packets and their derivatives. Only valid
-   packets are part of this which means that an Rx packet which has been
-   dropped because of storm prevention will not be counted.
--  ***Error Counters*** : This includes statistics such as Dropped
-   frames, Rx/Tx errors etc.
--  ***Other statistics*** : Includes statistics related to 802.1
-   CSMA/CD, number of link breaks etc.
-
-A description of PRU statistics along with corresponding memory map is
-given below.
-
-align="center"
-***PRU Statistics Description & Memory Map***
-Name of Variable
-
-Description
-
-Name of Offset
-
-Refer to *icss_emacSwitch.h*
-
-Offset in PRU DRAM 0/1
-
-**txBcast**
-
-Number of broadcast packets sent
-
-*TX_BC_FRAMES_OFFSET*
-
-*0x1F00*
-
-**txMcast**
-
-Number of multicast packets sent
-
-*TX_MC_FRAMES_OFFSET*
-
-*0x1F04*
-
-**txUcast**
-
-Number of unicast packets sent
-
-*TX_UC_FRAMES_OFFSET*
-
-*0x1F08*
-
-**txOctets**
-
-Total number of octets sent, includes all packets
-
-*TX_BYTE_CNT_OFFSET*
-
-*0x1F0C*
-
-**rxBcast**
-
-Number of broadcast packets received
-
-*RX_BC_FRAMES_OFFSET*
-
-*0x1F10*
-
-**rxMcast**
-
-Number of multicast packets received
-
-*RX_MC_FRAMES_OFFSET*
-
-*0x1F14*
-
-**rxUcast**
-
-Number of unicast packets received
-
-*RX_UC_FRAMES_OFFSET*
-
-*0x1F18*
-
-**rxOctets**
-
-Total number of octets received, includes all packets
-
-*RX_BYTE_CNT_OFFSET*
-
-*0x1F1C*
-
-**lateColl**
-
-Number of packets that suffered collisions late into Tx
-
-*LATE_COLLISION_OFFSET*
-
-*0x1F20*
-
-**singleColl**
-
-Number of packets that suffered collision only once
-
-*SINGLE_COLLISION_OFFSET*
-
-*0x1F24*
-
-**multiColl**
-
-Number of packets that suffered collisions more than once
-
-*MULTIPLE_COLLISION_OFFSET*
-
-*0x1F28*
-
-**excessColl**
-
-Number of packets that suffered collisions more than 15 times
-
-*EXCESS_COLLISION_OFFSET*
-
-*0x1F2C*
-
-**txOverFlow**
-
-Number of times Tx queue overflowed
-
-(This is not supported right now)
-
-*TX_OVERFLOW_OFFSET*
-
-*0x1F30*
-
-**rxMisAlignmentFrames**
-
-Number of frames with uneven number of bytes in an octet
-
-(This is not tested)
-
-*RX_MISALIGNMENT_COUNT_OFFSET*
-
-*0x1F34*
-
-**stormPrevCounter**
-
-Number of packets dropped due to storm prevention
-
-*STORM_PREVENTION_COUNTER*
-
-*0x1F38*
-
-**macRxError**
-
-Number of packets with Rx MAC Error
-
-*RX_ERROR_OFFSET*
-
-*0x1F3C*
-
-**SFDError**
-
-Number of packets with incorrect SFD
-
-*SFD_ERROR_OFFSET*
-
-*0x1F40*
-
-**defTx**
-
-Number of packets deferred at least once due to CS high signal
-
-*TX_DEFERRED_OFFSET*
-
-*0x1F44*
-
-**macTxError**
-
-Number of packets facing Tx MAC Error
-
-*TX_ERROR_OFFSET*
-
-*0x1F48*
-
-**rxOverSizedFrames**
-
-Number of packets >1518 bytes
-
-*RX_OVERSIZED_FRAME_OFFSET*
-
-*0x1F4C*
-
-**rxUnderSizedFrames**
-
-Number of packets < 60 bytes
-
-*RX_UNDERSIZED_FRAME_OFFSET*
-
-*0x1F50*
-
-**rxCRCFrames**
-
-Frames with CRC/FCS Error
-
-*RX_CRC_COUNT_OFFSET*
-
-*0x1F54*
-
-**droppedPackets**
-
-Number of Received packets that were not transmitted because of link
-loss
-
-*RX_DROPPED_FRAMES_OFFSET*
-
-*0x1F5C*
-
-**tx64byte**
-
-Transmitted frames with size <= 64 bytes
-
-*TX_64_BYTE_FRAME_OFFSET*
-
-*0x1F60*
-
-**tx65_127byte**
-
-Transmitted frames with size >= 65 bytes and <= 127 bytes
-
-*TX_65_127_BYTE_FRAME_OFFSET*
-
-*0x1F64*
-
-**tx128_255byte**
-
-Transmitted frames with size >= 128 bytes and <= 255 bytes
-
-*TX_128_255_BYTE_FRAME_OFFSET*
-
-*0x1F6C*
-
-**tx256_511byte**
-
-Transmitted frames with size >= 256 bytes and <= 511 bytes
-
-*TX_256_511_BYTE_FRAME_OFFSET*
-
-*0x1F70*
-
-**tx512_1023byte**
-
-Transmitted frames with size >= 512 bytes and <= 1023 bytes
-
-*TX_512_1023_BYTE_FRAME_OFFSET*
-
-*0x1F74*
-
-**rx64byte**
-
-Received frames with size <= 64 bytes
-
-*RX_64_BYTE_FRAME_OFFSET*
-
-*0x1F78*
-
-**rx65_127byte**
-
-Received frames with size >= 65 bytes and <= 127 bytes
-
-*RX_65_127_BYTE_FRAME_OFFSET*
-
-*0x1F7C*
-
-**rx128_255byte**
-
-Received frames with size >= 128 bytes and <= 255 bytes
-
-*RX_128_255_BYTE_FRAME_OFFSET*
-
-*0x1F80*
-
-**rx256_511byte**
-
-Received frames with size >= 256 bytes and <= 511 bytes
-
-*RX_256_511_BYTE_FRAME_OFFSET*
-
-*0x1F84*
-
-**rx512_1023byte**
-
-Received frames with size >= 512 bytes and <= 1023 bytes
-
-*RX_512_1023_BYTE_FRAME_OFFSET*
-
-*0x1F88*
-
-API Guide & Data Structures
-''''''''''''''''''''''''''''
-
-As discussed above there are two data structures for Statistics.
-
-#. PRU based
-#. On Host
-
-Shown below are the members of Host Statistics. The members of PRU
-statistics are listed in the memory map.
-
-.. code-block:: c
-
-    typedef struct {
-
-     volatile uint32_t txUcast;         /**Number of unicast packets sent*/
-     volatile uint32_t txBcast;         /**Number of broadcast packets sent*/
-     volatile uint32_t txMcast;         /**Number of multicast packets sent*/
-     volatile uint32_t txOctets;            /**Number of bytes sent*/
-     volatile uint32_t rxUcast;         /**Number of unicast packets rcvd*/
-     volatile uint32_t rxBcast;         /**Number of broadcast packets rcvd*/
-     volatile uint32_t rxMcast;         /**Number of multicast packets rcvd*/
-     volatile uint32_t rxOctets;            /**Number of Rx packets*/
-     volatile uint32_t rxUnknownProtocol;           /**Number of packets with unknown protocol*/
-     volatile uint32_t linkBreak;           /**Number of link breaks*/
-
-    }hostStatistics_t;
-
-As one can see most of the members are identical to that of PRU
-statistics (they are a subset) and if all packets are sent to the Host
-then these member values for PRU and Host statistics should match.
-
-API descriptions are only for information, developers are requested to
-use corresponding `IOCTL <index_device_drv.html#ioctl>`__
-calls. The IOCTL command for Statistics module is
-***ICSS_EMAC_IOCTL_STATS_CTRL***
-
-***Reading PRU Statistics***  : To fetch PRU statistics an M2M copy is
-done from the PRU Data RAM to the PRU statistics structure on DDR. To
-get the values correctly the memory layout on both sides should be
-identical. Developers should not modify the member order in
-**pruStatistics_t. Doing so can give incorrect results**
-
-Host statistics are updated on the fly in the structure as packets are
-received (ICSS_EmacUpdateRxStats) or transmitted
-(ICSS_EmacUpdateTxStats) so there is no separate API to collate
-them.
-
-The corresponding API for this is
-
-::
-
-    void ICSS_EmacReadStats(uint8_t portNum, ICSSEMAC_Handle icssEmacHandle)
-
-IOCTL Param value is *ICSS_EMAC_IOCTL_STAT_CTRL_GET*
-
-***Clearing PRU and Host Statistics***  : To clear the values do memory
-write to the structure memory, PRU data RAM and initialize to 0.
-
-The corresponding API for this is
-
-::
-
-    void PurgeStats(uint8_t portNum, ICSSEMAC_Handle icssEmacHandle)
-
-IOCTL Param value is *ICSS_EMAC_IOCTL_STAT_CTRL_CLEAR*
-
-Usage
-''''''''
-
-Statistics are a great tool to debug issues on the switch. To get them
-in the application use the IOCTL calls to get and clear statistics
-
-While IOCTL calls provide access to statistics in the application. If
-someone is using CCS then another quick way to see if there is any
-activity on the Ports is to directly go to the PRU data RAM offset
-*STATISTICS_OFFSET* and see the values directly in memory Refer Debug
-guide on how to see data RAM values directly in CCS.
-
-Memory Map
-^^^^^^^^^^^
-
-The memory map here refers to the Shared Data RAM memory map in ICSS. L3
-map is not of much use to the developer while DDR map is dynamic and is
-part of the application. The goal of providing this is to help the
-developer in debugging. Based on the memory map one can directly look at
-the memory in a CCS + Emulator environment and verify if driver/firmware
-is working correctly.
-
-The memory map can be found in *icss_emacSwitch.h* under
-*os_drivers/lld/emac* and is common to firmware and driver builds
-
-.. table::  ***ICSS Shared Memory Map***
-
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   | Shared    | Value     | PRU0 Data | Value     | PRU1 Data | Value     |
-   | Memory    |           | RAM       |           | RAM       |           |
-   | Offset    |           |           |           |           |           |
-   +===========+===========+===========+===========+===========+===========+
-   | 0x0000 -  | Buffer    | 0x0000 -  | Reserved  | 0x0000 -  | Reserved  |
-   | 0x1C10    | Descripto | 0x0400    | for       | 0x0400    | for       |
-   |           | r         |           | Future    |           | Future    |
-   |           | Offsets   |           | Use       |           | Use       |
-   |           | For Host  |           |           |           |           |
-   |           | Queues    |           |           |           |           |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   | 0x1C10-0x | Multicast | 0x0400-0x | Available | 0x0400-0x | Available |
-   | 2010      | Filtering | 1EC0      | for       | 1EC0      | for       |
-   |           | Table     |           | Protocol/ |           | Protocol/ |
-   |           | (Disabled |           | Applicati |           | Applicati |
-   |           | for EMAC) |           | on        |           | on        |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   | 0x2010-0x | Reserved  | 0x1EC0-0x | Port      | 0x1EC0-0x | Port      |
-   | 2400      | for       | 1F00      | Queue     | 1F00      | Queue     |
-   |           | Future    |           | Offsets   |           | Offsets   |
-   |           | Use       |           |           |           |           |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   | 0x2400-0x | Available | 0x1F00-0x | Port0     | 0x1F00-0x | Port1     |
-   | 3000      | for       | 1F8C      | Statistic | 1F8C      | Statistic |
-   |           | Protocol/ |           | s         |           | s         |
-   |           | Applicati |           | (Map      |           | (Map      |
-   |           | on        |           | provided  |           | provided  |
-   |           |           |           | `above <h |           | `above <h |
-   |           |           |           | ttp://pro |           | ttp://pro |
-   |           |           |           | cessors.w |           | cessors.w |
-   |           |           |           | iki.ti.co |           | iki.ti.co |
-   |           |           |           | m/index.p |           | m/index.p |
-   |           |           |           | hp/ICSS_E |           | hp/ICSS_E |
-   |           |           |           | MAC_LLD_d |           | MAC_LLD_d |
-   |           |           |           | evelopers |           | evelopers |
-   |           |           |           | _guide#De |           | _guide#De |
-   |           |           |           | sign_3>`_ |           | sign_3>`_ |
-   |           |           |           | _)        |           | _)        |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   |           |           | 0x1F8C    | Port0     | 0x1F8C    | Port1     |
-   |           |           |           | Storm     |           | Storm     |
-   |           |           |           | Preventio |           | Preventio |
-   |           |           |           | n         |           | n         |
-   |           |           |           | Control   |           | Control   |
-   |           |           |           | Variable  |           | Variable  |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   |           |           | 0x1F90    | Port0     | 0x1F90    | Port1     |
-   |           |           |           | Link      |           | Link      |
-   |           |           |           | Speed     |           | Speed     |
-   |           |           |           | 0x64 -    |           | Same as   |
-   |           |           |           | 100Mbps   |           | Port0     |
-   |           |           |           |           |           |           |
-   |           |           |           | 0xA -     |           | Any other |
-   |           |           |           | 10Mbps    |           | value is  |
-   |           |           |           |           |           | illegal   |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   |           |           | 0x1F94    | Port0     | 0x1F94    | Port1     |
-   |           |           |           | Link      |           | Link      |
-   |           |           |           | Status    |           | Status    |
-   |           |           |           | 0x1 -     |           | Same as   |
-   |           |           |           | Link Up   |           | Port0     |
-   |           |           |           |           |           |           |
-   |           |           |           | 0x0 -     |           |           |
-   |           |           |           | Link Down |           |           |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   |           |           | 0x1F9A    | Port0     | 0x1F9A    | Port1     |
-   |           |           |           | Control   |           | Control   |
-   |           |           |           | 0x1 - Rx  |           | Same as   |
-   |           |           |           | Disabled  |           | Port0     |
-   |           |           |           |           |           |           |
-   |           |           |           | 0x0 - Rx  |           |           |
-   |           |           |           | Enabled   |           |           |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-   |           |           | 0x1FA0    | Port0 MAC | 0x1FA0    | Port1 MAC |
-   |           |           |           | ID        |           | ID        |
-   |           |           |           | 6 bytes   |           | 6 bytes   |
-   +-----------+-----------+-----------+-----------+-----------+-----------+
-
-
-OS and TCP/IP
-^^^^^^^^^^^^^^^
-
-RTOS
-"""""
-
-The SDK uses
-`SYS/BIOS <http://processors.wiki.ti.com/index.php/Category:SYSBIOS>`__
-as it's RTOS. Configuration for the RTOS is done through RTSC tool chain
-integrated with CCS. SYS/BIOS is provided free of cost and is a very
-capable RTOS for typical use cases with minimal latency.
-
-The driver is written in a manner such that there is very little
-dependency on the Operating System. All dependence on SYS/BIOS is
-abstracted to OSAL (Operating System Abstraction Layer) and developers
-are integrate their own operating systems.
-
-OSAL consists of
-
-#. Interrupt management
-#. Task and Semaphore management, Mailbox
-#. Management of peripherals like DMTimer, BIOS Timers
-
-The *osdrv* layer deals with RTOS and other OS related tasks in general,
-within this layer the relevant files which deal with OSAL layer are
-***osdrv_osal.c*** and ***osdrv_osal.h***. Developers are requested to
-port the API's within these two files to their own Operating System.
-
-
-TCP/IP
-""""""""
-
-The Industrial SDK uses `NDK <http://www.ti.com/tool/NDKTCPIP>`__ as
-it's TCP/IP stack. API reference guide
-`here <http://www.ti.com/lit/ug/spru524i/spru524i.pdf>`__. Like SYS/BIOS
-the module is imported externally through RTSC (refer Debug Guide) and
-managed through the application configuration file (***am335x_app.cfg***
-and ***am437x_app.cfg***)
-
-NDK recommends it's own abstraction layer which is called NIMU (Network
-Interface Management Unit). This layer is implemented in the driver.
-Relevant source files are
-
--  *icss_ethdriver.c*
--  *icss_nimu_eth.c*
--  *icss_switch_emac.c*
-
-Understanding the NIMU layer helps in porting another TCP/IP stack to
-the example. The NIMU layer is explained in this
-`guide <http://www.ti.com/lit/ug/sprufp2a/sprufp2a.pdf>`__
-
-`Porting
-guide <http://processors.wiki.ti.com/index.php/ICSS_EMAC_LLD_developers_guide#Porting_ICSS_EMAC_LLD>`__
-covers all aspects of using a custom TCP/IP stack to the EMAC LLD
-example.
-
-PRUSS & EMAC Handle
-^^^^^^^^^^^^^^^^^^^^
-
-The ICSS EMAC Handle is a main driver handle which provides access to
-all members, variables, registers and addresses in the SoC.
-
-It is the application's task to allocate memory for the handle and pass
-it to the driver initialization API. The handle is also required as a
-parameter for most of the external API's and all IOCTL calls in the
-driver so it's important to understand it's members.
-
-The members of the EMAC Handle are discussed in detail
-`here <http://processors.wiki.ti.com/index.php?title=SYSBIOS_Industrial_SDK_Migration_guide_from_1.1_to_2.1#ICSS_EMAC_LLD>`__
-
-The sample code for Handle allocation and initialization (from the
-example application) is shown below
-
-.. code-block:: c
-
-    /*Declare the EMAC Handle*/
-    ICSSEMAC_Handle emachandle;
-    /*Declare the PRUSS Handle*/
-    PRUICSS_Handle handle;
-    /*Allocate memory for EMAC and PRUSS Handle*/
-    handle = (PRUICSS_Handle)malloc(sizeof(PRUICSS_Config));
-    handle->object = (PRUICSS_V1_Object*)malloc(sizeof(PRUICSS_V1_Object));
-    handle->hwAttrs = (PRUICSS_HwAttrs*)malloc(sizeof(PRUICSS_HwAttrs));
-    emachandle = (ICSSEMAC_Handle)malloc(sizeof(ICSSEMAC_Config));
-    /*Initialize the EMAC*/
-    ICSSEmacDRVInit(emachandle, 0);
-    /*Initialize PRUSS*/
-    PRUSSDRVInit(handle); /* ICSS_M instance 0 */
-    /*Assign PRU handle to EMAC handle making it the parent structure*/
-    ((ICSSEMAC_Object*)emachandle->object)->pruIcssHandle = handle;
-    ((ICSSEMAC_Object*)emachandle->object)->emacInitcfg = switchEmacCfg;
-
-IOCTL
-^^^^^^^
-
-IOCTL implementation for the switch drivers is identical to the
-Unix/Linux based IOCTL calls. They provide the application a convenient
-method to access driver/kernel space parameters or modify them.
-
-Developers are expected to familiarize themselves with the full list of
-IOCTL calls so that they can utilize all the features provided. This is
-even more important when working in an Application/OS kind of
-environment where access to an emulator is not available.
-
-Design
-"""""""
-
-The primary IOCTL call is through the API **ICSS_EmacIoctl** which is
-implemented in the file icss_emacFwInit.c An IOCTL call uses two
-parameters to find out which driver API to call
-
-#. **ioctlCommand** : Is used to locate the module (Statistics/ Port
-   control etc) which should be called.
-#. **ioctlParams** : Is used to give module specific instructions
-
-***ioctlParams*** consists of
-
--  **command** : Indicates which specific API to execute
--  **ioctlVal** : Sometimes the API may require specific input, this is
-   used to provide that.
-
-For example to disable receive functionality on a port the following
-code is used. This code is part of Link interrupt functionality where
-receive is disabled when PHY detects a link down.
-
-.. code-block:: c
-
-    ioctlvalue = ICSS_EMAC_IOCTL_PORT_CTRL_DISABLE;
-    ioctlParams.ioctlVal = &ioctlvalue;
-    ICSS_EmacIoctl(icssEmacHandle, ICSS_EMAC_IOCTL_PORT_CTRL, ICSS_EMAC_PORT_1, (void*)&ioctlParams);
-
-Here *ICSS_EMAC_IOCTL_PORT_CTRL* refers to the ***ioctlCommand*** while
-*ICSS_EMAC_IOCTL_PORT_CTRL_DISABLE* is the ***command*** part of
-**ioctlParams** which tells which action to perform, in this case
-disabling the port. Port selected is *ICSS_EMAC_PORT_1* which refers to
-Port 1.
-
-A complete list of commands and actions is given below.
-
-API Guide & Data Structures
-"""""""""""""""""""""""""""""
-
-IOCTL Command structure
-
-.. code-block:: c
-
-     typedef struct ICSSEMAC_IoctlCmd {
-       uint8_t command;
-       uint8_t* ioctlVal;
-     }ICSSEMAC_IoctlCmd;
-
-There is only one API for IOCTL. It's defined below
-
-.. code-block:: c
-
-    uint8_t ICSS_EmacIoctl(ICSSEMAC_Handle icssEmacHandle, uint32_t ioctlCommand, uint8_t portNo, void *ioctlParams)
-
-The possible values for ***ioctlCommand*** are
-
--  *ICSS_EMAC_IOCTL_PORT_CTRL* : Select Port Control Operations.
-   Enable/Disable Rx for the specified port.
--  *ICSS_EMAC_IOCTL_LEARNING_CTRL* : Select Learning/FDB module.
--  *ICSS_EMAC_IOCTL_STORM_PREV_CTRL* : Select Storm Prevention module.
--  *ICSS_EMAC_IOCTL_STATS_CTRL* : Select Statistics module.
--  *ICSS_EMAC_IOCTL_TTS_CTRL* : Select Time Triggered Send Configuration
-   module. Enable/Disable TTS for the specified port.
--  *ICSS_EMAC_IOCTL_TTS_STATUS_CTRL* : Select Time Triggered Send Query
-   module. Get TTS status and other details for the specified port from
-   PRU firmware.
-
-Possible values for ***ioctlParams*** are
-
--  **ICSS_EMAC_IOCTL_LEARNING_CTRL** : Refer to Learning/FDB API's
-
-   -  *ICSS_EMAC_LEARN_CTRL_UPDATE_TABLE* : Add an entry to the Hash
-      table.
-   -  *ICSS_EMAC_LEARN_CTRL_CLR_TABLE* : Clear the Learning Table for
-      the specified port.
-   -  *ICSS_EMAC_LEARN_CTRL_AGEING* : Age out old entries from the
-      table.
-   -  *ICSS_EMAC_LEARN_CTRL_FIND_MAC* : Find the port number given a MAC
-      ID.
-   -  *ICSS_EMAC_LEARN_CTRL_REMOVE_MAC* : Remove a MAC ID from the
-      Learning Table
-   -  *ICSS_EMAC_LEARN_CTRL_INC_COUNTER* : Age the entries with time by
-      calling this periodically
-   -  *ICSS_EMAC_LEARN_CTRL_INIT_TABLE* : Initialize the learning table
-   -  *ICSS_EMAC_LEARN_CTRL_SET_PORTSTATE* : Set the Port state to value
-      defined by the enum type **portState**
-
--  **ICSS_EMAC_IOCTL_STATS_CTRL** : Refer to Statistics API's
-
-   -  *ICSS_EMAC_IOCTL_STAT_CTRL_GET* : Get the statistics
-   -  *ICSS_EMAC_IOCTL_STAT_CTRL_CLEAR* : Clear all stat counters
-
--  **ICSS_EMAC_IOCTL_STORM_PREV_CTRL** : Refer to Storm prevention API's
-
-   -  *ICSS_EMAC_STORM_PREV_CTRL_ENABLE* : Enable Storm Prevention
-   -  *ICSS_EMAC_STORM_PREV_CTRL_DISABLE* : Disable Storm Prevention
-   -  *ICSS_EMAC_STORM_PREV_CTRL_SET_CREDITS* : Set how many BC/MC
-      packets are allowed in a period of 100 NDK Ticks (Time period of
-      **\_HwPktPoll()**)
-   -  *ICSS_EMAC_STORM_PREV_CTRL_INIT* : Initialize Storm Prevention
-   -  *ICSS_EMAC_STORM_PREV_CTRL_RESET* : Renew the storm prevention
-      counters, this allows more packets to come through once existing
-      credits have expired. This must be called periodically in
-      **\_HwPktPoll()**
-
--  **ICSS_EMAC_IOCTL_PORT_CTRL** : For Rx Enable/Disable operations.
-   There are no sub-commands here. Whether to enable or disable is
-   decided by the value of ***ioctlVal***
-
-
-Usage
-"""""""
-
-Using IOCTL to debug the issues is encouraged. This is easier than
-trying to connect an emulator and reading the values at run time. There
-are numerous instances of it's usage. A quick search for the API
-**ICSS_EmacIoctl** throughout the code reveals numerous examples. One of
-them pertaining to Storm Control module is shown below.
-
-In this example the storm prevention counters are reset in PRU Data RAM
-using IOCTL. The **if/else** refers to Switch or EMAC mode, rest of the
-code is self-explanatory
-
-.. code-block:: c
-
-     ioctlParams.command = ICSS_EMAC_STORM_PREV_CTRL_RESET;
-     /*Reset the credit values used for Storm prevention*/
-     if(ICSS_EMAC_MODE_SWITCH == ((ICSSEMAC_Object*)(pi->nimuDrvHandle)->object)->emacInitcfg->portMask)
-     {
-       strmPreventionEnable1 = (stormPrevention_t*)(((ICSSEMAC_Object*)(pi->nimuDrvHandle)->object)->stormPrevPtr);
-       strmPreventionEnable2 = (stormPrevention_t*)(((ICSSEMAC_Object*)(pi->nimuDrvHandle)->object)->stormPrevPtr +1);
-       if(strmPreventionEnable1->suppressionEnabled ||   strmPreventionEnable2->suppressionEnabled)
-        ICSS_EmacIoctl(pi->nimuDrvHandle, ICSS_EMAC_IOCTL_STORM_PREV_CTRL, NULL, (void*)&ioctlParams);
-     }
-     else
-     {
-       strmPreventionEnable1 = (stormPrevention_t*)(((ICSSEMAC_Object*)(pi->nimuDrvHandle)->object)->stormPrevPtr);
-       if(strmPreventionEnable1->suppressionEnabled)
-        ICSS_EmacIoctl(pi->nimuDrvHandle, ICSS_EMAC_IOCTL_STORM_PREV_CTRL, NULL, (void*)&ioctlParams);
-     }
-
-Time Triggered Send
-^^^^^^^^^^^^^^^^^^^^^
-
-The EMAC Time Triggered Send (TTS) is used to expand classical Ethernet
-to meet deterministic, time-critical or safety-relevant conditions. TTS
-reduces the transmission jitter from 10us range to 40ns. TTS can be
-dynamically enabled and disabled by the Host. We have two well defined
-TTS APIs which control all TTS related EMAC aspects. Developers are
-advised to access these APIs using the EMAC IOCTL implementation as
-explained in the `IOCTL <index_device_drv.html#ioctl>`__ section
-previously.
-
-TTS Design Overview
-"""""""""""""""""""""
-
-TTS is designed to facilitate transmission of packets at pre-defined
-cyclic instants/triggers. The `TTS API Details and Data
-Structures <index_device_drv.html#tts-api-details-and-data-structures>`__
-are explained below but in a broad sense we can say that while
-initializing TTS, the application must provide the first cyclic trigger
-and the cycle period. The PRU firmware then sets cyclic triggers
-repeatedly and shall send the packets cyclically provided that they are
-queued before the trigger. The following timing diagram explains the use
-of TTS.
-
-Each cycle shall have a configuration time (as shown in the figure
-above) before each trigger. This configuration time is used to setup the
-start trigger and end trigger of current cycle in the PRU firmware. If
-the application does not set a suitable (long enough) configuration
-time, the PRU and perhaps even the EMAC Driver TTS API may not get
-enough time to setup and initialize TTS. This might result in improper
-functionality. The configuration time shall also be provided during
-initialization and shall be application specific. For example, if a
-response packet is to be received for the cyclic packet sent at trigger
-T1 and based on that response packet the next cyclic packet shall be
-generated, then the developer can increase/decrease configuration time
-accordingly to ensure that the next cyclic packet is ready before
-trigger T2 which shall in-turn be based on when the response packet is
-received.
-
-Queue 0 (high priority queue) is reserved as the real-time queue. All
-packets in queue 0 are cyclic packets. On the other hand, packets from
-other queues are acyclic packets. Cyclic packets are sent at triggered
-instances, whereas acyclic packets are sent based on time availability,
-as shown in the figure below.
-
-The time availability check for cyclic packets means to basically check
-whether the acyclic packet can be transmitted such that its transmission
-does not overlap the next cyclic trigger, considering the size of the
-acyclic packet. Such a situation is represented as “Undesired Behaviour”
-in the above figure and PRU firmware ensures that this never happens.
-Only one cyclic packet will be sent out in each cycle irrespective of
-the number of cyclic packets available in Queue 0. There is no
-restriction on the number of acyclic packets sent out in each cycle but
-it is contingent on time availability. Cyclic packets must be queued in
-Queue 0 before the trigger instant else two erroneous situations are
-possible:
-
-#. If the firmware finds a packet in any other low priority queue, it
-   will send the acyclic packet. Once an acyclic packet has been
-   transmitted in a given cycle, no cyclic packet will be transmitted in
-   that cycle. So, if the cyclic packet is not queued on time, it will
-   miss the cycle and will be transmitted in the next cycle.
-#. If all the queues are empty and a cyclic packet is inserted late, it
-   will result in increased jitter.
-
-The above two situations are demonstrated in the figure below.
-
-In the above figure, the PRU firmware ensures that the first two
-situations never occur but the application needs to take care of the
-third situation, i.e., by queueing the cyclic packet on time.
-
-The PRU firmware makes the following assumptions regarding TTS:
-
-#. The cycle period is long enough to be able to transmit any cyclic
-   packet in queue 0. Failure to ensure this will cause the cyclic
-   packet with size greater than the allowed size (as per the period),
-   and any cyclic packets following it, to remain in the queue.
-#. The configuration time provided (using ICSS EMAC IOCTL) is sufficient
-   for the PRU to configure the next cycle. PRU should typically need a
-   maximum of 10us to configure the next cycle.
-#. If the host keeps queuing packets irrespective of the fact whether
-   the packet has been transmitted by the firmware (in accordance with
-   the preset triggered intervals), the packets might get dropped at the
-   driver level if the queue is full. It is assumed that this is taken
-   care of at the host level.
-
-TTS API Details and Data Structures
-"""""""""""""""""""""""""""""""""""""
-
-TTS has the following APIs, which are accessed using EMAC IOCTL
-implementation as explained in the IOCTL section previously.
-
-.. code-block:: c
-
-    int8_t ICSS_EmacTTS(const ICSS_EmacTTSConfig* ttsConfig)
-
-This API is used to enable/disable time triggered send for Queue 0
-frames.
-
-.. code-block:: c
-
-    int8_t ICSS_EmacTTSGetStatus(ICSS_EmacTTSQuery* ttsQuery)
-
-This API is used to query time triggered send details, status and TTS
-parameter values from PRU firmware.
-
-The TTS parameter structure is explained below:
-
-.. code-block:: c
-
-    typedef struct ICSS_EmacTTSConfig_s {
-      ICSSEMAC_Handle icssEmacHandle;
-      uint8_t portNumber;
-      uint64_t cycleStartTime;
-      uint32_t cyclePeriod;
-      uint32_t configTime;
-      uint8_t statusTTS;
-      uint8_t cycTxSOFStatus;
-    } ICSS_EmacTTSConfig;
-
--  *icssEmacHandle*: EMAC handle for concerned EMAC instance and port.
--  *portNumber*: Port number for which TTS needs to be enabled/disabled.
--  *cycleStartTime*: A future IEP counter value at which the first
-   cyclic packet will be transmitted.
--  *cyclePeriod*: TTS cycle period.
--  *configTime*: Configuration time for PRU to setup upcoming TTS cycle.
--  *statusTTS*: Enable/Disable TTS. Enable = 1, Disable = 0.
--  *cycTxSOFStatus*: Enable/Disable storing transmit start-of-frame
-   timestamp for cyclic packets in memory. Enable = 1, Disable = 0.
-
-The TTS query structure is as explained below:
-
-.. code-block:: c
-
-    typedef struct ICSS_EmacTTSQuery_s {
-      ICSSEMAC_Handle icssEmacHandle;
-      uint8_t portNumber;
-      uint8_t statusTTS;
-      uint8_t missedCycle;
-      uint8_t insertCycFrameNotification;
-      uint8_t cycTxSOFStatus;
-      uint32_t missedCycleCounter;
-      uint64_t cycTxSOF;
-    } ICSS_EmacTTSQuery;
-
--  *icssEmacHandle*: EMAC handle for concerned EMAC instance and port.
--  *portNumber*: Port number for which TTS query needs to be performed.
--  *statusTTS*: Whether TTS is enabled/disabled for given port. Enabled
-   = 1, Disabled = 0.
--  *missedCycle*: Whether any cyclic packet missed a cycle. Missed = 1,
-   Did not miss = 0.
--  *insertCycFrameNotification*: Notification to state that it’s time to
-   insert cyclic packet. If it’s time = 1, else = 0.
--  *cycTxSOFStatus*: Whether storing transmit start-of-frame timestamp
-   for cyclic packets in memory is enabled/disabled. Enabled = 1,
-   Disabled = 0.
--  *missedCycleCounter*: Number of cycles missed by cyclic packets.
-
-The application shall update the elements of the ICSS_EmacTTSConfig
-structure and pass its pointer to EMAC IOCTL with appropriate command to
-enable/disable TTS. On the other hand, the application shall only update
-the icssEmacHandle and portNumber elements of the ICSS_EmacTTSQuery
-structure and pass its pointer to EMAC IOCTL with appropriate command to
-retrieve the details from PRU firmware. The driver TTS API
-(ICSS_EmacTTSGetStatus) shall then update the elements of the structure
-with appropriate values.
-
-TTS can be enabled/disabled using EMAC IOCTL as follows:
-
-For Enable:
-
-.. code-block:: c
-
-    ICSSEMAC_IoctlCmd ioctlParams;
-    ICSS_EmacTTSConfig ttsConfig;
-    uint32_t iepRegsBase;
-    int8_t ret;
-
-    ioctlParams.command = 0;
-    ioctlParams.ioctlVal = (void *)(&ttsConfig);
-
-    ttsConfig.icssEmacHandle = icssEmacHandle;
-    ttsConfig.cycTxSOFStatus = ICSS_EMAC_TTS_CYC_TXSOF_ENABLE;
-    ttsConfig.portNumber = portNumber;
-    ttsConfig.configTime = ICSS_EMAC_TTS_CONFIG_TIME;
-    ttsConfig.cyclePeriod = cyclePeriod;
-    ttsConfig.statusTTS = ICSS_EMAC_TTS_ENABLE;
-
-    iepRegsBase = (((ICSS_EmacHwAttrs*)icssEmacHandle->hwAttrs)->emacBaseAddrCfg)->prussIepRegs;
-
-    /*  Reading IEP Counter Value.  */
-    iepCounterVal = (*((uint64_t*)(iepRegsBase + CSL_ICSSIEP_COUNT_REG0)));
-
-    /*  Calculating cycle start value by adding 100us to counter value. */
-    ttsConfig.cycleStartTime = (uint64_t)(iepCounterVal + 100000);
-
-    /*  Enabling time triggered send.   */
-    ret = ICSS_EmacIoctl(icssEmacHandle, ICSS_EMAC_IOCTL_TTS_CTRL, portNumber, &ioctlParams);
-    assert(ret == 0);
-
-For Disable:
-
-.. code-block:: c
-
-    ICSSEMAC_IoctlCmd ioctlParams2;
-    ICSS_EmacTTSConfig ttsConfig;
-    int8_t ret;
-
-    /*  Setting tts status to disable (Port 1)  */
-    ttsConfig.icssEmacHandle = icssEmacHandle;
-    ttsConfig.statusTTS = ICSS_EMAC_TTS_DISABLE;
-    ttsConfig.cyclePeriod = 0;
-    ttsConfig.configTime = 0;
-    ttsConfig.cycleStartTime = 0;
-    ttsConfig.cycTxSOFStatus = ICSS_EMAC_TTS_CYC_TXSOF_DISABLE;
-    ttsConfig.portNumber = portNumber;
-
-    ioctlParams2.command = 0;
-    ioctlParams2.ioctlVal = (void *)(&ttsConfig);
-
-    /*  Disabling time triggered send on PORT 1 (PRU0). */
-    ret = ICSS_EmacIoctl(icssEmacHandle, ICSS_EMAC_IOCTL_TTS_CTRL, portNumber, &ioctlParams2);
-    assert(ret == 0);
-
-TTS Cyclic Frame Notification
-"""""""""""""""""""""""""""""""
-
-The PRU firmware has been designed to notify the Host when it’s time to
-insert the cyclic packet. This helps the Host to queue the cyclic packet
-well before trigger time and avoid any unnecessary jitter or any other
-erroneous situations as mentioned previously. The firmware does this in
-two ways:
-
-Polling Mode
-''''''''''''''
-
--  In this mode the firmware sets a status bit when it’s time to insert
-   the cyclic frame and this bit cleared when the time to insert the
-   cyclic frame is over or the firmware has found a cyclic frame in
-   Queue 0.
--  This status bit can be queried using the EMAC IOCTL and is reflected
-   in insertCycFrameNotification element of the ICSS_EmacTTSQuery
-   structure.
--  If it’s time, insertCycFrameNotification = 1, else
-   insertCycFrameNotification = 0.
--  The application must then continuously poll for this status by
-   repeating EMAC IOCLT calls and querying TTS status.
--  Once insertCycFrameNotification = 1, the application must queue the
-   cyclic frame in Queue 0.
-
-Interrupt Mode
-''''''''''''''''
-
--  In this mode, in addition to setting the status bit as in polling
-   mode, the firmware has the capability to give an interrupt to the
-   Host when it’s time to insert a cyclic frame.
--  The interrupt feature should be first enabled as follows during EMAC
-   Driver Initilization.
-
-::
-
-    ICSS_EmacInitConfig* switchEmacCfg;
-    switchEmacCfg = (ICSS_EmacInitConfig*)malloc(sizeof(ICSS_EmacInitConfig));
-    switchEmacCfg->ICSS_EmacTTSEnableCycPktInterrupt = ICSS_EMAC_TTS_CYC_INTERRUPT_ENABLE;
-
--  Also, proper interrupt mapping should be done as explained earlier in
-   this guide.
--  Interrupt callback functions should also be registered for all
-   concerned EMAC handles using the following API:
-
-::
-
-    ICSS_EmacRegisterHwIntTTSCyc(emachandle, (ICSS_EmacCallBack)ttsCycPort1Callback);
-
--  Interrupts should also be enabled. Please refer to example ICSS EMAC
-   applications from Processor SDK RTOS for further details.
--  Once the PRU firmware throws an interrupt, the registered callback
-   function is called and this is where the application shall queue the
-   cyclic packet to Queue 0.
-
-ICSS EMAC LLD Dependencies
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-ICSS EMAC LLD is dependent on the Application/Transport layer for its
-proper functioning. These dependencies have been consolidated and
-exported to the application layer (example) to make it easy for
-developer to integrate the LLD with their own RTOS and TCP/IP stack.
-
-Interrupt Configuration
-""""""""""""""""""""""""
-
-ICSS EMAC LLD expects the Interrupt configuration to come from
-Application/Transport layer. The interrupt configuration is explained in
-detail in the interrupts `section <index_device_drv.html#id58>`__.
-Please refer to it for more details.
-
-The LLD makes use of two interrupts for copying packets from the queues
-to the TCP/IP stack.
-
-Rx Interrupt
-''''''''''''''
-
-The ICSS EMAC LLD depends on the Rx interrupt for receiving packets.The
-application should do the interrupt creation and should use the API
-**ICSS_EmacRxInterruptHandler** as the ISR.This will enable the ICSS
-EMAC LLD to receive packets. The user should make sure the arm interrupt
-(Rx) is mapped to correct PRUSS Event. The PRUSS Event that is used for
-Rx will be determined by the firmware which will be used along with the
-ICSS EMAC LLD
-
-Link Interrupt
-'''''''''''''''
-
-Link Interrupt informs the ICSS EMAC LLD of any Link state change. This
-is where the LLD informs the firmware about the Link status and the Phy
-configuration.The LLD expects single interrupt for both Ports. In case
-the Interrupt mechanism is not available, the application should call
-**ICSS_EmacLinkISR** whenever there is a link change.
-
-Learning module Increment counter implementation
-"""""""""""""""""""""""""""""""""""""""""""""""""
-
-This is required for Switch implementation only. The application needs
-to call the IOCTL periodically, this is already done by the NDK. Refer
-to the API `section <index_device_drv.html#api-guide-data-structures>`__
-of Learning for more details.
-
-MDIO Configurations
-"""""""""""""""""""""
-
-ICSS EMAC LLD does not do any of the MDIO configurations. It expects the
-application to do following MDIO operations
-
--  MDIO Initialization -
--  MDIO Link Interrupt enable if MDIO Link interrupt is used
-
-NOTE: Please refer to ti/drv/icss_emac/test/src/test_mdio.c for details
-of how to initialize the MDIO sub-system and how to enable MDIO link
-interrupts. This file contains a set of MDIO test APIs which are used by
-the icss emac loopback unit tests.
-
-EMAC Configuration and How To
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Network related
-""""""""""""""""""
-
-How to configure IP address and other IPv4 parameters
-'''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-IP address, network mask and other params can be set through the NDK
-configuration file. See
-`here <http://processors.wiki.ti.com/index.php/SYSBIOS_Industrial_SDK_02.01.00.01_User_Guide#Ethernet_MAC>`__
-
-.. rubric:: How to configure MAC address
-   :name: How-to-configure-MAC-address
-
-MAC address is variable macId in the configuration ICSSEMAC_InitConfig. It can
-be set as per the application requirements. The following excerpt from
-ethernet_mac example shows how to do this
-
-::
-
-    /*Get MAC address from eFUSE*/
-    SOCCtrlGetPortMacAddr(1,lclMac);
-    /*Assign MAC ID for that particular port*/
-    switchEmacCfg->macId = lclMac;
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ESPI_FIRMWARE.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ESPI_FIRMWARE.rst
deleted file mode 100644
index f6184d289..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ESPI_FIRMWARE.rst
+++ /dev/null
@@ -1,251 +0,0 @@
-.. http://ap-fpdsp-swapps.dal.design.ti.com/index.php/Processor_SDK_RTOS_ESPI_FIRMWARE
-
-Introduction
-============
-
-| PRU-ICSS eSPI serves as an example for firmware-based eSPI peripheral
-  support. The Processor SDK package includes full source code for eSPI FW.
-
-|
-
-Firmware Organization
-=====================
-
-+-------------------------+--------------------------------------------------+
-| **FW Item**             | **Directory**                                    |
-+=========================+==================================================+
-| Source code             | <PDK>/packages/ti/drv/spi/firmware/icss_espi/src/|
-+-------------------------+--------------------------------------------------+
-| Design Guide            | <PDK>/packages/ti/drv/spi/docs/                  |
-+-------------------------+--------------------------------------------------+
-
-Firmware Build Instruction
-==========================
-
-Build instruction from Processor SDK Release package
-----------------------------------------------------
-.. rubric::  Pre-requisites to Building
-   :name: espi-pre-requisites-to-building
-
-Refer to the Processor SDK RTOS Building page for information on setting up the build environment.
-
-.. rubric::  Compiling Driver/Firmware
-   :name: espi-compiling-driver-firmware
-
-1. ``make spi``
-
-
-.. rubric::  Running CCS Application
-   :name: espi-run-app
-
-CCS applications will be build and run just like any other project with one exception. Before loading the binary, from the menu-bar run ``Scripts > PRU_ICSS > PRU_ICSS_Init``.
-
-Supported EVMs
-==============
-
-Supported EVMs and pin configurations for these EVMs are listed below. See the design document in ``<PDK>/packages/ti/drv/spi/docs/`` for more information.
-
-+-------------+---------------------+-------------------+
-| EVM Name    | PRU-ICSS Instances  | PRU-ICSS Revision |
-+=============+=====================+===================+
-| bbbAM335x   | 1                   | REV1              |
-+-------------+---------------------+-------------------+
-| idkAM437x   | 2                   | REV1              |
-+-------------+---------------------+-------------------+
-
-
-.. rubric::  bbbAM335x
-   :name: espi-bbbam335x
-
-+---------+-------+----------------+----------------------+----------+---------+
-| Core    | PRU   | Functional Pin | GPIO Pins            | EVM Port | EVM Pin |
-+=========+=======+================+======================+==========+=========+
-|         |       | OUT[0]         | pr1_pru0_pru_r30_4   | J3       | 41      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | OUT[1]         | pr1_pru0_pru_r30_5   | J3       | 42      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | OUT[2]         | pr1_pru0_pru_r30_6   | J3       | 39      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | OUT[3]         | pr1_pru0_pru_r30_7   | J3       | 40      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | Alert          | pr1_pru0_pru_r30_9   | J3       | 29      |
-|         |       +----------------+----------------------+----------+---------+
-| ICSS1   | PRU1  | EN             | pr1_pru0_pru_r30_10  | J3       | 28      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | IN[0]          | pr1_pru0_pru_r30_0   | J3       | 45      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | IN[1]          | pr1_pru0_pru_r30_1   | J3       | 46      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | IN[2]          | pr1_pru0_pru_r30_2   | J3       | 43      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | IN[3]          | pr1_pru0_pru_r30_3   | J3       | 44      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | SCL            | pr1_pru0_pru_r30_8   | J3       | 27      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | CS             | pr1_pru0_pru_r30_11  | J3       | 30      |
-+---------+-------+----------------+----------------------+----------+---------+
-| A8      | n/a   | Reset          | GPIO_3_19            | J9       | 26      |
-+---------+-------+----------------+----------------------+----------+---------+
-
-.. rubric::  idkAM437x
-   :name: espi-idkAM437x
-
-+---------+-------+----------------+----------------------+----------+---------+
-| Core    | PRU   | Functional Pin | GPIO Pins            | EVM Port | EVM Pin |
-+=========+=======+================+======================+==========+=========+
-|         |       | OUT[0]         | pr1_pru0_pru_r30_6   | P16      | 49      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | Alert          | pr1_pru0_pru_r30_11  | P16      | 48      |
-|         |       +----------------+----------------------+----------+---------+
-| ICSS1   | PRU0  | EN             | pr1_pru0_pru_r30_8   | P16      | 6       |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | IN[0]          | pr1_pru0_pru_r30_16  | P16      | 42      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | SCL            | pr1_pru0_pru_r30_10  | P16      | 46      |
-|         |       +----------------+----------------------+----------+---------+
-|         |       | CS             | pr1_pru0_pru_r30_9   | P16      | 8       |
-+---------+-------+----------------+----------------------+----------+---------+
-| A9      | n/a   | Reset          | GPIO_5_9             | P16      | 32      |
-+---------+-------+----------------+----------------------+----------+---------+
-
-
-eSPI Applications
-=================
-
-We have included a simple example test application which handles PUT_IORD_SHORT,
-PUT_IOWR_SHORT, PUT_MEMRD32_SHORT, and PUT_MEMWR32_SHORT packets with expected
-address/data values. This can be used as a starting point to build your own
-applications, along with the following:
-
-- eSPI uses the MCSPI API
-
-   - Open as MCSPI instance 2
-
-- HW interrupts must be enabled
-
-   - i.e. HwiP_enableInterrupt(espi_cfg.intNum)
-
-- MCSPI_transfer() is blocking and takes a SPI_Transaction parameter which is
-  used as follows:
-
-   - RX Transfer:
-
-      - transaction.rxBuf = <some pre-allocated buffer>
-
-      - transaction.txBuf = Null
-
-      - transaction.count = max packet size
-
-   - TX Transfer:
-
-      - transaction.rxBuf = Null
-
-      - transaction.txBuf = <some pre-allocated buffer>
-
-      - transaction.count = <size of packet>
-
-- The application must parse the full eSPI packet, and must respond with the
-  full proper eSPI packet (the RSP code and CRC will be taken care of by the
-  firmware)
-
-.. rubric::  example-application
-   :name: espi-example-application
-
-.. code-block:: c
-
-    /* Refer to eSPI FW Example for details */
-
-    Board_init(boardCfg);
-
-    ...
-
-    /* Initialize the ESPI fw configuration */
-    ESPI_socInitFwCfg();
-
-    /* Get the default ESPI init configurations */
-    ESPI_socGetFwCfg(ESPI_INSTANCE, &espi_cfg);
-
-    /* Modify the default eSPI configurations if necessary */
-
-    /* Set the default ESPI init configurations */
-      ESPI_socSetFwCfg(ESPI_INSTANCE, &espi_cfg);
-
-    /* Set GPIO pin configurations */
-    GPIO_setConfig(ESPI_GPIO_PIN_RESET, GPIO_DEVICE_CONFIG(espi_cfg.resetPin.port,
-    						    espi_cfg.resetPin.pinNum) |
-    		 GPIO_CFG_IN_INT_RISING | GPIO_CFG_INPUT);
-
-    /* Initialize GPIO */
-    GPIO_init();
-
-    /* Initialize the MCSPI paramters */
-    MCSPI_Params_init(&mcspiParams);
-
-    /* Init SPI driver */
-    MCSPI_init();
-
-    /* Enable interrupts (necessary for  */
-    HwiP_enableInterrupt(espi_cfg.intNum);
-
-    /* Grab ESPI handle from SoC config list */
-    fwHandle = (MCSPI_Handle)MCSPI_open(ESPI_INSTANCE, 0, &mcspiParams);
-
-    ...
-
-    /* Read ESPI Packet */
-    transaction.txBuf = NULL; /* indicates we want RX */
-    transaction.rxBuf = (uint8_t*) rxBuf;
-    transaction.count = ESPI_PACKET_MAX_SIZE;
-    retVal = MCSPI_transfer(fwHandle, &transaction);  /* blocking */
-
-    ...
-
-    /* Prepare TX response */
-    transaction.txBuf = (uint8_t*) txBuf;
-    transaction.rxBuf = NULL; /* indicates we want TX */
-    transaction.count = ESPI_PACKET_MAX_SIZE;
-
-    ...
-
-    /* Put response in TX queue */
-    retVal = MCSPI_transfer(fwHandle, &transaction);
-
-    ...
-
-.. rubric::  Examples List
-   :name: examples-list
-
-Refer to the Release Notes for details concerning eSPI support across different EVMs.
-
-+-----------------------+-----------------------+---------------------------+
-| Name                  | Description           | Expected Results          |
-+=======================+=======================+===========================+
-| ESPI_FwExample        | Driver Firmware       | A short write to 0xDEAD   |
-|                       | example application   | or 0x0D0E0A0D will not    |
-|                       | for ESPI FW instances | print or return anything. |
-|                       |                       | A short read from 0xDEAD  |
-|                       |                       | or 0x0D0E0A0D will return |
-|                       |                       | the command opcode + the  |
-|                       |                       | byte-number of the        |
-|                       |                       | response. A read from any |
-|                       |                       | other address will return |
-|                       |                       | the opcode minus the      |
-|                       |                       | byte-number of the        |
-|                       |                       | response.                 |
-+-----------------------+-----------------------+---------------------------+
-
-|
-
-.. rubric::  Firmware Design Guide
-   :name: firmware-design-guide
-
-+-----------------------------------+---------------------------------------------------------+
-| **Document**                      | **Location**                                            |
-+===================================+=========================================================+
-| eSPI FIRMWARE Design Guide        | <PDK>/packages/ti/drv/spi/docs/ESPI_FW_DESIGN_GUIDE.doc |
-+-----------------------------------+---------------------------------------------------------+
-
-**NOTE: For normal use of eSPI FW, there is no need to refer to the design guide.
-This document can be cosulted in case of interest in details of internal firmware
-operation, or a desire to modify the firmware.**
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_I2C_FIRMWARE.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_I2C_FIRMWARE.rst
deleted file mode 100644
index f1744c7a1..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_I2C_FIRMWARE.rst
+++ /dev/null
@@ -1,344 +0,0 @@
-.. http://ap-fpdsp-swapps.dal.design.ti.com/index.php/Processor_SDK_RTOS_I2C_FIRMWARE
-
-Introduction
-============
-
-| PRU-ICSS I2C serves as an example for firmware-based I2C peripheral
-  support. The I2C firmware (I2C FW) allows additional I2C instances for SOCs
-  beyond those supported by SOC hardware. The Processor SDK package includes
-  full source code for I2C FW.
-
-|
-
-FIRMWARE FEATURES
-=================
-
-I2C FW supports the standard two pin I2C interface through three GPIO pins
-from the PRU-ICSS module. The I2C SCL pin is implemented using a single
-GPIO configured in GPO mode. The I2C SDA pin is implemented using two GPIO
-pins: one pin configured in GPI mode for sampling SDA, and a second pin
-configured in GPO mode for driving the SDA. Depending on the I2C clock
-speed, I2C FW can emulate multiple I2C instances from a single PRU core.
-Following are high-level I2C FW features:
-
-+-----------------------------------+-----------------------------------+
-| **Feature**                       | **Remarks**                       |
-+-----------------------------------+-----------------------------------+
-| No. of instances                  | 4 (Standard mode)                 |
-|                                   |                                   |
-|                                   | 1 (Fast mode)                     |
-+-----------------------------------+-----------------------------------+
-| SMBus support                     | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Addressing modes                  | 7/10-bit                          |
-+-----------------------------------+-----------------------------------+
-| Controller mode                   | Supported                         |
-+-----------------------------------+-----------------------------------+
-| I2C data transfer rate from       | 100 kHz / 400 kHz                 |
-| 100 kbps up to 400 kbps           |                                   |
-+-----------------------------------+-----------------------------------+
-| Bit format transfer               | 8 bit                             |
-+-----------------------------------+-----------------------------------+
-| Number of host interrupts         | 1                                 |
-+-----------------------------------+-----------------------------------+
-| Peripheral enable/disable         | Supported                         |
-| capability                        |                                   |
-+-----------------------------------+-----------------------------------+
-| Start/Restart/Stop                | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Built-in configurable FIFOs (8,   | 8/16/32/64/128/256                |
-| 16, 32, 64 bytes) for buffered    |                                   |
-| read/write                        |                                   |
-+-----------------------------------+-----------------------------------+
-| 8-bit-wide data access            | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Target reset feature              | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Internal loopback feature         | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Target mode                       | Not Supported                     |
-+-----------------------------------+-----------------------------------+
-| Combined Controller-Target        | Not Supported                     |
-| mode/transaction                  |                                   |
-+-----------------------------------+-----------------------------------+
-| DMA support                       | Not Supported                     |
-+-----------------------------------+-----------------------------------+
-| Programmable clock generation     | Not Supported                     |
-+-----------------------------------+-----------------------------------+
-| Implement Auto Idle mechanism     | Not Supported                     |
-| (SOC specific feature)            |                                   |
-+-----------------------------------+-----------------------------------+
-| Implement Idle Request/Idle       | Not Supported                     |
-| Acknowledge handshake mechanism   |                                   |
-| (SOC specific feature)            |                                   |
-+-----------------------------------+-----------------------------------+
-| Support for asynchronous wakeup   | Not Supported                     |
-| mechanism                         |                                   |
-+-----------------------------------+-----------------------------------+
-
-Firmware Organization
-=====================
-
-+-------------------------+--------------------------------------------------+
-| **FW Item**             | **Directory**                                    |
-+-------------------------+--------------------------------------------------+
-| Source code             | <PDK>/packages/ti/drv/i2c/firmware/icss_i2c/src  |
-+-------------------------+--------------------------------------------------+
-| Design Guide            | <PDK>/packages/ti/drv/i2c/firmware/icss_i2c/docs |
-+-------------------------+--------------------------------------------------+
-| Firmware binaries       | <PDK>/packages/ti/drv/i2c/firmware/icss_i2c/bin  |
-+-------------------------+--------------------------------------------------+
-
-|
-
-Firmware Build Instruction
-==========================
-
-Build instruction from Processor SDK Release package
-----------------------------------------------------
-
-.. rubric::  Pre-requisites to Building
-   :name: pre-requisites-to-building
-
-Refer to the Processor SDK RTOS Building page for information on setting up the build environment.
-
-.. rubric::  Compiling I2C FIRMWARE
-   :name: compiling-i2c-firmware
-
--  cd <PDK>/packages/ti/drv/i2c
--  make firm
-
-Firmware binaries at the end of the build will be located at:
-
--  <PDK>/packages/ti/drv/i2c/firmware/<FIRMWARE_TYPE>/bin/<SOC>/<HOST_CORE>/<REVISION>
-
--  <FIRMWARE_TYPE> indicates the firmware type i.e. icss_i2c
-
--  <SOC> indicates the SOC type, e.g. am437x
-
--  <HOST_CORE> indicates the Host core type on which the built binary
-   can be loaded, e.g. a9host
-
--  <REVISION> indicates the revision of the firmware binary based on
-   core (there are 2 revision of PRU-ICSS core), e.g. REV1.
-
-|
-
-Build instruction for GIT
--------------------------
-
-Following are the steps for building firmware from any external
-environment outside Processor SDK RTOS package.
-
--  Creation of directories
-
-   -  Create a working directory e.g. <WORK_DIR>
-   -  Create a new directory named ti inside working directory. i.e.
-      <WORK_DIR/ti>
-   -  Create a new directory called drv inside ti. i.e.
-      <WORK_DIR/ti/drv>
-
--  Clone of Repos
-
-   -  Git clone pdk build repo into ti directory. i.e.
-      <WORK_DIR/ti/build>
-   -  Git clone i2c repo into ti/drv directory. i.e.
-      <WORK_DIR/ti/drv/i2c>
-
--  Setting Environment Variables
-
-   -  Export CLPRU install path. i.e. export CL_PRU_INSTALL_PATH=clpru
-      toolchain directory
-   -  Export pdk install path. i.e. export PDK_INSTALL_PATH=<WORK_DIR>
-   -  Export LIMIT_SOCS Variable i.e. LIMIT_SOCS=<SOC> [Optional for
-      limiting to some SOCs]
-
--  Build command
-
-   -  Run make firm_clean/firm to clean/build firmware from i2c
-      directory i.e. <WORK_DIR/ti/drv/i2c>
-
--  Generated binaries
-
-   -  the firmware binaries which will be located in
-      <WORK_DIR/ti/drv/i2c/firmware/<FIRMWARE_TYPE>/bin/<SOC>/<HOST_CORE>/<REVISION>>
-
-|
-
-Supported EVMs
-==============
-
-Supported EVMs and pin configurations for these EVMs are listed below.
-
-+-------------+---------------------+-------------------+
-| EVM Name    | PRU-ICSS Instances  | PRU-ICSS Revision |
-+=============+=====================+===================+
-| icev2AM335x | 1                   | REV1              |
-+-------------+---------------------+-------------------+
-| idkAM437x   | 2                   | REV1              |
-+-------------+---------------------+-------------------+
-| idkAM574x   | 2                   | REV2              |
-+-------------+---------------------+-------------------+
-| idkAM572x   | 2                   | REV2              |
-+-------------+---------------------+-------------------+
-
-|
-
-.. rubric::  icev2AM335x
-   :name: icev2am335x
-
-+---------+-------+----------+--------------+---------------------+--------+-------+
-| ICSS    | PRU   | Instance |Functional Pin|PRU GPIO Pins        |EVM Port|EVM Pin|
-+=========+=======+==========+==============+=====================+========+=======+
-|         |       |          | SCL          |pr1_pru0_pru_r30_1   | J3     | 14    |
-|         |       |          +--------------+---------------------+--------+-------+
-| ICSS1   | PRU0  | I2C0     |              |pr1_edio_data_out7   | J4     | 21    |
-|         |       |          | SDA          +---------------------+--------+-------+
-|         |       |          |              |pr1_pru0_pru_r31_0   | J3     | 12    |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-
-.. rubric::  idkAM437x
-   :name: idkAM437x
-
-+---------+-------+----------+--------------+---------------------+--------+-------+
-| ICSS    | PRU   | Instance |Functional Pin|PRU GPIO Pins        |EVM Port|EVM Pin|
-+=========+=======+==========+==============+=====================+========+=======+
-|         |       |          | SCL          |pr1_pru0_pru_r30_8   | J3     | 6     |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       | I2C0     |              |pr1_edio_data_out0   | J3     | 5     |
-|         |       |          | SDA          +---------------------+--------+-------+
-|         |       |          |              |pr1_pru0_pru_r31_9   | J3     | 8     |
-| ICSS1   | PRU0  +----------+--------------+---------------------+--------+-------+
-|         |       |          | SCL          |pr1_pru0_pru_r30_10  | J16    | 46    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       | I2C1     |              |pr1_edio_data_out1   | J3     | 7     |
-|         |       |          | SDA          +---------------------+--------+-------+
-|         |       |          |              |pr1_pru0_pru_r31_11  | J16    | 48    |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-|         |       |          | SCL          |pr0_pru0_pru_r30_8   | J16    | 56    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       | I2C0     |              |pr1_edio_data_out0   | J3     | 5     |
-|         |       |          | SDA          +---------------------+--------+-------+
-|         |       |          |              |pr0_pru0_pru_r31_9   | J16    | 37    |
-| ICSS0   | PRU0  +----------+--------------+---------------------+--------+-------+
-|         |       |          | SCL          |pr0_pru0_pru_r30_10  | J16    | 38    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       | I2C1     |              |pr1_edio_data_out1   | J3     | 7     |
-|         |       |          | SDA          +---------------------+--------+-------+
-|         |       |          |              |pr0_pru0_pru_r31_11  | J16    | 58    |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-
-.. rubric::  idkAM572x/idkAM574x
-   :name: idkAM572x-idkAM574x
-
-+---------+-------+----------+--------------+---------------------+--------+-------+
-| ICSS    | PRU   | Instance |Functional Pin|PRU GPIO Pins        |EVM Port|EVM Pin|
-+=========+=======+==========+==============+=====================+========+=======+
-|         |       |          | SCL          |pr1_pru1_gpo1        | J21    | 5     |
-|         |       |          +--------------+---------------------+--------+-------+
-| ICSS1   | PRU0  | I2C0     |              |pr1_edio_data_out1   | J46    | 4     |
-|         |       |          | SDA          +---------------------+--------+-------+
-|         |       |          |              |pr1_pru1_gpi0        | J21    | 3     |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-
-|
-
-I2C FIRMWARE Example
-====================
-
-Sample code for I2C transaction:
-
-.. code-block:: c
-
-    /* Refer to I2C FW Example for details */
-    ...
-
-    /* Initialize the I2C FW configuration */
-    I2C_socInitFwCfg();
-
-    /* Get the default I2C init configuration */
-    I2C_socGetFwCfg(I2C_TEST_INSTANCE1, &i2c_cfg);
-
-    /* Modify the default I2C configurations if necessary */
-
-    /* Set the default I2C init configurations */
-    I2C_socSetFwCfg(I2C_TEST_INSTANCE1, &i2c_cfg);
-    ...
-
-    Board_init(boardCfg);
-    ...
-
-    I2C_init();
-
-    handle = I2C_open(I2C_TEST_INSTANCE1, &i2cParams);
-    ...
-
-    /* Initiate I2C transfers */
-    I2C_transactionInit(&i2cTransaction);
-    i2cTransaction.targetAddress = I2C_EEPROM_ADDR;
-    ...
-
-    status = I2C_transfer(handle, &i2cTransaction);
-    if (status!= I2C_STS_SUCCESS) {
-        /* I2C transaction failed */
-    }
-
-Sample code for SMBus transaction:
-
-.. code-block:: c
-
-    /* Refer to I2C FW Test for details */
-    ...
-
-    testCmd.transferCmd = SMBUS_WRITE_BYTE_CMD;
-    testCmd.cmdCode = WRITE_SMBUS_COMMAND_CODE;
-    controlStatus = I2C_control(handle, I2C_CMD_SMBUS_TYPE, ((void*)&testCmd));
-    I2C_transactionInit(&i2cTransaction);
-    ...
-
-    status = I2C_transfer(handle, &i2cTransaction);
-    if (status != I2C_STS_SUCCESS) {
-        /* I2C transaction failed */
-    } 
-
-|
-
-.. rubric::  Examples List
-   :name: examples-list
-
-Refer to the Release Notes for details concerning I2C support across different EVMs.
-
-+-----------------------+-----------------------+------------------------+
-| Name                  | Description           | Expected Results       |
-+=======================+=======================+========================+
-| I2C_FwExample         | Driver Firmware       | Status messages will   |
-|                       | example application   | be displayed on        |
-|                       | for I2C FW instances  | console based based    |
-|                       |                       | on pass/fail criteria: |
-|                       |                       |                        |
-|                       |                       | **Pass criteria:**     |
-|                       |                       |                        |
-|                       |                       | I2C Test: Instance:    |
-|                       |                       | Baud Rate 100KHz:      |
-|                       |                       |                        |
-|                       |                       | All tests have         |
-|                       |                       | passed.                |
-+-----------------------+-----------------------+------------------------+
-
-|
-
-.. rubric::  Firmware Design Guide
-   :name: firmware-design-guide
-
-+-----------------------------------+--------------------------------------------------------------------------+
-| **Document**                      | **Location**                                                             |
-+-----------------------------------+--------------------------------------------------------------------------+
-| I2C FIRMWARE Design Guide         | <PDK>/packages/ti/drv/i2c/firmware/icss_i2c/docs/I2C_FW_DESIGN_GUIDE.pdf |
-+-----------------------------------+--------------------------------------------------------------------------+
-
-**NOTE: For normal use of I2C FW, there is no need to refer to the design guide.
-This document can be cosulted in case of interest in details of internal firmware
-operation, or a desire to modify the firmware.**
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-EMAC_FIRMWARES.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-EMAC_FIRMWARES.rst
deleted file mode 100644
index d96a0dfa7..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-EMAC_FIRMWARES.rst
+++ /dev/null
@@ -1,254 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_ICSS-EMAC_FIRMWARES
-
-Introduction
-=============
-
-| The ICSS FIRMWARES serves as example to implement various network
-  functionalities. Package includes source release for Dual_emac and
-  basic switch firmwares.
-
-|
-
-DUAL_EMAC
-=========
-
-ICSS DUAL EMAC FIRMWARE is a single port Ethernet MAC (Media Access
-Control) i.e. Layer 2 of OSI Model. It implements a 2 port ethernet mac
-supporting 10/100 Mbps. DUAL EMAC FIRMWARE is standardized to IEEE 802.1
-Ethernet Standards. Primary use case of the protocol is to demonstrate
-basic ethernet functionality via both PRU cores on 10/100 Mbit Ethernet
-cable. ICSS DUAL EMAC FIRMWARE can be used independently on two PRU's to
-implement two independent MAC's with two different MAC addresses and two
-different IP addresses. To provide an analogy, this is somewhat similar
-to a two port Ethernet PCIe NIC card on a PC.Ethernet interface in this
-case is available along with Host processor on a single SoC. Following
-are high level features:
-
-+-----------------------------------+-----------------------------------+
-| **Requirements**                  | **Remarks**                       |
-+-----------------------------------+-----------------------------------+
-| 1 ms buffering per port           | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Host IRQ                          | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Ethernet QoS                      | With 2 queues instead of 8. So,   |
-|                                   | it is not a standard Ethernet QoS |
-|                                   | implementation.                   |
-+-----------------------------------+-----------------------------------+
-| Statistics                        | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Storm Prevention                  | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Promiscuous Mode                  | Supported                         |
-+-----------------------------------+-----------------------------------+
-| TTS (Time Triggered Send)         | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Error Handling                    | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Multicast filtering               | Supported                         |
-+-----------------------------------+-----------------------------------+
-| VLAN filtering                    | Supported                         |
-+-----------------------------------+-----------------------------------+
-| PTP Handling                      | Supported                         |
-+-----------------------------------+-----------------------------------+
-
-|
-
-SWITCH
-======
-
-ICSS SWITCH FIRMWARE is a three port learning Ethernet switch i.e. Layer
-2 of OSI Model. It implements a 2 port cut through ethernet switch
-supporting at 100 Mbps. SWITCH FIRMWARE is standardized to IEEE 802.1
-Ethernet Standards. The primary use case of the protocol is to use
-Ethernet to automate applications which require short cut-through
-latency and low hardware costs. ICSS SWITCH FIRMWARE uses two PRU to
-implement three port Ethernet switch with one single MAC and IP address.
-To provide an analogy, this is somewhat standard network switch only
-here the network functionality is available to the host core within the
-single SOC. The following are the high level features it supports.
-
-+-----------------------------------+-----------------------------------+
-| **Requirements**                  | **Remarks**                       |
-+-----------------------------------+-----------------------------------+
-| Cut-Through                       | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Store and Forward                 | Supported                         |
-+-----------------------------------+-----------------------------------+
-| 1 ms buffering per port           | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Host IRQ                          | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Ethernet QoS                      | With 4 queues instead of 8. So,   |
-|                                   | it is not a standard Ethernet QoS |
-|                                   | implementation.                   |
-+-----------------------------------+-----------------------------------+
-| 802.1 learning switch             | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Statistics                        | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Queue-Contention Handling on each | Supported                         |
-| port                              |                                   |
-+-----------------------------------+-----------------------------------+
-| Three-Port Switch                 | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Storm Prevention                  | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Error Handling                    | Supported                         |
-+-----------------------------------+-----------------------------------+
-
-|
-
-Code Organization
-=================
-
-+-----------------------+-----------------------------------+-----------------------+
-| **Requirements**      | **Location in SDK**               | **Remarks**           |
-+-----------------------+-----------------------------------+-----------------------+
-| Common baseline code  | <PDK>/packages/ti/drv             | common code for       |
-|                       | /icss_emac/firmware/icss_dualemac | dual_emac and switch  |
-+-----------------------+-----------------------------------+-----------------------+
-| DUAL_EMAC             | <PDK>/packages/ti/drv             | dual_emac firmware    |
-|                       | /icss_emac/firmware/icss_dualemac | specific code         |
-+-----------------------+-----------------------------------+-----------------------+
-| SWITCH                | <PDK>/packages/ti/drv             | switch firmware       |
-|                       | /icss_emac/firmware/icss_switch   | specific code         |
-+-----------------------+-----------------------------------+-----------------------+
-
-|
-
-Firmware Build Instruction
-==========================
-
-Build instruction from Processor SDK Release package
----------------------------------------------------
-
-.. rubric:: Pre-requisites to Building
-   :name: pre-requisites-to-building
-
-::
-
-    Refer to the Processor SDK RTOS Building page for information on setting up build environment.
-
-.. rubric:: Compiling ICSS-EMAC FIRMWARES
-   :name: compiling-icss-emac-firmwares
-
--  cd <PDK>/packages/ti/drv/icss_emac
--  make firm
-
-Firmware binaries at the end of the build will be located at:
-
--  <PDK>/packages/ti/drv/icss_emac/firmware/<FIRMWARE_TYPE>/bin/<SOC>/<HOST_CORE>/<REVISION>
-
--  <FIRMWARE_TYPE> indicates the firmware type i.e. icss_dualemac for
-   DUAL_EMAC or icss_switch for SWITCH
-
--  <SOC> indicates the SOC type.
-
--  <HOST_CORE> indicates the Host core type on which the built binary
-   can be loaded.
-
--  <REVISION> indicates the revision of the firmware binary based on
-   core. (There are 2 revision of PRU ICSS core)
-
-|
-
-Build instruction from GIT
---------------------------
-
-Following are the steps for building firmware from any external
-environment outside PROC SDK RTOS.
-
--  Creation of directories
-
-   -  Create a working directory e.g. <WORK_DIR>
-   -  Create a new directory named ti inside working directory. i.e.
-      <WORK_DIR/ti>
-   -  Create a new directory called drv inside ti. i.e.
-      <WORK_DIR/ti/drv>
-
--  Clone of Repos
-
-   -  Git clone pdk build repo into ti directory. i.e.
-      <WORK_DIR/ti/build>
-   -  Git clone icss_emac repo into ti/drv directory. i.e.
-      <WORK_DIR/ti/drv/icss_emac>
-
--  Setting Environment Variables
-
-   -  Export CLPRU install path. i.e. export CL_PRU_INSTALL_PATH=clpru
-      toolchain directory
-   -  Export pdk install path. i.e. export PDK_INSTALL_PATH=<WORK_DIR>
-   -  Export LIMIT_SOCS Variable i.e. LIMIT_SOCS=<SOC> [Optional for
-      limiting to some SOCs]
-
--  Build command
-
-   -  Run make firm/firm_clean to build/clean firmware from icss_emac
-      directory i.e. <WORK_DIR/ti/drv/icss_emac>
-
--  Generated binaries
-
-   -  the firmware binaries which will be located in
-      <WORK_DIR/ti/drv/icss_emac/firmware/<FIRMWARE_TYPE>/bin/<SOC>/<HOST_CORE>/<REVISION>>
-
-|
-
-Supported EVMs
-==============
-
-The following is a list of EVMS supported and the PRU-ICSS ethernet
-ports to be used:
-
-+-----------------------+-----------------------+-----------------------+
-| EVM Name              | PRU-ICSS Instance     | Supported PRU ICSS    |
-|                       |                       | core revision         |
-+-----------------------+-----------------------+-----------------------+
-| icev2AM335x           | PRU-ICSS instance 1   | REV1                  |
-+-----------------------+-----------------------+-----------------------+
-| idkAM437x             | PRU-ICSS instance 2   | REV1                  |
-+-----------------------+-----------------------+-----------------------+
-| idkAM571x             | PRU-ICSS instance 2   | REV2                  |
-+-----------------------+-----------------------+-----------------------+
-| idkAM572x             | PRU-ICSS instance 2   | REV1 & REV2 (Earlier  |
-|                       |                       | version of AM572x soc |
-|                       |                       | had REV1 pru cores    |
-|                       |                       | while later had REV2  |
-|                       |                       | pru cores)            |
-+-----------------------+-----------------------+-----------------------+
-| iceK2G                | PRU-ICSS instance 2   | REV2                  |
-+-----------------------+-----------------------+-----------------------+
-
-|
-
-Running ICSS-EMAC FIRMWARES Example
-===================================
-
-Please go through the following page for example demonstrating the use
-of the firmware via icss-emac driver.
-`[1] <index_device_drv.html#icss-emac>`__
-
-|
-
-.. rubric:: Firmware Design Guide
-   :name: firmware-design-guide
-
-+-----------------------------------+-----------------------------------+
-| **Document**                      | **Location**                      |
-+-----------------------------------+-----------------------------------+
-| ICSS DUAL EMAC FIRMWARE Design    | <PDK>/packages/ti/drv/icss_emac/f |
-| Guide                             | irmware/icss_dualemac/docs/ICSS_D |
-|                                   | UAL_EMAC_Firmware_Design_Guide.pd |
-|                                   | f                                 |
-+-----------------------------------+-----------------------------------+
-| ICSS SWITCH FIRMWARE Design Guide | <PDK>/packages/ti/drv/icss_emac/f |
-|                                   | irmware/icss_switch/docs/ICSS_SWI |
-|                                   | TCH_Firmware_Design_Guide.pdf     |
-+-----------------------------------+-----------------------------------+
-
-**NOTE: For normal use case, there is no need to refer this document.
-Unless you wish to go through the internal working for firmware and/or
-wanted to modify it.**
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-G-EMAC_FIRMWARES.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-G-EMAC_FIRMWARES.rst
deleted file mode 100644
index d4b5988f9..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-G-EMAC_FIRMWARES.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_ICSS-G-EMAC_FIRMWARES
-
-Introduction
-=============
-| The ICSS-G FIRMWARE serves as example to implement various network
-  functionalities. Package includes source release for DUAL EMAC
-
-|
-
-DUAL_EMAC
-=========
-
-ICSS DUAL EMAC FIRMWARE is a single port Ethernet MAC (Media Access
-Control) i.e. Layer 2 of OSI Model. It implements a 2 port Ethernet
-mac supporting 100Mbps and 1Gbps. DUAL MAC FIRMWARE is standardized
-to IEEE 802.1 Ethernet Standards. Primary use case of the protocol
-is to demonstrate basic Ethernet functionality via both PRU/RTU cores.
-ICSS-G DUAL EMAC FIRMWARE can be used independently on two PRUs to
-implement two independent MACs with two different MAC addresses
-and two different IP addresses.
-
-Following are high level features:
-
-+-----------------------------------+-----------------------------------+
-| **Requirements**                  | **Remarks**                       |
-+-----------------------------------+-----------------------------------+
-| 4 egress DMA threads per port     | Supported                         |
-+-----------------------------------+-----------------------------------+
-| 4 ingress “buckets” per port      | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Statistics                        | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Storm Prevention                  | Future                            |
-+-----------------------------------+-----------------------------------+
-| Promiscuous Mode                  | Supported                         |
-+-----------------------------------+-----------------------------------+
-| TTS (Time Triggered Send)         | Future                            |
-+-----------------------------------+-----------------------------------+
-| Error Handling                    | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Multicast filtering               | Supported                         |
-+-----------------------------------+-----------------------------------+
-| VLAN filtering                    | Future                            |
-+-----------------------------------+-----------------------------------+
-| PTP Handling                      | Supported                         |
-+-----------------------------------+-----------------------------------+
-
-|
-
-
-Firmware Code Location and Build Instruction
-============================================
-
-Firmware is located at <PDK>packages/ti/drv/emac/firmware/icss_eth/src directory.
-
-The CLPRU toolchain has to be used to build the firmware. The toolchain can be
-downloaded from <http://software-dl.ti.com/codegen/esd/cgt_public_sw/PRU/2.2.1/ti_cgt_pru_2.2.1_linux_installer_x86.bin>
-
-To build the firmware:
-
-- cd to <PDK>packages/ti/drv/emac/firmware/icss_eth/src directory
-
-- make CLPRU_INSTALL_PATH=<dir_where_the_toolchain_installed>.
-
-The firmware will be located in the <PDK>packages/ti/drv/emac/firmware/icss_eth/src/dm directory.
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_IOLINK_FIRMWARE.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_IOLINK_FIRMWARE.rst
deleted file mode 100644
index 9f0590600..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_IOLINK_FIRMWARE.rst
+++ /dev/null
@@ -1,184 +0,0 @@
-.. http://ap-fpdsp-swapps.dal.design.ti.com/index.php/Processor_SDK_RTOS_IOLINK_FIRMWARE
-
-Introduction
-============
-
-| PRU-ICSS IOLINK serves as an example for firmware-based IOLINK Master
-  Frame Handler support. The Processor SDK package includes
-  full source code for IOLINK FW.
-
-|
-
-FIRMWARE FEATURES
-=================
-
-IOLINK FW supports 8 channels per IO-Link instance in a single PRU core.
-Each channel uses three GPI/O pins from the PRU-ICSS module. The IOLINK
-TXD and TX_EN pins are implemented using two GPO pins, the IOLINK RXD
-pin is implemented using a single GPI pin.
-
-Following are high-level IOLINK FW features:
-
-+-----------------------------------+-----------------------------------+
-| **Feature**                       | **Remarks**                       |
-+-----------------------------------+-----------------------------------+
-| No. of instances                  | 1                                 |
-+-----------------------------------+-----------------------------------+
-| No. of channels per instance      | 8                                 |
-+-----------------------------------+-----------------------------------+
-| Baud Rate                         | COM1/COM2/COM3                    |
-+-----------------------------------+-----------------------------------+
-| Minumum Cycle Time                | 400 µs                            |
-+-----------------------------------+-----------------------------------+
-| Maximum Cycle Time                | 132 ms                            |
-+-----------------------------------+-----------------------------------+
-| Channel Independent Cycle Time    | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Receive Buffer                    | 1 buffer of 68 bytes              |
-+-----------------------------------+-----------------------------------+
-| Transmit Buffer                   | 2 buffer of 68 bytes              |
-+-----------------------------------+-----------------------------------+
-| Channel Independent Time Control  | Supported                         |
-| and Monitoring                    |                                   |
-+-----------------------------------+-----------------------------------+
-| Receive Glitch Filter and 8x      | Supported                         |
-| Oversampling                      |                                   |
-+-----------------------------------+-----------------------------------+
-| Receive Tolerance (per baud rate) | 3%                                |
-+-----------------------------------+-----------------------------------+
-| Programmable Max Response Time TA | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Start/Restart/Stop                | Supported                         |
-+-----------------------------------+-----------------------------------+
-| Start Bit                         | 1-bit                             |
-+-----------------------------------+-----------------------------------+
-| Stop Bit                          | 1-bit                             |
-+-----------------------------------+-----------------------------------+
-| Data Length                       | 8-bit                             |
-+-----------------------------------+-----------------------------------+
-| Parity Check                      | Even Parity                       |
-+-----------------------------------+-----------------------------------+
-| Interrupts that the CPU can use   | 1                                 |
-+-----------------------------------+-----------------------------------+
-
-
-Firmware Organization
-=====================
-
-+-------------------------+--------------------------------------------------------+
-| **FW Item**             | **Directory**                                          |
-+-------------------------+--------------------------------------------------------+
-| Source code             | <PDK>/packages/ti/drv/iolink/firmware/icss_iolink/src  |
-+-------------------------+--------------------------------------------------------+
-| Design Guide            | <PDK>/packages/ti/drv/iolink/docs                      |
-+-------------------------+--------------------------------------------------------+
-| Firmware binaries       | <PDK>/packages/ti/drv/iolink/firmware/icss_iolink/bin  |
-+-------------------------+--------------------------------------------------------+
-
-|
-
-Firmware Build Instruction
-==========================
-
-Build instruction from Processor SDK Release package
-----------------------------------------------------
-
-.. rubric::  Pre-requisites to Building
-   :name: pre-requisites-to-building
-
-Refer to the Processor SDK RTOS Building page for information on setting up the build environment.
-
-.. rubric::  Compiling IOLINK FIRMWARE
-   :name: compiling-iolink-firmware
-
--  cd <PDK>/packages/ti/drv/iolink
--  make firm
-
-Firmware binaries at the end of the build will be located at:
-
--  <PDK>/packages/ti/drv/iolink/firmware/<FIRMWARE_TYPE>/bin/<SOC>/<HOST_CORE>/<REVISION>
-
--  <FIRMWARE_TYPE> indicates the firmware type i.e. icss_iolink
-
--  <SOC> indicates the SOC type, e.g. am437x
-
--  <HOST_CORE> indicates the Host core type on which the built binary
-   can be loaded, e.g. a9host
-
--  <REVISION> indicates the revision of the firmware binary based on
-   core (there are 2 revision of PRU-ICSS core), e.g. REV1.
-
-|
-
-Build instruction for GIT
--------------------------
-
-Following are the steps for building firmware from any external
-environment outside Processor SDK RTOS package.
-
--  Creation of directories
-
-   -  Create a working directory e.g. <WORK_DIR>
-   -  Create a new directory named ti inside working directory. i.e.
-      <WORK_DIR/ti>
-   -  Create a new directory called drv inside ti. i.e.
-      <WORK_DIR/ti/drv>
-
--  Clone of Repos
-
-   -  Git clone pdk build repo into ti directory. i.e.
-      <WORK_DIR/ti/build>
-   -  Git clone iolink repo into ti/drv directory. i.e.
-      <WORK_DIR/ti/drv/iolink>
-
--  Setting Environment Variables
-
-   -  Export CLPRU install path. i.e. export CL_PRU_INSTALL_PATH=clpru
-      toolchain directory
-   -  Export pdk install path. i.e. export PDK_INSTALL_PATH=<WORK_DIR>
-   -  Export LIMIT_SOCS Variable i.e. LIMIT_SOCS=<SOC> [Optional for
-      limiting to some SOCs]
-
--  Build command
-
-   -  Run make firm_clean/firm to clean/build firmware from iolink
-      directory i.e. <WORK_DIR/ti/drv/iolink>
-
--  Generated binaries
-
-   -  the firmware binaries which will be located in
-      <WORK_DIR/ti/drv/iolink/firmware/<FIRMWARE_TYPE>/bin/<SOC>/<HOST_CORE>/<REVISION>>
-
-|
-
-Supported EVMs
-==============
-
-Supported EVMs are listed below.
-
-+-------------+---------------------+-------------------+
-| EVM Name    | PRU-ICSS Instances  | PRU-ICSS Revision |
-+=============+=====================+===================+
-| idkAM437x   | ICSS0               | REV1              |
-+-------------+---------------------+-------------------+
-
-
-
-|
-
-
-.. rubric::  Firmware Design Guide
-   :name: firmware-design-guide
-
-+-----------------------------------+--------------------------------------------------------------------------+
-| **Document**                      | **Location**                                                             |
-+-----------------------------------+--------------------------------------------------------------------------+
-| IOLINK FIRMWARE Design Guide      | <PDK>/packages/ti/drv/iolink/docs/IOLINK_FW_DESIGN_GUIDE.pdf             |
-+-----------------------------------+--------------------------------------------------------------------------+
-
-**NOTE: For normal use of IOLINK FW, there is no need to refer to the design guide.
-This document can be cosulted in case of interest in details of internal firmware
-operation, or a desire to modify the firmware.**
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_PRU_ICSS_SORTE.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_PRU_ICSS_SORTE.rst
deleted file mode 100644
index 912d80d80..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_PRU_ICSS_SORTE.rst
+++ /dev/null
@@ -1,177 +0,0 @@
-
-Introduction
-============
-
-| The Simple Open Real-time Ethernet protocol (SORTE) serves as an
-  example for Texas Instruments programmable approach to real-time
-  communication for input/output (IO) networks with a maximum of 254
-  devices. This protocol is fully documented and released in source
-  code. It is open to customers to learn, adapt and enhance the protocol
-  for their application requirements. SORTE is not bound to a given
-  communication standard and breaks some of the limits of existing
-  standards such as minimum Ethernet frame size, addressing and error
-  detection. The primary use case of the protocol is to connect
-  different end-equipment using Ethernet physical layer devices and 100
-  Mbit Ethernet cable.
-
-Protocol Overview
-=================
-
-The SORTE protocol is a TI-developed industrial Ethernet protocol that
-supports 4-µs cycle time. The SORTE protocol operates on the PRU-ICSS,
-which is an industrial peripheral within Sitara and KeyStone processors
-from Texas Instruments. SORTE protocol operates exclusively on the
-PRU-ICSS; therefore, the ARM Cortex-A8, A9 or A15 processors – depending
-on the device family – are available for industrial applications. The
-SORTE protocol differentiate between two network components: the master
-and one or more slave devices. For in depth details of the protocol
-please refer to the the design documents as listed in the References
-section below.
-
-Code Organization
-=================
-
-THE SORTE ARM application and firmware sources can be found under the
-following directory :
-
-**<PDK>/packages/ti/drv/pruss/example/apps/sorte/**
-
-Refer to the README.txt in this directory for details of directory
-layout.
-
-In addition, there is a README.txt which provides high-level over of how
-the protocol is implmented for master and slave device network
-compoments which can be found at:
-
-**<PDK>/packages/ti/drv/pruss/example/apps/sorte/firmware/src/master/README.txt**
-
-**<PDK>/packages/ti/drv/pruss/example/apps/sorte/firmware/src/slave/README.txt**
-
-|
-
-Building the Examples
-=====================
-
-Pre-requisites to Building
---------------------------
-
-#. Set your environment using pdksetupenv.sh. Building the Firmware
-   binaries and ARM application uses the same environment variables as
-   the pruss driver library build. Refer to the `Processor SDK RTOS
-   Building <index_overview.html#building-the-sdk>`__ page for
-   information on setting up your build environment.
-
-Compiling the PRUSS SORTE Firmware
-----------------------------------
-
-To build the SORTE firmware binaries:
-
-#. **cd <PDK>/packages/ti/drv/pruss**
-#. **make firm**
-
-This will make the firmware binaries which will be located in:
-
-**<PDK>/packages/ti/drv/pruss/example/apps/sorte/firmware/bin/<BOARD>**
-
-|
-
-Compiling the PRUSS SORTE Application
--------------------------------------
-
-To build the SORTE ARM applications:
-
-#. **cd <PDK>/packages/ti/drv/pruss**
-#. **make apps**
-
-This will make the ARM applications for both master and slave device
-which will be located in:
-
-**<PDK>/packages/ti/drv/pruss/example/apps/sorte/slave<BOARD>**
-
-**<PDK>/packages/ti/drv/pruss/example/apps/sorte/master<BOARD>**
-
-|
-
-Supported EVMs
-==============
-
-The following is a list of EVMS supported and the PRU-ICSS ethernet
-ports to be used:
-
-+--------------+-----------------------+-----------+-----------+
-| **EVM Name** | **PRU-ICSS Instance** | **Port0** | **Port1** |
-+--------------+-----------------------+-----------+-----------+
-| icev2AM335x  | PRU-ICSS instance 1   | J2        | J1        |
-+--------------+-----------------------+-----------+-----------+
-| idkAM437x    | PRU-ICSS instance 2   | J6        | J9        |
-+--------------+-----------------------+-----------+-----------+
-| idkAM571x    | PRU-ICSS instance 2   | J6        | J8        |
-+--------------+-----------------------+-----------+-----------+
-| idkAM572x    | PRU-ICSS instance 2   | J6        | J8        |
-+--------------+-----------------------+-----------+-----------+
-| iceK2G       | PRU-ICSS instance 2   | J8A       | J8B       |
-+--------------+-----------------------+-----------+-----------+
-
-|
-
-Running the PRUSS SORTE Example
-===============================
-
-In order to run the SORTE applications, you will require 1 EVM running
-as master and 2 EVMs running as slave(slave1/slave2). Use CCS to load
-and run the master and slave applications respectively.
-
-Prior to running the applications its best to connect the EVMS as
-follows:
-
-Connect master Port0 to slave1 Port0. Connect slave1 Port1 to slave2
-Port0.
-
-After loading the application binaries from CCS, run the master first,
-then run the slave2, finally run the slave1 with Port0 connecting to the
-the master Port 0.
-
-Note that the master device will wait until it discovers 2 slave devices
-in the network. UART console on the master will print the following
-until 2 slave devices are detected:
-
-**sorte master: waiting for atleast 2 SLAVE devices connected**
-
-Once 2 slave devices are detected by the master, the following print
-will be seen on UART console and master will continue with state machine
-and protocol processing:
-
-**sorte master: 2 SLAVE devices connected**
-
-The slave device via the UART console will continuosly display the
-number of packets its received during input output exchange state of the
-protocol until pass criteria is reached as follows(as an example):
-
-**sorte slave: test in progress: current receive packet count: 35000**
-
-**sorte slave: test in progress: current receive packet count: 40000**
-
-Once pass criteria number of packets have been received, the following
-print will be displayed on UART console:
-
-**All tests have passed**
-
-|
-
-|
-
-Additional Reference
-====================
-
-+-----------------------------------+-----------------------------------+
-| **Document**                      | **Location**                      |
-+-----------------------------------+-----------------------------------+
-| SORTE Master with PRU-ICSS        | http://www.ti.com/tool/TIDEP-0085 |
-| Reference Design                  |                                   |
-+-----------------------------------+-----------------------------------+
-| SORTE Slave Device with PRU-ICSS  | http://www.ti.com/tool/TIDEP-0086 |
-| Reference Design                  |                                   |
-+-----------------------------------+-----------------------------------+
-
-|
-
diff --git a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_UART_FIRMWARE.rst b/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_UART_FIRMWARE.rst
deleted file mode 100644
index 56517822a..000000000
--- a/source/rtos/PDK_Platform_Software/PRU_ICSS_Drivers/_UART_FIRMWARE.rst
+++ /dev/null
@@ -1,305 +0,0 @@
-.. http://ap-fpdsp-swapps.dal.design.ti.com/index.php/Processor_SDK_RTOS_UART_FIRMWARE
-
-Introduction
-============
-
-| PRU-ICSS UART serves as an example for PRU firmware-based UART peripheral
-  support. The UART firmware (UART FW) allows additional UART instances for SOCs
-  beyond those supported by SOC hardware. The Processor SDK package includes
-  full source code for UART FW.
-
-|
-
-FIRMWARE FEATURES
-=================
-
-The following UART specifications are supported by the PRU UART firmware:
-
-- Up to 3 UARTs are supported per PRU with the following configuration options
-    - Baud rate: common baud rates up to 115200
-    - Bits per transfer: 5-9 bit characters
-    - Number of stop bits: 1, 1.5, 2
-    - Parity: even, odd, none
-    - Flow control: HW, none (SW flow control currently unsupported)
-    - Full-duplex communication
-
-- Each UART can simultaneously support different configurations
-    - UART0 can have a different baud rate, number of stop bits, etc. when
-      compared to UART1 or UART2 in the same PRU
-
-- The firmware is self-contained in a single PRU
-    - The firmware does not use shared resources within an ICSS including IEP Timer and Scratchpad
-    - In case 3 or less UART instances are required, only one PRU core is required for the UART firmware
-
-The table below shows a comparison of the features supported by the UART
-firmware with those available on hardware IP.
-
-+------------------------------+-------------------------------+----------------------------+
-| **UART Supported Feature**   | **Hardware IP**               | **Software IP (Firmware)** |
-+------------------------------+-------------------------------+----------------------------+
-| Number of hardware instances | SoC dependent                 | 3 (per PRU)                |
-+------------------------------+-------------------------------+----------------------------+
-| Baud rates                   | SoC dependent (up to 12 Mbps) | All common baud rates      |
-|                              |                               | between 300-115200         |
-+------------------------------+-------------------------------+----------------------------+
-| Bits per character           | 5-8 bits                      | 5-9 bits                   |
-+------------------------------+-------------------------------+----------------------------+
-| Number of stop bits          | 1, 1.5, 2                     | 1, 1.5, 2                  |
-+------------------------------+-------------------------------+----------------------------+
-| Parity types                 | Even, Odd, Mark, Space, none  | Even, Odd, none            |
-+------------------------------+-------------------------------+----------------------------+
-| Flow control types           | HW, SW, none                  | HW, none                   |
-+------------------------------+-------------------------------+----------------------------+
-
-Firmware Organization
-=====================
-
-+-------------------------+---------------------------------------------------+
-| **FW Item**             | **Directory**                                     |
-+-------------------------+---------------------------------------------------+
-| Source code             | <PDK>/packages/ti/drv/uart/firmware/icss_i2c/src  |
-+-------------------------+---------------------------------------------------+
-| Design Guide            | <PDK>/packages/ti/drv/uart/docs                   |
-+-------------------------+---------------------------------------------------+
-
-|
-
-Firmware Build Instructions
-===========================
-
-Build instructions from Processor SDK Release package
------------------------------------------------------
-
-.. rubric::  Pre-requisites to Building
-   :name: uart-pre-requisites-to-building
-
-Refer to the Processor SDK RTOS Building page for information on setting up the build environment.
-
-.. rubric::  Compiling UART Firmware
-   :name: uart-compiling-firmware
-
--  cd <PDK>/packages/ti/drv/uart
--  make firm
-
-.. rubric::  Compiling UART LLD
-   :name: uart-compiling-driver
-
--  cd <PDK>/packages/ti/drv/uart
--  make lib
-
-.. rubric::  Compiling UART Driver & Firmware
-   :name: uart-compiling-driver-firmware
-
--  cd <PDK>/packages/
--  make uart
-
-
-Firmware binaries at the end of the firmware build will be located at:
-
--  <PDK>/packages/ti/drv/uart/firmware/<FIRMWARE_TYPE>/bin/<SOC>/<HOST_CORE>/<REVISION>
-
--  <FIRMWARE_TYPE> indicates the firmware type i.e. icss_uart
-
--  <SOC> indicates the SOC type, e.g. am335x
-
--  <HOST_CORE> indicates the Host core type on which the built binary
-   can be loaded, e.g. a8host
-
--  <REVISION> indicates the revision of the firmware binary based on
-   core (there are 2 revision of PRU-ICSS core), e.g. REV1.
-
-|
-
-Supported EVMs
-==============
-
-Supported EVMs and pin configurations for these EVMs are listed below. See the design document in ``<PDK>/packages/ti/drv/uart/docs/`` for more information.
-
-+-------------+---------------------+-------------------+
-| EVM Name    | PRU-ICSS Instances  | PRU-ICSS Revision |
-+=============+=====================+===================+
-| bbbAM335x   | 6                   | REV1              |
-+-------------+---------------------+-------------------+
-
-|
-
-.. rubric::  bbbAM335x
-   :name: bbbAM335x
-
-+---------+-------+----------+--------------+---------------------+--------+-------+
-| ICSS    | PRU   | Instance |Functional Pin|PRU GPIO Pins        |EVM Port|EVM Pin|
-+=========+=======+==========+==============+=====================+========+=======+
-|         |       |          | TX           |pr1_pru0_pru_r30_0   | P9     | 31    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RX           |pr1_pru0_pru_r31_1   | P9     | 29    |
-| ICSS1   | PRU0  | UART0    +--------------+---------------------+--------+-------+
-|         |       |          | CTS          |         \-          |  \-    |  \-   |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RTS          |         \-          |  \-    |  \-   |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-|         |       |          | TX           |pr1_pru0_pru_r30_2   | P9     | 30    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RX           |pr1_pru0_pru_r31_3   | P9     | 28    |
-| ICSS1   | PRU0  | UART1    +--------------+---------------------+--------+-------+
-|         |       |          | CTS          |         \-          |  \-    |  \-   |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RTS          |         \-          |  \-    |  \-   |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-|         |       |          | TX           |pr1_pru0_pru_r30_5   | P9     | 27    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RX           |pr1_pru0_pru_r31_7   | P9     | 25    |
-| ICSS1   | PRU0  | UART2    +--------------+---------------------+--------+-------+
-|         |       |          | CTS          |         \-          |  \-    |  \-   |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RTS          |         \-          |  \-    |  \-   |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-|         |       |          | TX           |pr1_pru0_pru_r30_0   | P8     | 45    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RX           |pr1_pru0_pru_r31_1   | P8     | 46    |
-| ICSS1   | PRU1  | UART0    +--------------+---------------------+--------+-------+
-|         |       |          | CTS          |pr1_pru1_pru_r31_2   | P8     | 43    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RTS          |pr1_pru1_pru_r30_3   | P8     | 44    |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-|         |       |          | TX           |pr1_pru0_pru_r30_4   | P8     | 41    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RX           |pr1_pru0_pru_r31_5   | P8     | 42    |
-| ICSS1   | PRU1  | UART1    +--------------+---------------------+--------+-------+
-|         |       |          | CTS          |pr1_pru1_pru_r31_6   | P8     | 39    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RTS          |pr1_pru1_pru_r30_7   | P8     | 40    |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-|         |       |          | TX           |pr1_pru0_pru_r30_8   | P8     | 27    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RX           |pr1_pru0_pru_r31_9   | P8     | 29    |
-| ICSS1   | PRU1  | UART2    +--------------+---------------------+--------+-------+
-|         |       |          | CTS          |pr1_pru1_pru_r31_10  | P8     | 28    |
-|         |       |          +--------------+---------------------+--------+-------+
-|         |       |          | RTS          |pr1_pru1_pru_r30_11  | P8     | 30    |
-+---------+-------+----------+--------------+---------------------+--------+-------+
-
-|
-
-UART Firmware Example & Test
-============================
-Example are test applications are available in the package for reference purpose
-and starting point.
-
-The example application uses the UART stdio API to repeatedly read characters
-transmitted from a PC UART. The acquired characters are then written (echoed)
-back to the PC UART.
-
-The test applications are more complex than the example application, and
-perform many more types of UART transfers than the example application. The
-test applications performs transfers using UART software IP (implemented
-in PRU firmware) and hardware IPs with different combinations of UART
-settings. Both the UART and UART stdio APIs are exercised (note the UART
-software and hardware IPs use the same UART-LLD API). The test applications
-are further described in the Firmware Design Guide.
-
-|
-
-Sample code for UART write & read:
-
-::
-
-    /* Refer to UART FW example & tests for details */
-    ...
-
-    /* Initialize the UART FW configuration */
-    UART_socInitFwCfg();
-
-    Board_init(boardCfg);
-    ...
-
-    UART_init();
-
-    /* Get the default UART init configuration */
-    UART_socGetFwCfg(uartInst, &uart_cfg);
-    /* Modify the default UART configurations if necessary */
-    /* Set the default UART init configurations */
-    UART_socSetFwCfg(uartInst, &uart_cfg);
-    ...
-
-    UART_Params_init(&uartParams);
-    uartParams.readCallback = UART_callback;
-    uartParams.readMode = UART_MODE_CALLBACK;
-    uartParams.writeCallback = UART_callback;
-    uartParams.writeMode = UART_MODE_CALLBACK;
-    uartParams.parityType = UART_PAR_NONE;
-    handle = UART_open(uartInst, &uartParams);
-    ...
-
-    /* Initiate UART write */
-    UART_transactionInit(&wrCbTransaction);
-    wrCbTransaction.buf = (void *)wrBuff;
-    wrCbTransaction.count = sizeof(wrBuffer)/2;
-    if (UART_write2(handle, &wrCbTransaction) == UART_ERROR) {
-        /* UART write failed */
-    }
-    ...
-
-    /* Initiate UART read */
-    UART_transactionInit(&rdCbTransaction);
-    rdCbTransaction.buf = (void *)rdBuff;
-    rdCbTransaction.count = sizeof(rdBuffer)/2;
-    if (UART_read2(handle, &callbackTransaction) == UART_ERROR) {
-        /* UART read failed */
-    }
-|
-
-.. rubric::  List of Examples & Tests
-   :name: examples-tests-list
-
-Refer to the Release Notes for details concerning UART support across different EVMs.
-
-+-----------------------+-------------------------+------------------------+
-| Name                  | Description             | Expected Results       |
-+=======================+=========================+========================+
-| UART_FwExample        | Example application     | Status messages will   |
-|                       | for PRU UART FW driver  | be displayed on        |
-|                       |                         | console based based    |
-|                       |                         | on pass/fail criteria: |
-|                       |                         |                        |
-|                       |                         | **Pass criteria:**     |
-|                       |                         |                        |
-|                       |                         | All Passed             |
-+-----------------------+-------------------------+------------------------+
-| UART_FwTest           | Simple test application | Status messages will   |
-|                       | for PRU UART FW driver  | be displayed on        |
-|                       |                         | console based on       |
-|                       |                         | pass/fail criteria:    |
-|                       |                         |                        |
-|                       |                         | **Pass criteria:**     |
-|                       |                         |                        |
-|                       |                         | All tests have         |
-|                       |                         | passed.                |
-+-----------------------+-------------------------+------------------------+
-| UART_FwTestExtLb      | More complex test       | Status messages will   |
-|                       | test application        | be displayed on        |
-|                       | for PRU UART FW driver, | console based on       |
-|                       | superset of UART_FwTest | pass/fail criteria:    |
-|                       |                         |                        |
-|                       |                         | **Pass criteria:**     |
-|                       |                         |                        |
-|                       |                         | All tests have         |
-|                       |                         | passed.                |
-+-----------------------+-------------------------+------------------------+
-
-|
-
-.. rubric::  Firmware Design Guide
-   :name: firmware-design-guide
-
-+-----------------------------------+----------------------------------------------------------+
-| **Document**                      | **Location**                                             |
-+-----------------------------------+----------------------------------------------------------+
-| UART Firmware Design Guide        | <PDK>/packages/ti/drv/uart/docs/UART_FW_DESIGN_GUIDE.pdf |
-+-----------------------------------+----------------------------------------------------------+
-
-**NOTE: Design document includes details for internal firmware implementation and
-can be used in case of modification required for firmware.**
-
-
-|
-
diff --git a/source/rtos/PRU_ICSS.rst b/source/rtos/PRU_ICSS.rst
deleted file mode 100644
index d98e41e38..000000000
--- a/source/rtos/PRU_ICSS.rst
+++ /dev/null
@@ -1,20 +0,0 @@
-######################
-PRU-ICSS Firmware
-######################
-
-.. toctree::
-   :maxdepth: 5
-
-   index_pru_icss_fw
-
-*************
-PRU-ICSS ESPI
-*************
-.. _PRU-ICSS-ESPI-FIRMWARE-label:
-.. include:: PDK_Platform_Software/PRU_ICSS_Drivers/_ESPI_FIRMWARE.rst
-
-*************
-PRU-ICSS UART
-*************
-.. _PRU-ICSS-UART-FIRMWARE-label:
-.. include:: PDK_Platform_Software/PRU_ICSS_Drivers/_UART_FIRMWARE.rst
diff --git a/source/rtos/Release_Specific.rst b/source/rtos/Release_Specific.rst
deleted file mode 100644
index 313735673..000000000
--- a/source/rtos/Release_Specific.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-##################
-Release Specific
-##################
-
-.. toctree::
-   :maxdepth: 5
-
-   index_release_specific
-
-
diff --git a/source/rtos/Release_Specific/_Build_the_SDK.rst b/source/rtos/Release_Specific/_Build_the_SDK.rst
deleted file mode 100644
index d0e5346b7..000000000
--- a/source/rtos/Release_Specific/_Build_the_SDK.rst
+++ /dev/null
@@ -1,257 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Building_The_SDK
-
-Overview
-=========
-
-The Processor SDK comes with pre-built libraries for everything you need
-to start writing an application. However, you may want to customize and
-rebuild from source. Inside the SDK there is a top-level Makefile that
-can be used to build some of the sub-components found within the SDK.
-Prior to calling this Makefile, run the provided script/batch file to
-setup your host environment variables. For components not covered by
-this top-level Makefile, please see guides within the respective
-component for build instructions.
-
-The Makefile and environment setup script are found in the RTOS SDK
-directory:
-
-::
-
-     [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/
-
-The default SDK Install Path is ``C:\ti`` for Windows and
-``/home/[user]/ti`` for Linux.
-
-The pre-requisite compilers are provided in Code Compose Studio, see the
-`CCS installation section of the Getting Started Guide <index_overview.html#code-composer-studio>`__.
-
-.. note::
-   If you have installed the SDK and/or CCS in non-default locations follow
-   the steps outlined in the article
-   `Processor SDK RTOS Install In Custom Path <index_how_to_guides.html#update-environment-when-installing-to-a-custom-path>`
-   to build the SDK from the toplevel Makefile.
-
-|
-
-.. _Build-The-SDK-Setup-Environment-label:
-
-Setup Environment
-====================
-
-Command
----------
-The SDK build environment can be configured on Windows and Linux by
-running an environment setup script located in the top-level RTOS SDK
-folder.
-
-.. note::
-
-   -  Windows 10 is required for building the SDK.
-   -  Mono is required for building the the SDK on linux. You can check if
-      mono is installed by typing "mono --version" at the linux prompt. If mono
-      is not installed, download and install mono from `here <http://www.mono-project.com>`__
-   -  OpenSSL is required for building the SDK for AM65xx. Check if OpenSSL is
-      is installed by typing "openssl version" at the comamnd prompt. If OpenSSL
-      is not installed, download and install OpenSSL for your OS.
-
-      -  For Windows : The easiest way is to download and install `Strawberry Perl <http:
-         //strawberryperl.com/download/5.28.0.1/strawberry-perl-5.28.0.1-64bit.msi>`__.
-         The Strawberry Perl installer automatically installs and sets up OpenSSL.
-         Alternately, users can also use any of these `Third Party OpenSSL Distributions
-         <https://wiki.openssl.org/index.php/Binaries>`__ for Windows. Refer individual
-         links for instructions on how to setup OpensSSL using a particular distribution.
-      -  For Linux : Execute the command "sudo apt-get install openssl" at the linux
-         command prompt.
-
-Windows
-^^^^^^^^^
-From the RTOS SDK directory, enter
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]> setupenv.bat
-
-which will configure the Windows command shell environment for the
-installed RTOS SDK.
-
-.. note::
-
-   -  You must re-run this batch file any time you open a new terminal.
-   -  Script also sets CCS installation path using TOOLS_INSTALL_PATH
-      variable so set the variable if you are not using default CCS install
-      path
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]>setupenv.bat
-
-     IPC_PLATFORM: DRA7XX
-     IPC_ALT_PLATFORM: AM572X AM571X
-     PROC_SDK_INSTALL_PATH     : C:/ti/processor_sdk_rtos_[soc]_[version]
-     **************************************************************************
-     Changing to short name to support directory names containing spaces
-     current directory: C:/ti/processor_sdk_rtos_[soc]_[version]
-     PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-     **************************************************************************
-
-.. note::
-   The warnings of optional parameters not configured can be ignored since
-   we are only rebuilding the libraries and not generating a release
-   package.
-
-Linux
-^^^^^^^^
-From the RTOS SDK directory, enter
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh
-
-which will configure the Linux shell environment for the installed RTOS
-SDK.
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc>]_[version]$ source setupenv.sh
-         IPC_PLATFORM: DRA7XX
-         IPC_ALT_PLATFORM: AM572X AM571X
-         PROC_SDK_INSTALL_PATH     : /home/[user]/ti/processor_sdk_rtos_[soc]_[version]
-
-     PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
-     *******************************************************************************
-
-.. note::
-   The warnings of optional parameters not configured can be ignored since
-   we are only rebuilding the libraries and not generating a release
-   package.
-
-
-Top-Level Makefile
-====================
-The SDK level makefile can be used to compile SDK sub-components after
-the build environment has been configured. The following sections cover
-the Makefile found in the top-level of the Processor SDK for RTOS.
-
-Target Types
---------------
-For each of the targets discussed below the following target type are
-defined:
-
--  **<target>** - This is the build target which will compile the
-   release version of the component
-
--  **<target>_clean** - This target will clean the component
-
-Top-Level Targets
-------------------
-The Processor SDK for RTOS provides the following targets by default
-which will invoke the corresponding component targets:
-
--  **help** - This will print target information defined in the Makefile
-
--  **all** - This will call the build target for each component defined
-   in the Makefile
-
--  **clean** - This will call the clean target for each component
-   defined in the Makefile
-
-.. note::
-   Invoking build using "all" option in SDK top level for multicore SOC
-   parts can take up to several hours to rebuild as the components need to
-   be built for all cores (e.g., A15, C66x, M4). Please rebuild individual
-   components in the PDK package for these devices to avoid long build times.
-
-Common Targets
----------------
-The following targets are common to all Processor SDKs for RTOS:
-
--  **pdk** - Builds the Platform Development Kit that includes CSL and
-   low level drivers
-
-Additional Targets
--------------------
-You can find the list of all the targets by invoking **help** target as
-described above. Depending on the capabilities and software available
-for a given device additional targets may also be defined:
-
--  **demo** - Builds demonstrations provided in the SDK
--  **ipc_bios** - Builds the IPC component provided in the SDK
--  **ipc_examples** - Builds the IPC examples provided in the IPC
-   component
-
-Support for parallelism (-j <job slots>)
-----------------------------------------
-Support for parallel make (-j) is available on the top level makefile targets 'all' and 'clean'
-and it improves the build time. This feature is available from Processor SDK RTOS 6.0 onwards
-and has been tested with <job slots> up to 4.
-
-|
-
-Usage Examples
-================
-The following examples demonstrate how to use the top-level Makefile for
-some common tasks. All of the examples below assume that you are calling
-the Makefile from the top-level of the SDK.
-
-Windows
---------
-
--  Build all
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]> gmake all -j4
-
--  Clean all
-
-::
-
-     C:\ti\processor_sdk_rtos_[soc]_[version]> gmake clean -j4
-
-Linux
-------
-
--  Build all
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc]_[version]$ make all -j4
-
--  Clean all
-
-::
-
-     ~/ti/processor_sdk_rtos_[soc]_[version]$ make clean -j4
-
-|
-
-Rebuilding Components
-=======================
-Instructions for rebuilding sub-components can be found in documentation
-within the component. Here are a collection of useful pages:
-
-Rebuild PDK
---------------
-.. include:: How_to_Guides/Host/Setup/_Rebuild_drivers_from_PDK_directory.rst
-
-Rebuild IPC
---------------
--  `Rebuild
-   IPC <index_Foundational_Components.html#rebuilding-ipc>`__
-   *(Starting in Release 3.0, IPC build has been integrated into the
-   top-level SDK Makefile.)*
-
-Rebuild NDK
---------------
--  `Rebuild
-   NDK <http://processors.wiki.ti.com/index.php/Rebuilding_The_NDK_Core_Using_Gmake>`__
-
-Rebuild SYS/BIOS
------------------
--  `Rebuild
-   SYS/BIOS <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__
-
-|
-
-.. raw:: html
-
diff --git a/source/rtos/Release_Specific/_Migration_Guide.rst b/source/rtos/Release_Specific/_Migration_Guide.rst
deleted file mode 100644
index 8ab0f70ba..000000000
--- a/source/rtos/Release_Specific/_Migration_Guide.rst
+++ /dev/null
@@ -1,866 +0,0 @@
-****************
-Migration Guide
-****************
-
-Overview
-========
-
-This page covers migration information for applications built on top
-of the Processor SDK RTOS.
-
-Processor SDK 06.xx Releases
-============================
-
-Processor SDK 06.03
--------------------
-
-Building PDK components from GIT repositories
-=============================================
-
-**Migration:** Change in git repository for PDK components.
-
-**Impact Scope:** Applicable for most drivers packaged in the PDK when used in development environment
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) had their own git respositories which could be cloned and used for development or picking up bugfixes which are not yet released through a processor sdk release.
-From this release onwards, most of the drivers in the PDK are moved to the new pdk.git repository(https://git.ti.com/cgit/processor-sdk/pdk) and its components (drivers) moved in to their respective locations inside the pdk_<soc>_<ver> of the Processor SDK installation.
-For example the i2c driver has been moved from https://git.ti.com/cgit/keystone-rtos/i2c-lld to https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/drv/i2c. Consequently, the latest updates on a PDK driver should be fetched from the new pdk.git repo (https://git.ti.com/cgit/processor-sdk/pdk) as the older repos are rendered obselete.
-
-Building of libraries of individual PDK components
-==================================================
-
-**Migration:** Building individual drivers' librabries/apps of PDK from PDK's top level makefile is not supported
-
-**Impact Scope:** Applicable for PDK top level makefile
-
-**Additional Details**:
-Prior to this release, libraries/applications of drivers included in pdk (pdk_xx/packages/ti) could be built from
-the top level makefile (pdk_xx/packages/makefile) using commands like "make uart_lib/uart_apps". This is no longer supported.
-Instead, the libraries and applications could either be built using "make all" from the top level makefile or issuing "make libs/apps" from within the module's directory.
-
-
-Processor SDK 06.01
--------------------
-
-NIMU
-====
-
-**Migration:** Udma init sequence call has been moved from NIMU library to NIMU example for AM65xx
-
-**Impact Scope:** Applicable for all NIMU applications using NIMU tranport library for AM65xx
-
-**Additional Details**:
-Applications will need to implement the following function to provide UDMA drive handle which will be called by the NIMU driver at startup
-
- Udma_DrvHandle nimu_app_get_udma_handle(void)
-
-Processor SDK 06.00
--------------------
-
-PRUSS
-^^^^^
-**Migration:**
-Calls that passed ``PRUICCSS_INSTANCE_MAX`` as a parameter to PRUSS driver API
-calls will now pass ``PRUICCSS_INSTANCE_THREE`` instead.
-
-**Impact Scope:**
-Applicable for all AM65xx applications using PRUSS driver for ICSSG use case.
-
-**Additional Details:**
-The following new enumeration, ``PRUICCSS_INSTANCE_THREE``, for PRU-ICSS
-instance 3 has been added to ``PRUICSS_MaxInstances`` enumeration list as
-``PRUICCSS_INSTANCE_MAX`` is not longer valid when making PRUSS driver API
-calls.
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-MMU configuration is needed to enable NBO CFG registers access on A53 core.
-
-**Impact Scope:**
-Applicable for all AM65xx RTOS applications calling ``Board_init()`` with
-``BOARD_INIT_ICSS_ETH_PHY`` flag.
-
-**Additional Details:**
-Board library is setting ``NAVSS THREADMAP`` register to give higher priority
-for MSMC access from ICSSG which requires access to ``NBO CFG`` registers.
-
-
-Processor SDK 05.xx Releases
-============================
-
-Processor SDK 05.03
--------------------
-
-EMAC
-^^^^
-**Migration-1:**
-ICSS-G EMAC firmware binary directory location update for future extension.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Applications will need to update the include path to location of firmware header
-files for ICSSG use case:
-
-- **Prevous location:** ``ti/drv/emac/firmeare/icss_eth/src/dm``
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/bin``
-
-**Migration-2:**
-Release introduces support for additional firmware specific configuration
-files. Added for future extension to support multiple firmwares using same EMAC
-driver.
-
-**Impact Scope:**
-Applicable for all applications using EMAC driver with ICSS-G dual EMAC
-firmware.
-
-**Additional Details:**
-Firmware configuration has been moved to firmware specific configuration files,
-``emac_fw_config_dual_mac.h`` and ``emac_fw_config_dual_mac.c``. Previously the
-firmware configuration was specified in the test application. It is not expected
-that applicatons will need to modify these files as the are closely tied to the
-firmware.
-
-- **Previous location:** firmware specific configuration was specified in the
-  text application (``ti/drv/emac/test/EmacLoopbackTest/test_utils_k3.c``)
-
-- **New location:** ``ti/drv/emac/firmware/icss_dualmac/config/``
-
-Applications will need to update their makefiles to include c source file
-``emac_fw_config_dual_mac.c``.
-
-At time of ``emac_open()`` API call, applications need to udpate configuruation
-parameters to pass get firmware configuration pointer :
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V5 emac_cfg;
-   EMAC_socGetInitCfg(0, &emac_cfg);
-   emac_cfg.portCfg[port_num].getFwCfg = &emacGetDualMacFwConfig;
-   EMAC_socSetInitCfg(0, &emac_cfg);
-
-CSL
-^^^
-**Migration:**
-API changes on CSL-FL of AM65xx on ecc aggregator, vim, esm modules
-
-**Impact Scope**:
-Limited to the case if application is using the CSL-FL APIs
-
-**Additional Details**:
-The CSL-FL for ECC aggregator, ESM and VIM are modified to return API
-functionality success/failures and additional arguments are added as and when
-needed (especially during the cases where the return was the value instead of
-API success/failure). Applications that use these CSL-FL calls are impacted and
-are needed to align to new calling conventions. If applicable application
-modification required to align to updated APIs, refer doxygen API documentation
-for API details.
-
-
-DSP- TI CGT Compiler
-^^^^^^^^^^^^^^^^^^^^
-
-**Migration:**
-In DSP TI CGT compiler version 8.3.2 the rts library boot object file name is
-changed from ``boot.obj`` to ``boot.c.obj``.
-
-**Impact Scope:**
-Limited only to DSP applications that explicitly uses rts library object files
-in linker command file.
-
-**Additional Details:**
-The DSP application which is using linker command file of CSL module should
-change boot object name from boot.obj file to ``boot.c.obj``. If the user is
-using cpp version of boot object file then it should be mentioned as
-``boot.cpp.obj``. In general it can be also be used as ``boot.*.obj``. This can
-be referred from the following linker command file in the PDK package
-``<PDK>/packages/ti/csl/example/lnk_dsp.cmd``
-
-Processor SDK 05.02
--------------------
-
-SBL
-^^^
-**Migration:**
-Image integration and memory map changes.
-
-**Additional Details:**
-Release supports optimized boot times for booting MCU1_0 core from OSPI
-flash. To reduce the size of the SBL,  the system firmware image, which was
-earlier embedded in the SBL, is now a separate binary. The system firmware image
-can be found at ``<PDK>/packages/ti/drv/sciclient/soc/V0/sysfw.bin``
-
-For MMC/SD boot, if the steps followed in `Windows SD Card Creation Guide
-<index_overview.html#windows-sd-card-creation-guide>`_ or `Linux SD Card
-Creation Guide <index_overview.html#tools-create-sd-card-linux-label>`_ are
-used, no additional steps are need. If the SD card is being created manually,
-then the ``sysfw.bin`` file also needs to be copied into the root directory of
-the MMC SD card, along with ``tiboot3.bin`` and ``app``.
-
-For OSPI boot, the flash offsets have changed. ``sysfw.bin`` needs to be
-programmed into OSPI flash at offset ``0x40000`` (new for this release), along
-with ``sbl_ospi_img_mcu1_0_release.tiimage`` at offset ``0x0`` (no change from
-previous release) and the ``app`` at offset ``0xA0000`` (was ``0x80000``
-previous release).  For details please refer `Programming the OSPI flash
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Board_EVM_Abstration.html#uniflash>`__
-
-Applications that the SBL loads must co-exist with the SBL's memory usage.In the
-application's linker command file, care must be taken to not use the first 0x100
-bytes of MCU1_0's ATCM memory and SBL reserved memory from ``0x41C00100 to
-0x41C28000``. If the applications violate the SBL memory usage, then apps that
-were working with the last release might not work any more, as the memory
-constraints are tighter. For details, refer the `SBL Memory Utilization
-<http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/Foundational_Components.html#am655x-sbl-memory-usage>`__
-
-PDK
-^^^
-**Migration:**
-AM65xx PDK component dependency on sciclient module.
-
-**Impact Scope:**
-Applications will need to link to sciclient module library. No migration impact
-if application is already linking the library.
-
-**Additional Details**:
-All application using PDK components on AM65xx platform will need to link
-sciclient library  as components internally will be using sciclient API for PLL
-and interrupt configuration. In this release, requirement for application will
-be more mandated as more components are using common infrastructure.
-
-DMSC firmware should be loaded onto Cortex-M4 core using SBL or `CCS GEL script
-<index_how_to_guides.html#advanced-am65x-debug-setup-with-dmsc-firmware-load>`_
-before calling the Board Init API with 'BOARD_INIT_PLL' flag.
-
-Board
-^^^^^
-**Migration:**
-New APIs for EEPROM Board ID Information
-
-**Impact Scope:**
-Applications using Board ID info APIs on AM65xx platform. No migration impact
-for existing applications and boards using version 1 API.
-
-**Additional Details**:
-TI Board ID information format has been updated to new version on AM65xx. New
-board library APIs ``Board_getIDInfo_v2()`` and ``Board_writeIDInfo_v2()`` are
-added to support new Board ID information format. Old Board ID info APIs are
-still avaialble to retain the backward build compatibility but returns error
-when used on AM65xx platform.
-
-FATFS
-^^^^^
-**Migration:**
-FATFS module in this release includes multipartition support and capability of
-detecting single vs multiple partitions run time.
-
-**Impact Scope:**
-Limited to the case if user had used MS-DOS Floppy disk format for formatting
-the SD/eMMC memory. No impact if the SD/eMMC is formatted using the steps
-provided by `Windows SD Card Creation Guide
-<index_overview.html#windows-sd-card-creation-guide>`_/ `Linux SD Card Creation
-Guide <index_overview.html#tools-create-sd-card-linux-label>`_
-
-**Additional Details**:
-Partition entry information may be wrongly detected for the storage media
-formated to  MS-DOS Floppy disk format. FATFS APIs fail to access the disk in
-this case.
-
-**Workaround**:
-Format the storage media using the steps provided by `Windows SD Card Creation
-Guide <index_overview.html#windows-sd-card-creation-guide>`_/ `Linux SD Card
-Creation Guide <index_overview.html#tools-create-sd-card-linux-label>`_
-in case this issue is observed.
-
-Processor SDK 05.01
--------------------
-
-Build
-^^^^^
-**Migration:**
-Applicable for applications migrating from SOCs supporting EDMA LLD to AM65x
-with updated DMA infrastructure. Additional UDMA driver support is available in
-package to support enhanced DMA infrastrcuture for AM65x Drivers for AM65x SOC
-is extended to support UDMA LLD abstracting changes needed by
-application. Limited change will be required for application using drivers
-included in Processor SDK.
-
-**Additional Details**:
-Modifications needed at application will be limited to initialization of UDMA
-driver using Udma_init() API in addition to linking  UDMA driver library. Driver
-Test code could be used as reference Additional migration details for all cases
-are covered in ``/ti/drv/udma/docs`` folder inside PDK package.
-
-DMA
-^^^
-**Migration:**
-For all drivers using DMA mode EDMA driver is updated to UDMA driver.
-
-**Additional Details:**
-Application will need to initialize UDMA driver and SCIClient interface using
-``Udma_init()`` and ``Sciclient_init()`` API. Test code could be used as
-reference.
-
-Networking
-^^^^^^^^^^
-**Migration:**
-Applicable for applications using NDK and Posix port of SysBIOS.
-
-**Additional Details:**
-Release introduces NS (Network Services Component) as independent portable
-networking API abstracting different network stacks. Detailed migration details
-is available at `NDK 2.x to 3.x Migration Guide <NDK_Migration_Guide_>`__
-
-Processor SDK 05.00
--------------------
-
-Build
-^^^^^
-**Migration:**
-``TOOLS_INSTALL_PATH`` macro value changed to ``SDK_INSTALL_PATH``. No migration
-impact if tools and SDK are installed in same location.
-
-**Additional Details:**
-``TOOLS_INSTALL_PATH`` macro value is set to ``SDK_INSTALL_PATH`` by
-default. For accessing the tools from a different path, modify
-``TOOLS_INSTALL_PATH`` in ``packages/ti/build/Rules.make`` file or can be
-overriden from the build console as shown below.
-
-Windows
-
-.. code:: console
-
-       set TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-Linux
-
-.. code:: console
-
-       TOOLS_INSTALL_PATH=<Path for the tools root folder>
-
-
-Build Setup
-^^^^^^^^^^^
-**Migration:**
-There is no migration need for components used within processor SDK. Application
-Software outside processor SDK may require a change if there is a dependency to
-internal Processor SDK environment variables. See more details below.
-
-**Additional Details:**
-Rules.make file is used instead of pdksetupenv to setup the build environment
-variables. Components inside processor SDK are updated to align with this
-change. Any applications making use of pdksetupenv from processor SDK to setup
-the build environment variables should include below line in the application
-makefile.
-
-.. code-block:: c
-
-  include $(RULES_MAKE)
-
-Processor SDK 04.xx Releases
-============================
-
-Processor SDK 04.03
--------------------
-
-OSAL
-^^^^
-**Migration:**
-No impact expected if Semaphore allocation and HwIP registration from OSAL is
-not invoked by application.
-
-**Additional Details:**
-OSAL module is fine tuned for optimized number of semaphores required internally
-within drivers. Module provides additional API to application for additional
-semaphore allocation if required.Application can configure for either default
-internal static allocation or it can select external memory block that can be
-provided to create these objects. Note that this decision to go with external
-memory block or internal memory block need to be done during init configuration
-of application (near to main) just after ``Board_init()`` is called. Below
-sample code sets SemaphoreP/HwiP to be used from external memory block:
-
-.. code-block:: c
-
-   /* Get the Hw Attrs */
-   osal_ret = Osal_getHwAttrs(&hwAttrs);
-   if (osal_ret != osal_OK)
-   {
-       return (false);
-   }
-
-   /* This API should set to use external memory block */
-   hwAttrs.extSemaphorePBlock.base = (uintptr_t) &semPMemBlock[0];
-   hwAttrs.extSemaphorePBlock.size = SEMP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.size       = HWIP_BLOCK_SIZE;
-   hwAttrs.extHwiPBlock.base       = (uintptr_t) &hwiPMemBlock[0];
-   osal_ret = Osal_setHwAttrs(ctrlBitMap, &hwAttrs);
-
-
-Board
-^^^^^
-**Migration:**
-Section details applicable only to applications based on DRA7xx SoCs.
-
-**Additional Details**:
-DRA7xx board libraries have refactored pad configuration sequence by removing
-manual pinmux entries and replacing them with a full IODELAY reconfiguration
-procedure. This was done in order to simplify transition from a standalone
-application development in CCS to booting the whole device via SBL, ensuring
-that pad configuration is 100% consistent between the two application loading
-methods.
-
-The IODELAY and pin control data structures are maintained in each of evmDRA72x
-and evmDRA75x board library source directories. These structures are also
-included in the SBL compilation and used in the SBL's IODELAY
-reconfiguration. Therefore, changes can be made in one location but reused by
-both Board and SBL components just through recompilation.
-
-Note that DRA78x does not require IODELAY reconfiguration and pinmux setup is
-always contained entirely in the application. Hence, there are no corresponding
-changes to this library.
-
-All of this is done in a transparent manner, so there is **no API change** and
-will not affect existing applications. However, there are considerations with
-respect to memory placement and potential conflicts between the board library
-and SBL code. These restrictions have always existed but are now more clearly
-defined and documented. Please refer to `Board Support
-<Board_EVM_Abstration.html#board-support>`__ for more details.
-
-I2C
-^^^
-**Migration:**
-No migration required for existing user application.
-
-**Additional Details:**
-PRUICSS based I2C Firmware have been introduced in this release. This new
-features increases the number of I2C interface available in the SOC. I2C LLD now
-depends on PRUSS LLD for compilation of this new feature. All of this is done in
-a transparent manner, so there is **no API change** and will not affect existing
-applications. However, for using the I2C FW feature refer :ref:`I2C FW
-<PRU-ICSS-I2C-FIRMWARE-label>` for additional details.
-
-Processor SDK 04.02
--------------------
-
-GCC Toolchain Migration to 6-2017-q1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to TI-RTOS based application on ARM Cortex-A cores.
-
-**Additional Details:**
-Processor SDK RTOS components includes updates to be compatible with GCC tool
-chain. This includes updates to SysBIOS, compiler and linker options. Following
-migration changes required for applications:
-
-- Compiler options: Add nano libs to Include path
-
-  - Example:
-    ``gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/newlib-nano``
-
-- Linker Options: Replace fpu lib paths with hard lib and enable nano specs
-
-  - Example: ``"<SYS/BIOS Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu"``
-     with ``"<SYS/BIOS
-     Root>/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard --specs=nano.specs”``
-
-**Additional References:**
-
-- PDK Project Creation Scipt:
-  ``<pdk_soc_x_x_x/packages/pdkProjectCreate.[bat/sh]>``
-
-**Note:** For baremetal applications, stack section needs to be aligned to 8
-bytes. Updated GCC toolchain is more stringent on memory alignment requirement.
-Misalignment can result in unexpected run time failures.
-
-EMAC Library
-^^^^^^^^^^^^
-**Migration:**
-Limited to C6657, OMAPL137/C6747 and OMAPL138/C6748 SoCs.
-
-**Additional Details:**
-Interrupt setup and ISR functions are implemented in the driver. Interrupt
-handling in applications need to be removed to use the latest driver
-version. Use ``EMAC_socGetInitCfg()`` and ``EMAC_socSetInitCfg()`` functions to
-change the default interrupt mapping in HW attributes if required.
-
-Example:
-
-.. code-block:: c
-
-   EMAC_HwAttrs_V0             emac_hwattr;  /* Local instance for HW attributes */
-   EMAC_OPEN_CONFIG_INFO_T     open_cfg;
-
-   EMAC_socGetInitCfg(port_num, &emac_hwattr);  /* Get default SOC HW attributes */
-   emac_hwattr.txIntrNum = <Int Num>  /* Change default interrupt mapping Optional: if needed */
-   EMAC_socSetInitCfg(port_num, &emac_hwattr); /* Change the default HW attributes */
-   open_cfg.hwAttrs = &emac_hwattr;  /* Assign HW attributes to configuration parameters */
-   emac_open(port_num, &open_cfg);
-
-
-Processor SDK 04.01
--------------------
-
-Common CSL Library
-^^^^^^^^^^^^^^^^^^
-**Migration:**
-Limited to Bare metal Application and Keystone SoCs such as K2HK/K2LE/K2G. No
-change required for other SoCs such as AM571x/AM572x/C6678/C6657.
-
-**Additional Details:**
-Default start address for the vectors modified to beginning of MSMCSRAM
-(``0x0C000000``) compared to previous release end of the MSMC. This matches to
-both secured and non secured devices Application is required to reserve
-(``0x0C000000 to 0x0C000040``) size 0x40 bytes.
-
-Bare metal Application needs to reserve this location for vectors when using CSL
-startup library. There is still option for overriding default configuration by
-defining ``vector_base`` to desired start address: Example: if the vector
-location desired is say ``0xC0E0000``, then add below line in the application's
-linker command file:
-
-.. code-block:: c
-
-   __vector_base__= 0xC0E0000;
-
-No change needed for application using default configuration matching CSL.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration required for applications using default icss_dualemac
-and icss_switch firmware.*
-
-The location of ``icss_emacFwConfig.c/.h`` has moved from
-``ti/drv/icss_emac/firmware/<SOC_TYPE>`` directory to
-``ti/drv/icss_emac/firmware/icss_dualemac/config/`` directory. If applications
-are compiled with ``icss_emacFwConfig.c``, please update your build/make
-infrastructure.
-
-Processor SDK 04.00
--------------------
-MCSDK 1.1 to Processor SDK Migration for OMAPL13x/C674x devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This release includes additional support for OMAPL13x/C674x
-architecture/SOCs. For more information on migrating aplications from
-MCSDK(OMAPL13x) to Processor SDK, see `this migration page
-<MCSDK_Migration_for_OMAPL13x_>`__.
-
-ICSS_EMAC Library
-^^^^^^^^^^^^^^^^^
-**Migration:**
-*Required. Application will need to link to firmware binaries.*
-
-ICSS EMAC driver component includes source code support for Dual-emac firmware
-with support for rebuilding. Firmware is no longer supported as header format
-*.h in order to align to PRUSS compiler.
-
-- In order to include new binary application will need to link the PRUSS
-  firmware binary as demonstrated through ``*project.txt``. **Note: firmware
-  binary to be linked will be dependent on the SOC as shown below**
-
-**Example:**
-*AM572x have support for both version so include both version of
-binaries and linker \*.cmd files.*
-
-.. code-block:: c
-
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU0.bin
-   ${PDK_INSTALL_PATH}/ti/drv/icss_emac/firmware/icss_dualemac/bin/<SOC>/<HOSTCORE>/<REVISION>/icss_dualemac_PRU1.bin
-
-- Default linker command file is available in PDK software which can be linked
-  by application based on cores where application is running. For A8, A9, A15
-  cores below linker command can be linked in makefile or CCS project. Refer the
-  ICSS-EMAC Unittest for additional details.
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_a8_a9_a15_<REVISION>.cmd
-
-- For c66 and m4 cores
-
-.. code-block:: c
-
-   -Wl,-T,${PDK_INSTALL_PATH}/ti/build/pruss/lnk_c66_m4_<REVISION>.cmd
-
-Board Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact in case of applications using custom board
-library which is not following similar approach as default board library for
-Ethernet PHY configurations.*
-
-Updated Board library for OMAPL137 in this release includes additional Ethernet
-PHY initialization support for reference EVM during init and hence requiring
-dependency on I2C LLD. This is applicable to applications using default OMAPL137
-board library similar to other PDK/Processor SDK applications in the
-release. For all those cases linking to additional I2C LLD library will be
-required.
-
-Examples for including I2C LLD library for:
-
-- Baremetal Applications
-
-Include the I2C LLD library from below mentioned path in makefile or linker
-command file:
-
-- **ARM Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/arm9/release/ti.drv.i2c.ae9``
-- **DSP Core** -
-  ``<PDK_INSTALL_DIR>/packages/ti/drv/i2c/lib/omapl137/c674/release/ti.drv.i2c.ae674``
-
-- SYS/BIOS RTOS Applications
-
-Include the I2C LLD library in SYS/BIOS config file using xdc load package
-module:
-
-.. code-block:: c
-
-   var devType = "omapl137"
-   var I2c     = xdc.loadPackage('ti.drv.i2c');
-   I2c.Settings.socType = devType;
-
-McASP Library
-^^^^^^^^^^^^^
-**Migration:**
-*Optional. No migration impact for applications initializing the structure using
-memset and default configuration: ``Mcasp_WordBitsSelect_LSB()``.*
-
-McASP driver includes additional configuration field in
-``Mcasp_ChanParams->wordBitsSelect`` to enable newly introduced mode
-Mcasp_WordBitsSelect_MSB. Configuration needs to be initialized by application.
-
-Processor SDK 03.xx Releases
-============================
-
-Processor SDK 03.03
--------------------
-
-Processor SDK 03.02
--------------------
-
-PDK I2C LLD
-^^^^^^^^^^^
-To support I2C target mode, added ``I2C_transactionInit()`` API. Applications
-need to call ``I2C_transactionInit()`` API before calling ``I2C_transfer()``
-API.
-
-**Example:**
-
-.. code-block:: c
-
-   I2C_Transaction   transaction;
-   I2C_transactionInit(&transaction);
-   transaction.controllerMode   = false;
-   transaction.writeCount = wrLen;
-   transaction.readCount  = rdLen;
-   transaction.timeout    = timeout;
-   I2C_transfer(i2c, &transaction);
-
-PDK MCASP LLD
-^^^^^^^^^^^^^
-The call back function's behavior has changed. The MCASP driver no longer
-modifies the ``cArg`` parameter of the registered call back function to indicate
-the transaction type(TX or RX). The cArg paramter will be unchanged and passed
-back to the application. Please refer to the examples, which have been updated
-to reflect this change.
-
-PDK MMCSD LLD
-^^^^^^^^^^^^^
-No update required for use of default SOC dependent library.This is applicable
-for applications which choose to include the ``soc/MMCSDDMA_soc.c``. The
-``soc/MMCSDDMA_soc.c`` file has now been removed as a part of combining the DMA
-and Non-DMA source code of the MMCSD library. Applications may include
-``soc/MMCSD_soc.c`` file instead.
-
-PDK USB LLD
-^^^^^^^^^^^
-- Cache is now supported. Buffers that are passed to low level USB bulk API's
-  need to be cache-size aligned. These include buffers passed to:
-  ``USBHMSCBlockWrite()``, ``USBHMSCBlockRead()``, ``USBHostRead()``,
-  ``USBHostWrite()``, or ``usbSetupEpReq()``, etc.
-
-- DMA is enabled by default on AM335x. Remove DMA_MODE flag in
-  ``build/makefile.mk`` to go back to FIFO mode.
-
-PDK ICSS EMAC LLD
-^^^^^^^^^^^^^^^^^
-Support has been added to all allow the icss-emac LLD to be configured with
-custom firmware memory map parameters which fall into the following 2
-categories:
-
-- *Static configuration*: Tied directly to the firmware. For example, location and
-  size of statistics, port status and conrol address offsets.
-
-- *Dynamic configuration*: Tuneable parameters based on application. For
-  example, sizes of TX/RX queues, port specific buffer/buffer descriptor
-  offsets.
-
-A complete list of these parameters can be found in
-``ti/drv/icss_emac/icss_emacDrv.h``. Refer to ``ICSS_EmacFwStaticMmap`` and
-``ICSS_EmacFwDynamicMmap`` structures.
-
-Firmare binaries which reside in ``ti/drv/icss_emac/firmware/<SOC>`` directory
-should be accompanied by a ``icss_emacFwConfig.c`` file. For existing firmware
-binaries in this release, there is an equivelent ``icss_emacFwConfig.c`` file
-already present. This file basically defines the 2 stuctures mentioned
-above. This file needs to be compiled in as part of the user application. User
-application can then use the following 2 newly introduced API's to "get" and
-"set" firmware memory map configuration parameters with the LLD and firmware.
-
-- ``icss_emacGetFwMMapInitConfig()``: Allows for retrieval of default firmware
-  memory map configuration. User application may call this if they wish to
-  update dynamic firmware memory map configuration paremeters. Static
-  configuration parameters MUST not be updated.
-
-- ``icss_emacSetFwMMapInitConfig()``: Allows for static and dynamic firmware
-  memory map configuration parameters to be configured into the the LLD and
-  firmware.
-
-Note that these API's need to be called prior to calling ``ICSS_EmacInit()``
-which is LLD's initialization function.
-
-Backward compatibility is also supported. If user application does not wish to
-update any configuration parameters, LLD will operate of default configuration
-parameters as specified in respective ``icss_emacFwConfig.c`` file which is
-being delivered as part of this release.
-
-TI-RTOS
-^^^^^^^
-The updated version of TI-RTOS (SYS/BIOS) includes a check to ensure the proper
-run-time library is linked. If you face a compilation issue, see `this note on
-RTOS FAQ <SYSBIOS_reentsupport_error_faq_>`__ for more information.
-
-Processor SDK 03.01
--------------------
-PDK CSL
-^^^^^^^
-- ``csl_a15init`` module is renamed to ``csl_init`` to support portability. The
-  impact of this change is limited to bare metal application using PDK makefile
-  infrastructure. As part of migration, the module name need to be updated.
-
-- ``csl_a15Aux.h`` is removed as it is duplicate of ``csl_a15.h``. The impact of
-  this change is limited to applications that include ``csl_a15Aux.h``. As part
-  of migration, the modification required is to include ``csl_a15.h`` instead.
-
-PDK SA LLD (K2x, C66x)
-^^^^^^^^^^^^^^^^^^^^^^
-Added a feature to select Air Cipher Engine over the default Encryption engine
-for algorithms such as AES_CTR part of ``Sa_DataModeConfigParams_t`` API. There
-is no migration impact if application is initializing the structure to zero
-using memset.
-
-Processor SDK 03.00
--------------------
-This release is a maintenance update with new features and bug fixes. The major
-number in the version changed to stay aligned with the Linux package that moved
-to 2016 LTS.
-
-Device Drivers
-^^^^^^^^^^^^^^
-- Locations of precompiled libraries have moved for the following PDK
-  components: ``CSL, PDK Examples, GPIO, GPMC, I2C, ICSS-EMAC, McASP, McSPI,
-  MMC-SD, PCIe, PRUSS, QSPI, UART, USB, VPS, PDK Utils, FATFS, BOARD, OSAL,
-  NIMU, NIMU_ICSS``. The overall change is to rename armv7 to a15/a8/a9 as
-  appropriate for the device. All cores have moved the libraries compiled with
-  optimization to ``release``, while a debug folder is available (but not
-  prebuilt) for libraries with ``-g``.
-
-  - No changes are needed for applications configured with a XDC/BIOS \*.cfg with
-    dependancies specified through xdc.useModule or xdc.loadPackage because
-    updated library paths are autogenerated.
-
-  - For other applications which explicitly set libraries and/or library include
-    paths via ``-l, -I, or -L`` flags passed to the linker, the library paths
-    need to be updated. For example, for GPIO on A15, the path changes from
-    ``ti/drv/gpio/lib/am572x/armv7`` to ``ti/drv/gpio/lib/am572x/a15/release``.
-
-- The drivers GPIO, I2C, SPI and UART now use CSL-FL. Applications using these
-  drivers need to add include and library dependencies by adding xdc.useModule
-  for CSL-FL for XDC/BIOS based applications, or by adding ``-I/-l/-L`` paths to
-  the compilation/linker flags for the application. For XDC, here is a sample
-  code for adding CSL-FL:
-
-.. code-block:: javscript
-
-   /*use CSL package*/
-   var socType = "am571x";
-   var Csl     = xdc.loadPackage('ti.csl');
-
-   Csl.Settings.deviceType = socType;
-
-- The driver I2C has an API change for I2C_transfer, a new timeout field is
-  added to ``I2C_Transaction`` structure, and the return value type of this API
-  is changed from ``bool`` to ``int16_t``. In the test/example application,
-  timeout value need to be initialized before calling this API:
-
-**Example:**
-
-.. code-block:: c
-
-   int16_t status;
-
-   i2cTransaction.targetAddress = I2C_EEPROM_ADDR;
-   i2cTransaction.writeBuf = (uint8_t *)&txBuf[0];
-   i2cTransaction.writeCount = I2C_EEPROM_TEST_LENGTH + I2C_EEPROM_ADDR_SIZE;
-   i2cTransaction.readBuf = NULL;
-   i2cTransaction.readCount = 0;
-   i2cTransaction.timeout   = I2C_TRANSACTION_TIMEOUT;
-
-   status = I2C_transfer(handle, &i2cTransaction);
-
-Processor SDK 02.xx Releases
-============================
-
-Processor SDK 02.00.02
-----------------------
-This release primarily adds support for K2G device. There is no migration impact
-to customers using devices supported in the previous release (AM3, AM4, AM5,
-C665x, C667x, K2E, K2H, K2K, K2L).
-
-Processor SDK 02.00.01
-----------------------
-This release primarily adds support for devices from the KeyStone architecture:
-C665x, C557x, K2E, K2H, K2K, and K2L. There is no migration impact to customers
-using devices supported in the previous release (AM3, AM4, AM5).
-
-For information on migrating from BIOS-MCSDK (C66x) or MCSDK (K2x) to Processor
-SDK, see `this migration page <MCSDK_Migration_Guide_>`__.
-
-Processor SDK 02.00.00
-----------------------
-**This is the initial Processor SDK RTOS release from Texas Instruments unifying
-platform software across multiple SOC's.**
-
-The strategy for forward/backwards compatibility is as follows:
-
-- `Device Drivers <Device_Drivers_>`__
-
-  - All new development efforts should use Device Drivers because:
-
-    - Device Drivers will maintain common APIs for all supported SoCs
-    - Customer applications can be easily ported to new and additional SoCs
-      hence providing scalable software platform
-    - All new features and development will occur only in the Device Drivers.
-
-- StarterWare is included for AM335x and AM437x for backwards compatibility with
-  Industrial SDK 02.01.00.01
-
-  - This will be maintenance only (bugs will be fixed, no new features)
-
-For applications that already depend on StarterWare from Industrial SDK
-02.01.00.01 on AM335x/AM437x, those APIs remain in Processor SDK in:
-
-- **AM335x SOC:** ``pdk_am335x_1_0_0/ti/starterware``
-- **AM437x SOC:** ``pdk_am437x_1_0_0/ti/starterware``
-
-
-.. _Linux_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#tools-create-sd-card-linux-label
-.. _Windows_SD_Card_Creation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html?highlight=bootable#windows-sd-card-creation-guide
-.. _NDK_Migration_Guide: http://software-dl.ti.com/targetcontent/ndk/3_40_01_01/exports/ndk_3_40_01_01/docs/ndk/NDK_2_to_3_Migration_Guide.html
-.. _Device_Drivers: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index.html#Device_Drivers
-.. _MCSDK_Migration_Guide: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk-to-processor-sdk-migration-guide
-.. _MCSDK_Migration_for_OMAPL13x: http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Release_Specific.html#mcsdk1-1-to-processor-sdk-linux-migration-guide-for-omapl13x-devices
-.. _SYSBIOS_reentsupport_error_faq: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/FAQ.html#Why_do_I_get_a_.22undefined_reference_to_.60ti_sysbios_rts_gnu_ReentSupport_checkIfCorrectLibrary.27.22_error_when_compiling_my_application.3F
diff --git a/source/rtos/Release_Specific/_Release_Notes.rst b/source/rtos/Release_Specific/_Release_Notes.rst
deleted file mode 100644
index ca86a12c9..000000000
--- a/source/rtos/Release_Specific/_Release_Notes.rst
+++ /dev/null
@@ -1,736 +0,0 @@
-************************************
-Release Notes
-************************************
-
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Release_Notes
-
-Overview
-==========
-
-The **Processor Software Development Kit (Processor-SDK)** provides the
-core foundation and building blocks that facilitate application software
-development on TI's embedded processors. This *Release Notes* focuses on
-the Real-time operating system (RTOS).
-
-|
-
-Licensing
-===========
-
-Please refer to the software manifest, which outlines the licensing
-status for all packages included in this release. The manifest can be
-found on the SDK download page or in the installed directory as
-indicated below.
-
-|
-
-Documentation
-===============
-
--  :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`:
-   Provides information on getting the software and running basic
-   examples/demonstrations bundled in the SDK.
--  :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` Provides
-   migration information for applications built on top of the Processor
-   SDK for RTOS.
--  :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>`
-   Provides information on features, functions, delivery package and,
-   compile tools for the Processor SDK RTOS release. This also provides
-   detailed information regarding software elements and software
-   infrastructure to allow developers to start creating applications.
--  **Software Manifest**: Provides license information on software
-   included in the SDK release. This document is in the release at
-   ``/processor_sdk_rtos_<SOC>_<version>/docs`` and available to view
-   from the software download page.
--  **EVM Quick Start Guide**: Provides information on hardware setup and
-   running the demonstration application that is loaded on flash. This
-   document is provided as part of the EVM kit.
-
-|
-
-Processor SDK v06.03.00
-========================
-
-Released Apr 2020
-
-.. rubric::  What's New
-   :name: whats-new
-
-.. rubric::  New Features
-   :name: new-features
-
-- Generic Updates
-    - Sysbios update to 6.76.03.01
-    - TI ARM CGT update to 18.12.5 LTS
-
-- AM65x
-    - Added Support for SR 2.0
-    - Added Thumb2 mode support for R5 cores
-    - `IPC LLD sample test for R5  to A53  running Linux <index_device_drv.html#example-details>`_
-    - `CSL: Baremetal example for ePWM, WWDT <index_device_drv.html#csl-fl-examples>`_
-    - EMAC Driver: Update to use NAVSS256L instead of MCU NAVSS
-    - Added support for ICSS-EMAC,NIMU ICSS EMAC
-
-- Descoped features
-    - Sercos3 softmaster demo on AM335x
-
-.. _release-notes-component-version:
-
-.. rubric::  Component Version
-   :name: component-version
-
-The following software components and host tools are bundled with the
-SDK installer. See the :ref:`Software Developer Guide <Index-Processor-SDK-RTOS-label>` for
-more information on each item.
-
-.. note::
-   | This release has been tested with the following component and tool versions. It is recommended to use the versions listed here to avoid compatibility issues.
-
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  Component  |   Version  |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E  | K2L  | K2G  |C665x |C667x |OMAP-L137|OMAP-L138|
-+=============+============+======+======+======+======+=======+======+======+======+======+======+=========+=========+
-| CG_XML      | 2.61.0     |   X  |  X   |  X   |  X   |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-| CTOOLSLIB   | 2.2.0.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  DSPLIB     | 3.4.0.4    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  EDMA3 LLD  | 2.12.5.30  |   X  |  X   |  X   |      |       |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  FC         | 3.40.2.7   |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  FFTLIB     | 3.1.0.0    |      |      |      |      |       |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  IMGLIB     | 3.1.1.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  IPC        | 3.50.4     |      |      |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |         |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  LIBARCH    | 1.0.0.0    |      |      |      |      |   X   |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  LINALG     | 1.2.0.0    |      |      |      |      |   X   |      |      |      |      |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  MATHLIB    | 3.1.2.4    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  MPM        | 3.0.4.0    |      |      |      |      |   X   |  X   |  X   |  X   |      |      |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  NDK        | 3.61.1     |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  NS         | 2.60.1     |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  OPENCL     | 1.2.0.2    |      |      |  X   |      |       |      |      |      |      |      |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  OPENMP     | 2.6.3.0    |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |         |         |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  PDK        |            |1.0.17|1.0.17|1.0.17| 1.0.7| 4.0.16|4.0.16|4.0.16|1.0.16|2.0.16|2.0.16|  1.0.11 |  1.0.11 |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  SYS/BIOS   | 6.76.3.1   |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  UIA        | 2.30.1.2   |      |      |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  XDAIS      | 7.24.0.4   |      |      |  X   |      |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-|  XDCTOOLS   | 3.55.02    |   X  |  X   |  X   |   X  |   X   |  X   |  X   |  X   |  X   |  X   |    X    |    X    |
-+-------------+------------+------+------+------+------+-------+------+------+------+------+------+---------+---------+
-
-
-The following compilers are bundled with the SDK installer:
-
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|    Compiler    | Version |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E | K2L    |  K2G   |C665x|C667x|OMAP-L137|OMAP-L138|
-+================+=========+======+======+======+======+=======+=====+========+========+=====+=====+=========+=========+
-|GNU ARM Embedded|7-2018-q2|   A8 |  A9  |  A15 |      |  A15  | A15 | A15    |  A15   |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|GNU Linaro GCC  | 7.2.1   |      |      |      | A53  |       |     |        |        |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI ARM CGT      | 18.12.5 |      |      |  M4  |  R5  |       |     |A15(SBL)|        |     | ARM9|   ARM9  |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI C6000 CGT    | 8.3.2   |      |      | C66x |      | C66x  |C66x | C66x   |  C66x  |C66x |C66x |   C674x |   C674x |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-|TI PRU CGT      | 2.3.2   | PRU  | PRU  | PRU  |  PRU |       |     |  PRU   |        |     |     |         |         |
-+----------------+---------+------+------+------+------+-------+-----+--------+--------+-----+-----+---------+---------+
-
-The SDK uses Code Composer Studio (CCS) as the integrated development
-environment (IDE) for all devices and EVMs:
-
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-| Component | Version  |AM335x|AM437x|AM57x |AM65x |K2H/K2K| K2E | K2L | K2G |C665x|C667x|OMAP-L137|OMAP-L138|
-+===========+==========+======+======+======+======+=======+=====+=====+=====+=====+=====+=========+=========+
-|   CCS     | 9.3.0    |   X  |  X   |  X   |  X   |   X   |  X  |  X  |  X  |  X  |  X  |    X    |    X    |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-|   EMU Pack|Sitara    |   X  |  X   |  X   |  X   |       |     |     |     |     |     |         |         |
-|           |Device    |      |      |      |      |       |     |     |     |     |     |         |         |
-|           |1.4.5     |      |      |      |      |       |     |     |     |     |     |         |         |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-|    TI     |8.3.0.0   |   X  |  X   |  X   |  X   |   X   |  X  |  X  |  X  |  X  |  X  |     X   |     X   |
-| Emulators |          |      |      |      |      |       |     |     |     |     |     |         |         |
-+-----------+----------+------+------+------+------+-------+-----+-----+-----+-----+-----+---------+---------+
-
-If you need to install CCS, see the `CCS installation section <index_overview.html#code-composer-studio>`__
-in the *Getting Started Guide* for options to select for Processor-SDK.
-
-
-
-Fixed Issues
-==============
-
-.. csv-table::
-   :header: "Record ID","Board/s", "Component/s", "Summary"
-   :widths: 15, 20,20,30
-
-	PRSDK-7627,"am654x-evm, am654x-hsevm, am654x-idk",PRUSS-Firmware,ICSSG: firmware - support changing of speed/duplex on the fly from DUT
-	PRSDK-7722,am654x-idk,PDK,PN_Switch: EMAC LLD free_pkt_cb callback function returns invalid data
-	PRSDK-5935,"am654x-evm, j721e-evm",UNIFLASH,Flashing speed for OSPI with Uniflash 5.0 is very poor (about 7KB/s)
-	PRSDK-6109,"am654x-evm, am654x-hsevm, am654x-idk, j721e-evm",Boot,ROM load time of SBL increased on GP devices because SBL is not signed with ROM degeneratekey
-	PRSDK-7907,am572x-evm,Chip Support,AM572x GP EVM eth0 is not working at 10Mbps
-	PRSDK-8171,"am335x-evm, beagleboneblack",PDK,UART DMA Transmission and Receiving isn't working
-	PRSDK-8343,am654x-idk,SCIClient,Sciclient_pmDeviceReset failing on SDK 6.3
-	PRSDK-7120,"j721e-evm, k2g-evm",PDK,SPI master slave test fails in non-dma callback mode
-	PRSDK-5966,"am654x-evm, am654x-hsevm, am654x-idk",Boot,PLL settings for Maxwell are not optimal
-	PRSDK-5397,am574x-idk,Chip Support,"CSL ECC EMIF test hangs at ""OCMC FULL ECC Mode"" on ARM"
-	PRSDK-7292,"am335x-evm, am335x-ice, amic110-ice, beagleboneblack",Control Drivers,AM335x SPI: No DMA support for McSPI slave mode examples
-	PRSDK-7898,j721e-evm,"Board Support, PDK",PSDKRA release docs indicate Uniflash support exists for J721E
-	PRSDK-8136,"am654x-evm, am654x-hsevm, am654x-idk",Chip Support,AM65xx: NAVSS bit field definitions missing from CSL
-	PRSDK-7518,am572x-evm,Documentation,PRSDK docs contains incorrect info concerning AM572x GP EVM camera support
-	PRSDK-8116,"am654x-evm, am654x-idk, j721e-evm",SCIClient,[SCICLIENT] Trail bytes logic overwrites response parameters
-	PRSDK-7958,am572x-idk,Control Drivers,AM57xx: C66 repeated McSPI loopback transfer crashes
-	PRSDK-8092,"am654x-evm, am654x-idk",Chip Support,AM65xx: A53_0 CSL ePWM example build incorrect & run-time failure
-	PRSDK-7489,"am571x-idk, am572x-idk",OSAL,AM57xx: OSAL Timer on DSP requires Board_init() with UART_STDIO_INIT
-	PRSDK-8020,"am654x-evm, am654x-idk",Documentation,AM65xx:R5F Incorrect documentation concerning RTOS template app
-	PRSDK-8117,"am570x-evm, am571x-idk, am572x-evm, am572x-idk, am574x-idk",Chip Support,AM5728: CSL cache API always returns error
-	PRSDK-3727,"c6748-evm, c6748-lcdk",PDK,C6748 is missing from SOC description list in pdkProjectCreate
-	PRSDK-8114,c6657-evm,Networking,C6657 NIMU ping test failure for packet size greater than 1510 bytes
-
-Known Issues
-==============
-
-This section contains the list of known issues at the time of making the
-release and any known workaround.
-
-.. csv-table::
-   :header: "Record ID","Board/s","Component/s","Summary","Workaround"
-   :widths: 15,100,20,30,20
-
-	PRSDK-769,Posix-SMP Demo DMIPS are wrong,Demonstrations,Multiple Platforms
-	PRSDK-5642,USB_DevBulk_ExampleProject: Failed to load/run app,Board Support,am335x-evm,Use JTAG to load and run the example
-	PRSDK-5186,"*Multiple platforms",Board Support,PDK Driver examples wrongly puts libgcc in to DDR invalidating IO delay configuration,"The user application could explicitly place the libgcc.a in to OCMC RAM along with BOARD_IO_DELAY_DATA/CODE sections so that there is no DDR access while calling IO Delay functions "
-	PRSDK-6653,"Diagnostics tests(Haptics,Temperature,Accelerometer,ADC,Ambient light, button, mmcsd) hangs on evmAM335x/AM437x",Diagnostics,"am335x-evm, am437x-evm"
-	PRSDK-2336,"am335x-evm, am437x-evm",Power,AM3 & AM4 PM Examples experience I2C bus lockup when communicating with PMIC,"The debug versions of the PM apps are still functional. To build them: From the top-level makefile in pdk.../packages folder run ""make BUILD_PROFILE=debug pm"" This will build the debug versions of the PM RTOS and measurement apps."
-	PRSDK-6043,TI-RTOS Kernel Example does not work with Resource Explorer in CCS 9.x,CCS,Multiple Platforms
-	PRSDK-8163,output from pinmux template file for AM335x causes ADP_Stopped exception in Board_init(),Board Support,am335x-ice,Existing pinmux files available in release will need to be updated
-	PRSDK-8300,"Diag(MEM,LED,MMCSD) test failures on am335x-ice",Diagnostics,am335x-ice
-	PRSDK-6184,BIOS 6.75 newlib-nano and header incompatibility with GCCv7.3.1 toolchain in SDK,System Integration,Multiple Platforms
-	PRSDK-335,USB host MSC fails to re-enumerate,High-Speed Drivers,"am437x-evm, k2g-evm",Re-enumeration support for the case of device unplugged and plugged back currently fails for the example. Workaround is to avoid disconnecting drive while running example
-	PRSDK-6161,ICSS_EMAC_BasicExample fails on AM437x IDK with errors in received acyclic pkt content,Networking,am437x-idk
-	PRSDK-5936,IO-Link master example does not work with Balluff inductive coupler,PDK,am437x-idk
-	PRSDK-4583,PRUSS-I2C-FW: Does not support 1Mhz mode. Incorrect STOP condition generated for HS mode,PRUSS-Firmware,am437x-idk
-	PRSDK-5938,I2C Master Slave Example: SPI TX/RX FIFO trigger level test failure (UT1),PDK,"am437x-idk, am571x-idk, am572x-idk"
-    PRSDK-2892,"am571x-idk, am572x-evm, am572x-idk",PDK,Incorrect A15 MMU configurations in default config file,"Set MMU attribute to not executable for device memory attrs0.noExecute = true; // Not executable"
-	PRSDK-5087,ICSS_EMAC_BasicExample fails on AM57xx-IDK with Packet cyclic timestamp error,Networking,"am571x-idk, am572x-idk, am574x-idk"
-	PRSDK-3876,CM_EMU_CLKSTCTRL=0x2 needed for reliable low power exit if EMU[1:0] pins are used as GPIOs,Boot,am572x-evm
-	PRSDK-5987,UART Rx/TX trigger level test fails in SMP mode for AM572x EVM (DMA),Control Drivers,am572x-evm
-	PRSDK-4667,Image Processing Demo lock up on AM572x GP EVM,"Demonstrations, Networking",am572x-evm,Issue seen using 1Gig router on ETH0. Replace with 100Mbps
-	PRSDK-1975,timer_DiagExample_evmAM572x_arm7.out doesn't work on ARM1 core,Diagnostics,am572x-evm,Example can run on ARM Core 0
-	PRSDK-6958,pm_rtos_testapp DSP/M4: shutdown test failed,Power,am572x-evm
-	PRSDK-3656,PM: shutdown test failed on DSP core for am572x-evm,Power,am572x-evm
-	PRSDK-8170,AM57xx: A15 QSPI flash block erase & DMA mode write issues,Control Drivers,am572x-idk,Use non-DMA (cpu based copy) instead of the DMA transfer
-	PRSDK-5879,Board: Board library needs to cover entire DDR region connected to EMIF1,Board Support,am654x-evm
-    PRSDK-7735,am65xx:Need to optimize time it takes to poll for packets from udma rings on R5,am654x-idk,"emac_poll_ctrl API is used to poll for rx packets, rx management responses and tx completion events. The parameters to this API are the port number, bitmap of receive packets, bitmap of management rings, and bitmap of tx completion rings to poll. The bitmaps are specified in the driver interface header file. In order to reduce the polling interval, it is recommended to call this API with only bitmap of rings that are required to be polled for an applications use call rather than polling for all the rings. Note that for release 6.3 applications and libraries for rR5F core are being compiled in thumb mode and initial testing indicates a ~20% reduction in cycle time versus release 6.1"
-	PRSDK-6382,SBL: R5F: Core 1 boot is not working with unsigned binary with ipc images,Boot,am654x-evm
-	PRSDK-4661,Maxwell: Board diagnostics LCD touchscreen test reports incorrect number of touch events,Diagnostics,"am654x-evm, am654x-hsevm, am654x-idk"
-	PRSDK-7908,R5 Board Diagnostics Apploader crashes on AM65x (PG1 & 2),PDK,"am654x-evm, am654x-hsevm, am654x-idk",Board Diagnostics can be executed from A53
-	PRSDK-7176,AM65x R5 diagnostic tests are hanging while running from diag framework,Board Support,"am654x-evm, am654x-idk"
-	PRSDK-2951,Maxwell_M4_Diag: LCD Display Diagnostic Stress Test,"Board Support, Diagnostics","am654x-evm, am654x-idk"
-	PRSDK-5074,McASP driver hangs with small buffer size,PDK,"am654x-evm, j721e-evm",Use packet size 32 samples or greater
-	PRSDK-5626,OSPI Read using UDMA fails on AM65x HS devices.,"Boot, DMA",am654x-hsevm,Non-DMA mode could be used for the read operation
-	PRSDK-5229,PCIe diagnostic test validates only one port on PCIe 2-lane card,Board Support,am654x-idk
-	PRSDK-5989,USB Host MSC test hangs in SMP mode on AM65xx IDK board,Control Drivers,am654x-idk
-	PRSDK-5751,AM65xx IDK PCIe diagnostic test failure,Diagnostics,am654x-idk
-	PRSDK-5022,am65xx: Running emac unit test on R5 core from ddrless SBL at times does not complete execution,Networking,am654x-idk
-	PRSDK-3114,K2G: RTOS ECC support broken on ARM core,Diagnostics,"k2g-evm, k2g-hsevm, k2g-ice"
-	PRSDK-2989,MMCSD LLD fails on OMAPl137 with 1024 byte block size,High-Speed Drivers,omapl137-evm
-	PRSDK-4043,OMAPL13x: USB Baremetal project binaries not built via top level make,High-Speed Drivers,"omapl137-evm, omapl138-lcdk"
-
-.. _RN-Supported-Platforms-label:
-
-Supported Platforms
-=====================
-
-Devices
----------
-
-The following table lists all supported devices for a given installer.
-
-+----------------+------------+-------------------------------------------------------------------------------+
-|   Installer    |Platform/SOC|                                 Supported Devices                             |
-+================+======+=====+===============================================================================+
-|                |`AM335x`_   | `AM3351`_, `AM3352`_, `AM3354`_, `AM3356`_, `AM3357`_, `AM3358`_, `AM3359`_   |
-|`RTOS-AM335X`_  +------------+-------------------------------------------------------------------------------+
-|                |`AMIC11x`_  | `AMIC110`_                                                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-AM437X`_  |`AM437x`_   | `AM4376`_, `AM4377`_, `AM4378`_, `AM4379`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-AM57X`_   |`AM57x`_    |`AM5706`_, `AM5708`_, `AM5716`_, `AM5718`_, `AM5726`_, `AM5728`_,              |
-|                |            |`AM5746`_, `AM5748`_                                                           |
-+----------------+------------+-------------------------------------------------------------------------------+
-| `RTOS-AM65X`_  | `AM65x`_   |`AM6526`_, `AM6527`_, `AM6528`_, `AM6546`_, `AM6548`_, DRA80xM                 |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-C665X`_   |`C665x`_    | `C6652`_, `C6654`_, `C6655`_, `C6657`_                                        |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-C667X`_   |`C667x`_    | `C6671`_, `C6672`_, `C6674`_, `C6678`_                                        |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2E`_     |`K2E`_      | `66AK2E02`_, `66AK2E05`_, `AM5K2E02`_, `AM5K2E04`_                            |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2G`_     |`K2G`_      | `66AK2G02`_, `66AK2G12`_                                                      |
-+----------------+------------+-------------------------------------------------------------------------------+
-|                |`K2H`_      | `66AK2H06`_, `66AK2H12`_, `66AK2H14`_                                         |
-| `RTOS-K2HK`_   +------------+-------------------------------------------------------------------------------+
-|                |`K2K`_      | `TCI6638K2K`_                                                                 |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-K2L`_     |`K2L`_      | `66AK2L06`_                                                                   |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-OMAPL137`_|`OMAP-L1x`_ | `OMAP-L137`_, `C6743`_, `C6745`_, `C6747`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-|`RTOS-OMAPL138`_|`OMAP-L1x`_ | `OMAP-L138`_, `C6742`_, `C6746`_, `C6748`_                                    |
-+----------------+------------+-------------------------------------------------------------------------------+
-
-
-.. _RTOS-AM335X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM335X/latest/index_FDS.html
-.. _AM335x: http://www.ti.com/am335x
-.. _AM3351: http://www.ti.com/product/am3351
-.. _AM3352: http://www.ti.com/product/am3352
-.. _AM3354: http://www.ti.com/product/am3354
-.. _AM3356: http://www.ti.com/product/am3356
-.. _AM3357: http://www.ti.com/product/am3357
-.. _AM3358: http://www.ti.com/product/am3358
-.. _AM3359: http://www.ti.com/product/am3359
-
-.. _AMIC11x: http://www.ti.com/lsds/ti/processors/sitara/industrial-ethernet/amic11x/amic11x-overview.page>`__
-.. _AMIC110: http://www.ti.com/product/amic110
-
-.. _RTOS-AM437X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM437X/latest/index_FDS.html
-.. _AM437x: http://www.ti.com/am437x
-.. _AM4376: http://www.ti.com/product/am4376
-.. _AM4377: http://www.ti.com/product/am4377
-.. _AM4378: http://www.ti.com/product/am4378
-.. _AM4379: http://www.ti.com/product/am4379
-
-.. _RTOS-AM57X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/latest/index_FDS.html
-.. _AM57x: http://www.ti.com/am57x
-.. _AM5706: http://www.ti.com/product/am5706
-.. _AM5708: http://www.ti.com/product/am5708
-.. _AM5716: http://www.ti.com/product/am5716
-.. _AM5718: http://www.ti.com/product/am5718
-.. _AM5726: http://www.ti.com/product/am5726
-.. _AM5728: http://www.ti.com/product/am5728
-.. _AM5746: http://www.ti.com/product/am5746
-.. _AM5748: http://www.ti.com/product/am5748
-
-.. _RTOS-AM65X: http://software-dl.ti.com/processor-sdk-rtos/esd/AM65X/latest/index_FDS.html
-.. _AM65x: http://www.ti.com/am65x
-.. _AM6526: http://www.ti.com/product/am6526
-.. _AM6527: http://www.ti.com/product/am6527
-.. _AM6528: http://www.ti.com/product/am6528
-.. _AM6546: http://www.ti.com/product/am6546
-.. _AM6548: http://www.ti.com/product/am6548
-
-.. _RTOS-C665X: http://software-dl.ti.com/processor-sdk-rtos/esd/C665x/latest/index_FDS.html
-.. _C665x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp/c66x/overview.page
-.. _C6652: http://www.ti.com/product/tms320c6652
-.. _C6654: http://www.ti.com/product/tms320c6654
-.. _C6655: http://www.ti.com/product/tms320c6655
-.. _C6657: http://www.ti.com/product/tms320c6657
-
-.. _RTOS-C667X: http://software-dl.ti.com/processor-sdk-rtos/esd/C667x/latest/index_FDS.html
-.. _C667x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp/c66x/overview.page
-.. _C6671: http://www.ti.com/product/tms320c6671
-.. _C6672: http://www.ti.com/product/tms320c6672
-.. _C6674: http://www.ti.com/product/tms320c6674
-.. _C6678: http://www.ti.com/product/tms320c6678
-
-.. _RTOS-K2E: http://software-dl.ti.com/processor-sdk-rtos/esd/K2E/latest/index_FDS.html
-.. _K2E: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2E02: http://www.ti.com/product/66ak2e02
-.. _66AK2E05: http://www.ti.com/product/66ak2e05
-.. _AM5K2E02: http://www.ti.com/product/am5k2e02
-.. _AM5K2E04: http://www.ti.com/product/am5k2e04
-
-.. _RTOS-K2G: http://software-dl.ti.com/processor-sdk-rtos/esd/K2G/latest/index_FDS.html
-.. _K2G: http://www.ti.com/processors/dsp/c6000-dsp-arm/66ak2x/overview.html
-.. _66AK2G02: http://www.ti.com/product/66ak2g02
-.. _66AK2G12: http://www.ti.com/product/66ak2g12
-
-.. _RTOS-K2HK: http://software-dl.ti.com/processor-sdk-rtos/esd/K2HK/latest/index_FDS.html
-.. _K2H: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2H06: http://www.ti.com/product/66ak2h06
-.. _66AK2H12: http://www.ti.com/product/66ak2h12
-.. _66AK2H14: http://www.ti.com/product/66ak2h14
-
-.. _K2K: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _TCI6638K2K: http://www.ti.com/product/tci6638k2k
-
-.. _RTOS-K2L: http://software-dl.ti.com/processor-sdk-rtos/esd/K2L/latest/index_FDS.html
-.. _K2L: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/66ak2x/overview.page
-.. _66AK2L06: http://www.ti.com/product/66ak2l06
-
-.. _RTOS-OMAPL137: http://www.ti.com/tool/processor-sdk-omapl137
-.. _OMAP-L1x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/omap-l1x/overview.page
-.. _OMAP-L137: http://www.ti.com/product/OMAP-L137
-.. _C6743: http://www.ti.com/product/tms320c6743
-.. _C6745: http://www.ti.com/product/tms320c6745
-.. _C6747: http://www.ti.com/product/tms320c6747
-
-.. _RTOS-OMAPL138: http://www.ti.com/tool/processor-sdk-omapl138
-.. _OMAP-L1x: http://www.ti.com/lsds/ti/processors/dsp/c6000_dsp-arm/omap-l1x/overview.page
-.. _OMAP-L138: http://www.ti.com/product/OMAP-L138
-.. _C6742: http://www.ti.com/product/tms320c6742
-.. _C6746: http://www.ti.com/product/tms320c6746
-.. _C6748: http://www.ti.com/product/tms320c6748
-
-Evaluation Modules
---------------------
-
-See :ref:`Processor SDK Supported Platforms <RTOS-SDK-Supported-Platforms>`
-page for a list of supported EVMs per platform and links to more
-information.
-
-Demonstrations
-----------------
-
-See `Examples and Demonstrations <Examples_and_Demonstrations.html>`__
-page for a list of demonstrations per platform and EVM.
-
-Drivers
----------
-
-The following tables show RTOS driver availability per platform and EVM.
-A shaded box implies that the feature is not applicable for that
-platform/EVM.
-
-**Sitara devices**
-
-+------------------+--------------------------------+---------------+-----------+-----------+-----------+----------+
-|     Feature      |    Platform/SOC                |  AM335x EVM   |AM437x EVM | AM57x EVM | AM65x EVM |J721E EVM |
-+==================+=======+======+=====+=====+=====+===+===+===+===+===+===+===+=====+=====+=====+=====+==========+
-|                  |AM335x |AM437x|AM57x|AM65x|J721E|GP |ICE|SK |BBB|GP |IDK|SK | GP  | IDK | GP  | IDK |  GP      |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| CSL              |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| EMAC             |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| EDMA3            |   X   |   X  |  X  |     |     | X |   |   |   | X |   |   |  X  |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| GPIO             |   X   |   X  |  X  |  X  |  X  |   | X |   | X | X |   | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| GPMC             |   X   |   X  |     |     |     |   | X |   |   | X |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| I2C              |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS-I2C f/w    |   X   |   X  |  X  |     |     |   | X |   |   |   | X |   |     |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS-eSPI f/w   |   X   |   X  |     |     |     |   |   |   |   |   |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| ICSS-EMAC        |   X   |   X  |  X  |  X  |     |   | X |   |   |   | X |   |     |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| McASP            |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| McSPI            |   X   |   X  |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |   X |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| MMC-SD           |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PCIe             |       |      |  X  |  X  |     |   |   |   |   |   |   |   |     |  X  |  X  |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PM               |   X   |      |  X  |  X  |  X  | X |   |   |   |   |   |   |  X  |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| PRUSS            |   X   |   X  |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| QSPI             |       |   X  |  X  |  X  |  X  |   |   |   |   |   | X | X |     |  X  |     |     |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| OSPI             |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| UART             |   X   |   X  |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB              |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |   X |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB Device Audio |   X   |      |     |     |     | X |   |   |   |   |   |   |     |     |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| USB Device Bulk  |   X   |   X  |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |   X |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| VPS              |       |      |  X  |     |     |   |   |   |   |   |   |   |  X  |  X  |     |     |          |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| UDMA             |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| SCICLIENT        |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| SA               |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| CAL              |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| DSS              |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-| FVID2            |       |      |     |  X  |  X  |   |   |   |   |   |   |   |     |     |  X  |  X  |  X       |
-+------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+----------+
-
-**DSP devices - K2x, C66x**
-
-+------------------+-------------------------------+-----------------------+-----------+
-|     Feature      |         Platform/SOC          |        K2 EVM         | C66x EVM  |
-+==================+=======+===+===+===+=====+=====+===+===+===+===+=======+=====+=====+
-|                  |K2H/K2K|K2E|K2L|K2G|C665x|C667x|K2H|K2E|K2L|K2G|K2G-ICE|C665x|C667x|
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| CSL              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| AIF2             |   X   |   |   |   |     |     | X |   |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| BCP              |   X   |   | X |   |     |     | X |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| CPPI             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| DFE              |       |   | X |   |     |     |   |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| EDMA3            |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| EMAC             |       |   |   | X |  X  |     |   |   |   | X |   X   |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| FFTC             |   X   |   | X |   |     |     | X |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| GPIO             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| HYPLNK           |   X   | X |   |   |  X  |  X  | X | X |   |   |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| ICSS-EMAC        |       |   |   | X |     |     |   |   |   |   |   X   |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| I2C              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IQN2             |       |   | X |   |     |     |   |   | X |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| McASP            |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| McBSP            |       |   |   | X |  X  |     |   |   |   | X |       |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MMAP             |   X   | X |   |   |     |     | X | X |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MMC-SD           |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| NWAL             |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PA               |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PCIe             |   X   | X | X | X |  X  |  X  | X | X | X | X |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| QMSS             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| RM               |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SA               |   X   | X | X | X |     |  X  | X | X | X | X |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SPI              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SRIO             |   X   |   |   |   |  X  |  X  | X |   |   |   |       |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| TCP3D            |   X   |   | X |   |  X  |     | X |   | X |   |       |  X  |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| TSIP             |       | X |   |   |     |  X  |   | X |   |   |       |     |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| UART             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB              |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB Device Audio |       |   |   |   |     |     |   |   |   |   |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| USB Device Bulk  |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-
-
-**DSP devices - OMAP-L13x, C674x**
-
-+----------------+-------------------+-------------+----------------+
-|    Feature     |   Platform/SOC    |OMAP-L137 EVM| OMAP-L138 EVM  |
-+================+=========+=========+=============+=======+========+
-|                |OMAP-L137|OMAP-L138| L137/6747 SK|LCDK138|LCDK6748|
-+----------------+---------+---------+-------------+-------+--------+
-|CSL             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|EDMA3           |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|EMAC            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|GPIO            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|I2C             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|McASP           |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|MMC-SD          |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|SPI             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|UART            |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB             |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB Device Audio|    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-|USB Device Bulk |    X    |    X    |      X      |   X   |   X    |
-+----------------+---------+---------+-------------+-------+--------+
-
-**Unsupported Features**
-
-- In general driver support is available across all cores within an SOC
-  with following exceptions
-
-+----------------+-------------------+
-|    Feature     | Not supported     |
-+================+=========+=========+
-|                |SOC      |CPU/Core |
-+----------------+---------+---------+
-|McASP           |  AM57x  |    M4   |
-+----------------+---------+---------+
-|USB             |  AM57x  |    C66x |
-+----------------+---------+---------+
-|USB             |  AM57x  |    M4   |
-+----------------+---------+---------+
-|USB             |  K2G    |    C66x |
-+----------------+---------+---------+
-|McBSP           |  K2G    |    A15  |
-+----------------+---------+---------+
-|McBSP           |OMAP-L13x|    ARM9 |
-+----------------+---------+---------+
-|All Drivers     | K2E/L/K |    A15  |
-+----------------+---------+---------+
-
-Other Features
-----------------
-
-The following table shows other feature availability per platform and
-EVM:
-
-**Sitara devices**
-
-+----------------------------+--------------------------------+---------------+-----------+-----------+-----------+ -----------+
-|          Feature           |    Platform/SOC                |   AM335x EVM  |AM437x EVM | AM57x EVM | AM65x EVM |  J721E EVM |
-+============================+=======+======+=====+=====+=====+===+===+===+===+===+===+===+=====+=====+=====+=====+============+
-|                            |AM335x |AM437x|AM57x|AM65x|J721E|GP |ICE|SK |BBB|GP |IDK|SK | GP  | IDK | GP  | IDK |  GP        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Board Support              |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Boot (SBL)                 |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| Diagnostics                |   X   |  X   |  X  |  X  |  X  | X |   |   |   | X |   |   |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| FATFS                      |   X   |  X   |  X  |  X  |  X  | X | X |   |   | X | X |   |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| NDK-NIMU(CPSW)             |   X   |  X   |  X  |  X  |  X  | X | X | X | X | X | X | X |  X  |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-| NDK-NIMU(ICSS)             |   X   |  X   |  X  |  X  |  X  |   | X |   |   |   | X |   |     |  X  |  X  |  X  |   X        |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-|CC-LINK IE Field Basic(CPSW)|   X   |  X   |  X  |     |     | X | X | X | X | X | X | X |  X  |  X  |     |     |            |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-|CC-Link IE Field Basic(ICSS)|   X   |  X   |  X  |     |     |   | X |   |   |   | X |   |     |  X  |     |     |            |
-+----------------------------+-------+------+-----+-----+-----+---+---+---+---+---+---+---+-----+-----+-----+-----+ -----------+
-
-**DSP devices - K2x, C66x**
-
-+----------------------------+-------------------------------+-----------------------+-----------+
-|          Feature           |         Platform/SOC          |        K2 EVM         | C66x EVM  |
-+============================+=======+===+===+===+=====+=====+===+===+===+===+=======+=====+=====+
-|                            |K2H/K2K|K2E|K2L|K2G|C665x|C667x|K2H|K2E|K2L|K2G|K2G-ICE|C665x|C667x|
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Board Support              |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Boot (IBL/SBL)             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Diagnostics                |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| FATFS                      |       |   |   | X |     |     |   |   |   | X |   X   |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Fault Management           |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IPC Transport (QMSS)       |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| IPC Transport (SRIO)       |   X   |   |   |   |  X  |  X  | X |   |   |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| MAD-UTIL                   |       |   |   |   |  X  |  X  |   |   |   |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Network (CPSW)             |   X   | X | X | X |  X  |  X  | X | X | X | X |   X   |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Network (ICSS)             |       |   |   | X |     |     |   |   |   | X |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-|CC-Link IE Field Basic(ICSS)|       |   |   | X |     |     |   |   |   | X |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-|Platform Library (obsolete) |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| PKTLIB                     |   X   | X | X |   |     |  X  | X | X | X |   |       |     |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| POST                       |   X   | X | X |   |  X  |  X  | X | X | X |   |       |  X  |  X  |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| SERDES Diagnostics         |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-| Trace Framework            |   X   | X | X |   |     |     | X | X | X |   |       |     |     |
-+----------------------------+-------+---+---+---+-----+-----+---+---+---+---+-------+-----+-----+
-
-
-**DSP devices - OMAP-L13x, C674x**
-
-+--------------+-------------------+-------------+----------------+
-|   Feature    |   Platform/SOC    |OMAP-L137 EVM| OMAP-L138 EVM  |
-+==============+=========+=========+=============+=======+========+
-|              |OMAP-L137|OMAP-L138| 137/6747 SK |LCDK138|LCDK6748|
-+--------------+---------+---------+-------------+-------+--------+
-|Board Support |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Boot (SBL)    |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Diagnostics   |    X    |         |      X      |       |        |
-+--------------+---------+---------+-------------+-------+--------+
-|FATFS         |    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-|Network (CPSW)|    X    |    X    |      X      |   X   |   X    |
-+--------------+---------+---------+-------------+-------+--------+
-
-Installation and Usage
-========================
-
-The :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>` provides
-instructions on how to setup up your development environment, install
-the SDK and start your development.
-
-To uninstall the SDK, remove the individual component directories from
-the installed path. This is safe to do even in Windows since these
-components do not modify the Windows registry.
-
-|
-
-Technical Support and Product Updates
-=======================================
-
-For further information or to report any problems, contact:
--  `TI E2E Processor Support <https://e2e.ti.com/support/processors/>`__ for all supported platforms
-
-
-|
-
-Archived
-==========
--  `Processor-SDK RTOS
-   6.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_01_00_08/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   6.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_00_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_03_00_07/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.2.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_02_00_10/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.1.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_01_00_11/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_15/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   5.0.0 AM65x EA Release <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_00_00_09/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
--  `Processor-SDK RTOS
-   4.3.0 <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/04_03_00_05/rtos/Release_Specific.html#processor-sdk-rtos-release-notes>`__
-
-**Note:** Release Notes prior to 4.3 are not archived. Please see the
-:ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>` for information on
-migration from these releases.
-
-|
-
diff --git a/source/rtos/Tools/Code_Composer_Studio/_CCS_v6_Getting_Started.rst b/source/rtos/Tools/Code_Composer_Studio/_CCS_v6_Getting_Started.rst
deleted file mode 100644
index be816daac..000000000
--- a/source/rtos/Tools/Code_Composer_Studio/_CCS_v6_Getting_Started.rst
+++ /dev/null
@@ -1,144 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/CCSv6_Getting_Started_Guide
-
-.. rubric:: Introduction
-   :name: introduction
-
-Welcome to Code Composer Studio v6! Code Composer Studio v6 is a major
-new release of Code Composer Studio (CCS) that is based on the Eclipse
-open source software framework. The Eclipse software framework is used
-for many different applications but it was originally developed as a
-open framework for creating development tools. We have chosen to base
-CCS on Eclipse as it offers an excellent software framework for building
-software development environments and is becoming a standard framework
-used by many embedded software vendors. CCSv5 combines the advantages of
-the Eclipse software framework with advanced embedded debug capabilities
-from Texas Instruments resulting in a compelling feature rich
-development environment for embedded developers.
-
-**Note:** This guide is designed for the latest release of CCSv6.
-
-.. rubric:: Obtaining CCS
-   :name: obtaining-ccs
-
-Code Composer Studio v6 can be downloaded directly to your PC.
-
-`GSG:CCSv6 Download <http://processors.wiki.ti.com/index.php/GSG:CCSv6_Download>`__
-
-.. rubric:: Installing CCS
-   :name: installing-ccs
-
-The installation process is the same for both delivery methods (DVD or
-download).
-
-`GSG:CCSv6 installation <http://processors.wiki.ti.com/index.php/GSG:CCSv6_installation>`__
-
-.. rubric:: Running CCS for the first time
-   :name: running-ccs-for-the-first-time
-
-When executed for the first time, Code Composer Studio v6 requires a few
-additional steps to operate properly:
-
--  Select a workspace, where all the projects will be placed
--  An active license
-
-Follow the link below to learn about these last steps:
-
-`GSG:CCSv6 Running for the first
-time <http://processors.wiki.ti.com/index.php/GSG:CCSv6_Running_for_the_first_time>`__
-
-.. rubric:: Working with CCS
-   :name: working-with-ccs
-
-.. rubric:: Code Development
-   :name: code-development
-
-All work on Code Composer Studio is based on projects - a collection of
-source, include and configuration files.
-
-| The most interesting way to get started on CCSv6 is to follow one of
-  the basic training modules that are published in this wiki server.
-
-`Device_Specific_Workshops_with_CCS <http://processors.wiki.ti.com/index.php/Device_Specific_Workshops_with_CCS>`__
-`CCS_Fundamentals_Workshop <http://processors.wiki.ti.com/index.php/CCS_Fundamentals_Workshop>`__
-
-| **Important!** The modules above require software libraries and
-  components that are not installed with CCSv6 by default: MSP430Ware,
-  Tivaware, ControlSUITE, Starterware, SYSBIOS, MCSDK, etc. These
-  components must be downloaded separately, and the easiest way to find
-  them is through the CCS App Center. To explore that and a few other
-  features, check the short video below:
-
-Additional quick start guides and videos can be found at the `CCS
-Training category <http://processors.wiki.ti.com/index.php/Category:CCS_Training>`__.
-
-.. rubric:: Advanced Topics
-   :name: advanced-topics
-
-The following topics are identical between CCSv5 and CCSv6, therefore
-they link to the same page between the two versions.
-
-.. rubric:: Advanced target configurations
-   :name: advanced-target-configurations
-
-The sections below describe several procedures used in complex target
-configurations.
-
-`GSG:Common_target_configurations_v5 <http://processors.wiki.ti.com/index.php/GSG:Common_target_configurations_v5>`__
-`GSG:Adding GEL files to a target configuration
-v5 <http://processors.wiki.ti.com/index.php/GSG:Adding_GEL_files_to_a_target_configuration_v5>`__
-`GSG:Connecting to target cores in SoC devices
-v5 <http://processors.wiki.ti.com/index.php/GSG:Connecting_to_target_cores_in_SoC_devices_v5>`__
-`http://processors.wiki.ti.com/index.php/Target_Configuration_-_Custom_Configurations <http://processors.wiki.ti.com/index.php/Target_Configuration_-_Custom_Configurations>`__
-
-.. rubric:: Linux development
-   :name: linux-development
-
-One additional feature in CCSv6 is the ability to create projects and
-debug code for embedded Linux environments.
-
-The topics below shows how to create projects for Linux that use the
-open source compiler suite (GCC), as well as perform debugging in this
-environment.
-
-`How to create GCC projects in
-CCSv5 <http://processors.wiki.ti.com/index.php/How_to_create_GCC_projects_in_CCSv5>`__
-`Sitara_Linux_SDK_CCS_Debug <http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_CCS_Debug>`__
-
-.. rubric:: Resources and References
-   :name: resources-and-references
-
--  Main Code Composer Studio v6 wiki page:
-
-`http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v6 <http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v6>`__
-
--  Frequently asked questions:
-
-`http://processors.wiki.ti.com/index.php/FAQ_-_CCSv6 <http://processors.wiki.ti.com/index.php/FAQ_-_CCSv6>`__
-
--  Eclipse Concepts:
-
-`http://processors.wiki.ti.com/index.php/Eclipse_Concepts <http://processors.wiki.ti.com/index.php/Eclipse_Concepts>`__
-
-.. rubric:: Example projects, libraries and source code
-   :name: example-projects-libraries-and-source-code
-
-**1.** Stellarisware libraries and example code:
-
-http://focus.ti.com/docs/toolsw/folders/print/sw-lm3s.html
-**2.** MSP430 source code:
-
-http://focus.ti.com/mcu/docs/mcuprodcodeexamples.tsp?sectionId=96&tabId=1468
-**3.** TMS320C2000 libraries and example code:
-
-http://focus.ti.com/mcu/docs/mcuprodcodeexamples.tsp?sectionId=96&tabId=1470
-**4.** TMS320C5500 Libraries:
-
-Chip Support Library (CSL):
-http://focus.ti.com/docs/toolsw/folders/print/sprc133.html
-DSP Library (DSPLIB):
-http://focus.ti.com/docs/toolsw/folders/print/sprc100.html
-Image Library (IMGLIB):
-http://focus.ti.com/docs/toolsw/folders/print/sprc101.html
-**5.** TMS320C6000 Libraries:
-
-http://focus.ti.com/dsp/docs/dspfindtoolswresults.tsp?sectionId=3&tabId=1620&familyId=44&toolTypeId=24&go=Go
diff --git a/source/rtos/Tools/Code_Composer_Studio/_Multi_Core_System_Analyzer.rst b/source/rtos/Tools/Code_Composer_Studio/_Multi_Core_System_Analyzer.rst
deleted file mode 100644
index c5aa9d192..000000000
--- a/source/rtos/Tools/Code_Composer_Studio/_Multi_Core_System_Analyzer.rst
+++ /dev/null
@@ -1,383 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Multicore_System_Analyzer
-
-.. rubric:: Overview
-   :name: overview
-
-System Analyzer is a real-time tool for analyzing, visualizing and
-profiling application running on single or multi core systems. Data is
-collected using UIA (Unified Instrumentation Architecture) software
-instrumentation on the target and transported via Ethernet, run-mode
-JTAG, stop-mode JTAG, USB or UART to the host PC for analysis and
-visualization in Code Composer Studio.
-
-In a multi core system, data from all cores are correlated to a single
-timeline.
-
-.. Image:: /images/SA.png
-.. rubric:: Unified Instrumentation Architecture (UIA)
-   :name: unified-instrumentation-architecture-uia
-
-UIA is the target-side package which defines the APIs, transports,
-interfaces and guidelines that enable developers to instrument embedded
-software in a way that is portable and flexible. It enables the creation
-of advanced tooling that can be used both in the lab and in the field.
-The framework includes:
-
--  a messaging infrastructure that allows instrumentation clients to
-   interact with instrumentation endpoints on a target device while the
-   target is running
--  an extensible set of commands and messages that can be sent over the
-   messaging infrastructure
--  protocols to be used by the target-side instrumentation framework and
-   the host-side instrumentation client
--  built-in instrumentation for DSP/BIOS for 'out of the box' real-time
-   visibility into the operation of the O/S
--  guidelines on how to instrument other RTOSes
-
-.. rubric:: Portable and Flexible
-   :name: portable-and-flexible
-
-System Analyzer and UIA are designed to be portable and flexible:
-
--  ISA independent: UIA can be re-used across a wide range of TI
-   platforms, single-core devices and multi-core devices
--  O/S independent: UIA not tied to any specific operating system
--  Transport independent: can use a wide variety of different transports
-   to upload software events from the target to the host, without having
-   to change the source code
--  Platform independent: Host-side tooling works on both Windows and
-   Linux platforms
--  IDE independent: Host-side tooling will support both tight
-   integration with Code Composer Studio and stand-alone operation for
-   use with other IDEs.
-
-System Analyzer together with it's UIA packages define an
-instrumentation framework that enables the development of
-instrumentation client tools, instrumented target content,
-infrastructure components, and instrumentation middleware components
-that interoperate and can be re-used across TI platforms and devices.
-
-.. rubric:: Available Analysis
-   :name: available-analysis
-
--  RTOS Execution Graph
--  CPU Load
--  Task Load
--  Duration Analysis
--  Context-aware Function Profiler
--  Concurrency Analysis
--  Task Profiler
--  Count/Statistical Analysis
-
-.. rubric:: Execution Graph
-   :name: execution-graph
-
-Graphical representation of RTOS context switches, events, semaphores,
-HWIs and SWIs. Start/Stop events logged for Duration Analysis and
-Enter/Exit events logged for Function Profiler are also shown in graph.
-In a multi core system all cores are shown in the same graph on the same
-timeline.
-
-.. rubric:: CPU Load
-   :name: cpu-load
-
-Graphical representation and min, max, average statistics of CPU loading
-data collected from RTOS.
-In a multi core system loading and statistics for all cores are shown.
-
-.. rubric:: Task Load
-   :name: task-load
-
-Graphical representation and min, max, average statistics of task
-loading data collected from RTOS.
-In a multi core system different instance of analysis can be opened for
-each core.
-
-.. rubric:: Duration Analysis
-   :name: duration-analysis
-
-Analyze time to perform operations. Start/Stop events logged for each
-operation is used to calculate and graph the time for each instance of
-each operation. Summary statistics (including count, min, max and
-average) is also shown for each operation.
-
-.. rubric:: Context Aware Function Profiler
-   :name: context-aware-function-profiler
-
-Min, max and average inclusive time (includes time spend in called
-functions) and exclusive time (excludes time spent in called functions)
-for functions. Functions to be profiled must have their entry and exit
-instrumented. See FAQ below on how to leverage compiler entry/exit hook
-functions. For context awareness, RTOS context switch logging must also
-be enabled.
-
-.. rubric:: Concurrency Analysis
-   :name: concurrency-analysis
-
-This is a multi-core tool to analyze parallel execution of application
-across multiple cores. RTOS Idle task is use to determine when the core
-is not in use. Task switch logging must be enabled for this analysis.
-
-.. rubric:: Task Profiler
-   :name: task-profiler
-
-The task profiler analyzes what percent of time tasks are spending in
-their different states. RTOS context switch events are required for this
-analysis.
-
-.. rubric:: Count/Statistical Analysis
-   :name: countstatistical-analysis
-
-Graphical representation of any counter/variable that is being logger.
-Also calculates number of occurrences and min, max, average value for
-each counter/variable.
-
-**Note:** TIRTOS/SYSBIOS instrumentation is not enabled by default.
-  See User Guide or Tutorials on how to enable this.
-
-**Note:** More information on the analysis features is available in the
-`System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: Documents and Tutorials
-   :name: documents-and-tutorials
-
-`System Analyzer Getting Started
-Guide </images/7/7b/MCSA1.1_Getting_Started_Guide.pdf>`__ - Get familar
-with System Analyzer features using a data file shipped with CCStudio.
-
-`System Analyzer User's Guide </images/b/bc/MCSA1.1_User_Guide.pdf>`__ -
-Detail guide on configuring and using System Analyzer and UIA.
-
-`System Analyzer Tutorials
-(CCSv5) <http://processors.wiki.ti.com/index.php/System_Analyzer_Tutorials_(CCSv5)>`__ - Includes a
-series of projects that can be built and use, along with step-by-step
-walkthroughs of how to configure code, set up System Analyzer, work with
-Analysis Features, etc.
-
-.. rubric:: System Analyzer and the MCSDK Demo
-   :name: system-analyzer-and-the-mcsdk-demo
-
-System Analyzer provides visibility into the real-time behavior and
-performance of the `BIOS MCSDK
-2.0 <http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide>`__
-Image Processing Demo. The `System Analyzer and the MCSDK
-Demo <http://processors.wiki.ti.com/index.php/MCSA_and_the_MCSDK_Demo>`__
-page provides more information about how to use System Analyzer with the
-MCSDK.
-
-.. rubric:: Known Issues/Errata
-   :name: known-issueserrata
-
-.. rubric:: CCS Crash when opening Graph in System Analyzer
-   :name: ccs-crash-when-opening-graph-in-system-analyzer
-
--  It appears that some graphics card drivers are not compatible with
-   Eclipse support for text rotation. This may result in a CCS crash
-   (inside the graphics driver) when opening graphs in System Analyzer
-   (graphs use text rotation for y-axis label). If you encounter this
-   problem, try updating the graphics card driver. This has resolved the
-   occurrences of this problem we've seen so far.
-
-.. rubric:: Multicore correlation not working
-   :name: multicore-correlation-not-working
-
--  Multicore event correlation is not automatically supported for JTAG
-   transports (it is supported for Ethernet). User can explicitly add
-   synchronization logs to enable correlation. (See `Tutorial
-   4B <http://processors.wiki.ti.com/index.php/System_Analyzer_Tutorial_4B>`__
-   for details)
--  if the target is halted (either by explict halt or implicit halts
-   such as Console I/O / CIO) while data is being collected via Ethernet
-   then correlation will not work.
--  if some target is generating data very infrequently then correlation
-   may timeout resulting in uncorrelated data. In this case the data can
-   be saved to a binary file and post process for correlation to work.
-
-.. rubric:: uia_1_00_04_35 : Tutorial 1 and Tutorial 2 do not build
-   properly.
-   :name: uia_1_00_04_35-tutorial-1-and-tutorial-2-do-not-build-properly.
-
--  The build fails with the error *"dc.services.global.XDCException:
-   xdc.PACKAGE_NOT_FOUND: can't locate the package 'ti.sysbios.knl'"*
--  To overcome this, please unzip
-
-.. Image:: /images/UIAMetaData.zip
-   <uia_1_00_04_35 install folder>/packages/ti/uia/runtime/ to update
-   the UIAMetaData.xs file. Then delete the <Debug> folder from your
-   project and rebuild.
-
-.. rubric:: uia_1_03_00_02 : JTAG Transport does not work properly on
-   some devices.
-   :name: uia_1_03_00_02-jtag-transport-does-not-work-properly-on-some-devices.
-
--  Project builds cleanly, System Analyzer starts normally, but no
-   events are captured.
--  To overcome this, please use
-   `uia_1_03_01_08 <http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/uia/1_03_01_08/index_FDS.html>`__
-   or later.
-
-.. rubric:: FAQs
-   :name: faqs
-
-.. rubric:: Q: When can I use System Analyzer auto configuration
-   :name: q-when-can-i-use-system-analyzer-auto-configuration
-
-When launching a Live or Binary File session users can choose to let
-System Analyzer auto configure itself. For this to work you must:
-
--  have a debug session running with the symbol/program file loaded
--  generated rta and uia xml file (*program*.rta.xml and
-   *program*.uia.xml) files should be located where the project
-   generated them or in the same folder as the .out file
--  if using Ethernet transport it is expected that IP address is output
-   in the console
-
-.. rubric:: Q: Configuring System Analyzer when auto configuration is
-   not possible
-   :name: q-configuring-system-analyzer-when-auto-configuration-is-not-possible
-
-See **Configuring System Analyzer Transport and Endpoints** in Chapter 4
-of the `System Analyzer User's
-Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: Q: Can I launch System Analyzer before the target if running
-   :name: q-can-i-launch-system-analyzer-before-the-target-if-running
-
-If using Ethernet transport, System Analyzer expects that the target is
-up and running and the Ethernet connection is established before it is
-started. For JTAG transport the target does not have to be running.
-
-.. rubric:: Q: What happens if the target is halted while collecting
-   data using Ethernet transport
-   :name: q-what-happens-if-the-target-is-halted-while-collecting-data-using-ethernet-transport
-
-Halting the target may result in the ethenet connection getting
-disconnected. The connection can be re-established using the **connect**
-button.
-
-.. rubric:: Q: How to Profile functions using enter and exit hook
-   functions
-   :name: q-how-to-profile-functions-using-enter-and-exit-hook-functions
-
-In order to do inclusive and exclusive profiling of functions(using
-Context Aware Profiler of System Analyzer), a UIA log is needed at the
-entry and exit point of functions. One can add entry and exit hook
-functions to every function in the source by doing the following
-
-Use the following compiler options when compiling the source
-
-::
-
-    --entry_hook=functionEntryHook
-    --entry_parm=address
-    --exit_hook=functionExitHook
-    --exit_parm=address
-
-To use the required UIA events, need this include
-
-.. code-block:: c
-
-    #include <ti/uia/events/UIABenchmark.h>
-
-|
-| Add entry and exit hook functions to the source (The below one is for
-  Context aware function profiling)
-
-.. code-block:: c
-
-    void functionEntryHook( void (*addr)() ){
-        Log_write3(UIABenchmark_startInstanceWithAdrs, (IArg)"context=0x%x, fnAdrs=0x%x:",(IArg)0, (IArg)addr);
-    }
-
-    void functionExitHook( void (*addr)() ){
-        Log_write3(UIABenchmark_stopInstanceWithAdrs,  (IArg)"context=0x%x, fnAdrs=0x%x:",(IArg)0, (IArg)addr);
-    }
-
-For CCS 5.5 and later
-
-.. code-block:: c
-
-    void functionEntryHook( void (*addr)() ){
-        Log_write2(UIAProfile_enterFunctionAdrs, (IArg)0, (IArg)addr);
-    }
-
-    void functionExitHook( void (*addr)() ){
-        Log_write2(UIAProfile_exitFunctionAdrs,  (IArg)0, (IArg)addr);
-    }
-
-|
-| The 1st parameter after the message string( 3rd parameter to
-  Log_write3) is a context parameter (For CCS 5.5 and later is the 2nd
-  parameter to Log_write2) and can be used to specify an additional
-  level of qualification (e.g. Task Context). For our purpose out here
-  we can ignore this and just set it to 0.
-
-If task aware profiling is needed, the Task context has to be logged.
-SYS/BIOS automatically logs events for task switches and SWI and HWI
-Start and Stop events. See Enabling and Disabling logging Sec 5.2.2 in
-the `System Analyzer User's
-Guide <http://www.ti.com/lit/pdf/spruh43>`__. Context change can also be
-explicitly logged by the application. For more on Profiling using system
-analyzer refer to Section 3.5,4.12 of the user's guide.
-
-**Profiling Results when using Libraries:** Hook functions will not be
-added and hence called from functions in libraries that have been linked
-in. This will cause the Exclusive counts of the functions making calls
-to the Library, to include the Library functions duration.
-
-.. rubric:: Trouble Shooting
-   :name: trouble-shooting
-
-.. rubric:: System Analyzer Events or Packets are being dropped
-   :name: system-analyzer-events-or-packets-are-being-dropped
-
-See **Troubleshooting System Analyzer Connections** section in the
-`System Analyzer User's Guide <http://www.ti.com/lit/pdf/spruh43>`__.
-
-.. rubric:: No Events showing up in System Analyzer Views
-   :name: no-events-showing-up-in-system-analyzer-views
-
-See **Troubleshooting System Analyzer Connections** section in the
-System Analyzer User's Guide.
-
-.. rubric:: System Analyzer cannot connect to the target to retrieve
-   logs
-   :name: system-analyzer-cannot-connect-to-the-target-to-retrieve-logs
-
-See **Troubleshooting System Analyzer Connections** section in the
-System Analyzer User's Guide.
-
-.. rubric:: System Analyzer Events do not make sense
-   :name: system-analyzer-events-do-not-make-sense
-
-See **Troubleshooting System Analyzer Connections** section in the
-System Analyzer User's Guide.
-
-.. rubric:: Time values in the logs are too large
-   :name: time-values-in-the-logs-are-too-large
-
-See **Troubleshooting System Analyzer Connections** section in the
-System Analyzer User's Guide.
-
-.. rubric:: Technical Support and Product Updates
-   :name: technical-support-and-product-updates
-
-For technical discussions and issues, please visit
-
--  `E2E Processor Support:
-   https://e2e.ti.com/support/processors/ <https://e2e.ti.com/support/processors/>`__
--  `BIOS Embedded Software forum:
-   http://e2e.ti.com/support/embedded/f/355.aspx <http://e2e.ti.com/support/embedded/f/355.aspx>`__
--  `Embedded Processors wiki:
-   http://processors.wiki.ti.com <http://processors.wiki.ti.com>`__
-
-Note: When asking for help in the forum you should tag your posts in the
-Subject with "System Analyzer", the part number (e.g. "C6678"), and
-component (e.g. "UIA").
-
-|
-| For product updates,
-
--  Use the CCS/Eclipse Update Manager (see the Getting Started Guide
-   above)
-
diff --git a/source/rtos/Tools/Code_Composer_Studio/_XDS100_Emulator_Info.rst b/source/rtos/Tools/Code_Composer_Studio/_XDS100_Emulator_Info.rst
deleted file mode 100644
index 16e8ba5c6..000000000
--- a/source/rtos/Tools/Code_Composer_Studio/_XDS100_Emulator_Info.rst
+++ /dev/null
@@ -1,1574 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/XDS100
-
-.. rubric:: What is the XDS100
-   :name: what-is-the-xds100
-
--  The XDS100 emulator is Texas Instruments' ultra-low-cost
-   USB-interface JTAG hardware reference design.
--  The XDS100 emulator provides JTAG access to Texas Instruments' JTAG
-   based devices.
--  It is compatible with `Code Composer
-   Studio <http://processors.wiki.ti.com/index.php/Code_Composer_Studio>`__\ ™ development
-   environment.
--  TI creates the reference design and our 3rd party partners create the
-   JTAG emulator products for end use.
--  The XDS100s are available as discrete emulators, or can be embedded
-   on a development card (DSK, EVM, etc.).
--  There are 3 versions of the XDS100. The XDS100v1 is the original
-   XDS100 design. The XDS100v2 is an updated XDS100 design with more
-   capability. The XDS100v3 is an updated XDS100v2 design with support
-   for the 1149.7 protocol.
--  Performance of the XDS100 is lower than the
-   `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ and `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__.
-   This means that program and data downloads will take a longer time
-   than with `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ and
-   `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__ emulators. Also, stepping in "C" and
-   "Assembly" will be slower with XDS100 when compared to
-   `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ or `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__
-   emulators.
-
-.. rubric:: General Features
-   :name: general-features
-
-The Texas Instruments' reference design for XDS100 has the following
-features (Please check your vendor for hardware details):
-
--  Debug features (`Emulation
-   Connect/Disconnect <http://processors.wiki.ti.com/index.php/Emulation_Connect/Disconnect>`__,
-   Read/Write memory, Read registers, Load program, Run, Halt, Step,
-   Software and Hardware `Breakpoint <http://processors.wiki.ti.com/index.php/Breakpoint>`__ support,
-   `Real-Time Mode <http://processors.wiki.ti.com/index.php/Real-Time_Mode>`__)
--  Compatible with Code Composer Studio™.
--  Support for targets with 1.8v and 3.3v IO voltages.
--  Support for “JTAG reset”/"wait-in-reset" boot-modes using the two EMU
-   pins sampled by the nTRST pin.
--  Support for “Power-on reset” boot-modes using the two EMU pins
-   sampled by the TVD pin.
--  Support for the configuration of the EMU pin features through `Code
-   Composer Studio <http://processors.wiki.ti.com/index.php/Code_Composer_Studio>`__\ ™ Setup
-   “connection properties” dialogs similar to those for the
-   `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__ Rev-D cable.
--  Support for “target power-loss detection” via the TVD pin even when
-   `Code Composer Studio <http://processors.wiki.ti.com/index.php/Code_Composer_Studio>`__\ ™ is not
-   running, and applying boot-modes at `Code Composer
-   Studio <http://processors.wiki.ti.com/index.php/Code_Composer_Studio>`__\ ™ start-up.
--  Supports ETB trace
-
-.. rubric:: Which XDS100 is right for me?
-   :name: which-xds100-is-right-for-me
-
--  XDS100v1 emulators are only recommended for users who need to use
-   Code Composer Studio v3.3, anyone using Code Composer Studio v4 or
-   later should consider an XDS100v2 or later emulator due to the
-   increased performance.  Some of our 3rd Party partners have
-   implemented XDS100v2 emulators that can also operate in v1 mode for
-   compatibility with Code Composer Studio v3.3.
--  XDS100v3 emulators are recommended for users who require support for
-   IEEE 1149.7, most devices do not require this.
--  XDS100v2 is the default recommended XDS100 emulator.
-
-.. rubric:: XDS100v1 Features
-   :name: xds100v1-features
-
-The Texas Instruments' reference design for XDS100v1 has the following
-features. Please check with your vendor as to whether the all of the
-below features are supported:
-
--  All of the XDS100 General Features
--  Support for USB Full Speed (12 Mbits/s)
--  Support for multiple FTDI devices (CCSv4 only)
--  Support targets with `14-pin TI JTAG
-   connector <http://processors.wiki.ti.com/index.php/JTAG_Connectors>`__ used by Texas Instruments
-   embedded processors.
--  Support for the following processors cores: TMS320C28x, TMS320C54x,
-   TMS320C55x, TMS320C64x+, TMS320C674x and TMS320C66x.
-
-.. rubric:: XDS100v2 Features
-   :name: xds100v2-features
-
-The Texas Instruments' reference design for XDS100v2 has the following
-features. Please check with your vendor as to whether the all of the
-below features are supported:
-
--  All of the XDS100 General Features
--  Support for USB High Speed (480 Mbit/s)
--  Support targets with `14-pin TI JTAG
-   connector <http://processors.wiki.ti.com/index.php/JTAG_Connectors>`__ or `20-pin TI JTAG
-   connector <http://processors.wiki.ti.com/index.php/JTAG_Connectors>`__ as used by Texas
-   Instruments embedded processors. (Please check your vendor for
-   hardware details)
--  Support for the following processor cores: TMS320C28x, TMS320C54x,
-   TMS320C55x, TMS320C64x+, TMS320C674x, TMS320C66x, ARM 9, ARM Cortex
-   cores: A (A8, A9 and A15), M (M0, M3 and M4) and R (R4 and R5).
-   Support for the cores was incrementally added across the releases -
-   check the release notes for the version you are using.
--  Supports cable-break detection
--  Supports target power loss detection
--  Support for multiple FTDI devices
--  Adaptive clocking
--  LED light to indicate active USB connection
--  Support for Code Composer Studio v4 and newer (Does not support Code
-   Composer Studio v3.3)
--  Note: As of 4/28/2010, the CPLD update was issued. Please see
-   `XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F>`__
-
-.. rubric:: XDS100v3 Features
-   :name: xds100v3-features
-
-The Texas Instruments' reference design for XDS100v3 has the following
-features. Please check with your vendor as to whether the all of the
-below features are supported:
-
--  All of the XDS100 General Features
--  IEEE 1149.7 capable emulator with a USB interface.
--  Can function as an 1149.7 adapter for use with existing scan
-   controllers.
--  Software compatible with XDS100v2 (except link delay and IEEE 1149.7
-   modes).
--  Physical jumper to select emulator or adapter mode.
--  Operates in 1149.7 Class 4, up to 25MHz.
--  LED to indicate IEEE 1149.7 Class 4 operation.
--  LED to indicate operation in adapter mode.
-
-.. rubric:: Features NOT supported 
-   :name: features-not-supported
-
--  It does not support `Real Time Data eXchange
-   (RTDX) <http://processors.wiki.ti.com/index.php/Real_Time_Data_eXchange_(RTDX)>`__ or `High Speed
-   RTDX (HSRTDX) <http://processors.wiki.ti.com/index.php/High_Speed_RTDX_(HSRTDX)>`__
--  It does not provide hardware support for TCLKR external clocking
--  Cores NOT supported: ARM 7, ARM 11, TMS320C24x, TMS320C55x+,
-   TMS320C670x, TMS320C671x, TMS320C672x, TMS320C64x (note that
-   TMS320C64x+ is supported) and other cores not listed as supported.
--  It cannot read the value of the EMU0/1 pins, so long profiling
-   operations that use the EMU0/1 pins to handle counter overflows will
-   not be possible.
--  JTAG Clock (TCLK) frequency other than default JTAG frequency (1Mhz)
-
-.. rubric:: XDS100 Installation Instructions
-   :name: xds100-installation-instructions
-
-.. rubric:: Installation for Code Composer Studio v6
-   :name: installation-for-code-composer-studio-v6
-
-All drivers are installed when XDS100 is selected during installation.
-
-.. rubric:: Installation for Code Composer Studio v5
-   :name: installation-for-code-composer-studio-v5
-
-For CCSv5.5 all drivers are installed when XDS100 is selected during
-installation. For CCSv5.1, 5.2, 5.3 and 5.4 make sure to check for
-updates in CCS and install the latest TI Emulation update if support for
-XDS100v3 is needed.
-
-|
-
-+-----------------------------------------------------------------------+
-| .. raw:: html                                                         |
-|                                                                       |
-|    <div style="text-align: center">                                   |
-|                                                                       |
-| **Code Composer Studio v5.1.x Support** (XDS100v1, XDS100v2 and       |
-| XDS100v3 hardware)                                                    |
-|                                                                       |
-| .. raw:: html                                                         |
-|                                                                       |
-|    </div>                                                             |
-+-----------------------------------------------------------------------+
-
-+-----------------+-----------------+-----------------+-----------------+
-| ***Processor    | **XDS100        | ***Code         | ***Notes***     |
-| Family***       | Hardware        | Composer Studio |                 |
-|                 | Version**       | Release/Version |                 |
-|                 |                 | ***             |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C28xx     | v1, v2, v3      | `Code Composer  | Additional SW   |
-|                 |                 | Studio v5       | patch required  |
-|                 |                 | page <http://pr | for XDS100v3    |
-|                 |                 | ocessors.wiki.t | support         |
-|                 |                 | i.com/index.php |                 |
-|                 |                 | /Category:Code_ |                 |
-|                 |                 | Composer_Studio |                 |
-|                 |                 | _v5>`__ and     |                 |
-|                 |                 | newer           |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C54xx     | v1, v2, v3      | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C55xx     | v1, v2, v3      | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C674x     | v1, v2, v3      | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C64x+     | v1, v2, v3      | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C66x      | v1, v2, v3      | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM9            | v2, v3          | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex A9   | v2, v3          | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex A8   | v2, v3          | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex      | v2, v3          | - as above -    | - as above -    |
-| M3/M4           |                 |                 |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex R4   | v2, v3          | - as above -    | - as above -    |
-+-----------------+-----------------+-----------------+-----------------+
-
-|
-
-A. Install Code Composer Studio 5.1.x (XDS100v1 and XDS100v2 support is
-included) as per the table above **before ** connecting XDS100 USB
-hardware.
-
-B. Install the EmuPack with XDS100v3 support.
-
-C. Connect the XDS100 hardware
-
-#. Make sure the Code Composer Studio 5.1.x and EmuPack with XDS100v3
-   support is installed FIRST **before** plugging in the XDS100 HW to
-   the PC.
-#. Connect USB cable from the PC to the XDS100 hardware. Connect the
-   JTAG to the target board (be careful to plug it in correctly: pin 1
-   should go to pin 1. Red strip usually indicates the side of pin 1)
-#. You will notice small popups to inform user that USB hardware is
-   recognized and installed correctly. No input are required.
-
-D. Setup Code Composer Studio v5.1.x
-
-#. Start Code Composer Studio and create a new target configuration. See
-   `Quick
-   Tips#Target_Setup.C2.A0 <http://processors.wiki.ti.com/index.php/Quick_Tips#Target_Setup.C2.A0>`__
-#. Select XDS100 as connection type (either XDS100 v1, XDS100 v2 or
-   XDS100v3)
-#. Select device.
-
-|
-
-.. rubric:: Installation for Code Composer Studio v4.x
-   :name: installation-for-code-composer-studio-v4.x
-
-|
-
-+-----------------------------------------------------------------------+
-| .. raw:: html                                                         |
-|                                                                       |
-|    <div style="text-align: center">                                   |
-|                                                                       |
-| **Code Composer Studio v4.x Support** (XDS100v1 and XDS100v2          |
-| hardware)                                                             |
-|                                                                       |
-| .. raw:: html                                                         |
-|                                                                       |
-|    </div>                                                             |
-+-----------------------------------------------------------------------+
-
-+-----------------+-----------------+-----------------+-----------------+
-| ***Processor    | **XDS100        | ***Code         | ***Notes***     |
-| Family***       | Hardware        | Composer Studio |                 |
-|                 | Version**       | Release/Version |                 |
-|                 |                 | ***             |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C28xx     | v1,             | `Code Composer  | No additional   |
-|                 | v2              | Studio          | SW required for |
-|                 |                 | v4.1 </index.ph | XDS100 support  |
-|                 |                 | p/Download_CCS> |                 |
-|                 |                 | `__ and         |                 |
-|                 |                 | newer           |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C54xx     | v1, v2          | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C55xx     | v1, v2          | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C674x     | v1, v2          | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C64x+     | v1, v2          | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C66x      | v1, v2          | - Code Composer |                 |
-|                 |                 | Studio 4.2.2    |                 |
-|                 |                 | and newer -     |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM9            | v2              | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex A9   | v2              | Code Composer   |                 |
-|                 |                 | Studio v4.2 and |                 |
-|                 |                 | newer           |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex A8   | v2              | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex M3   | v2              | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| ARM Cortex R4   | v2              | - as above -    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-
-|
-
-A. Install Code Composer Studio 4.x (XDS100 SW support is included) as
-per the table above **before ** connecting XDS100 USB hardware.
-
-B. Connect the XDS100 hardware
-
-#. Make sure the Code Composer Studio 4.x is installed FIRST **before**
-   plugging in the XDS100 HW to the PC.
-#. Connect USB cable from the PC to the XDS100 hardware. Connect the
-   JTAG to the target board (be careful to plug it in correctly: pin 1
-   should go to pin 1. Red strip usually indicates the side of pin 1)
-#. You will notice small popups to inform user that USB hardware is
-   recognized and installed correctly. No input are required.
-
-C. Setup Code Composer Studio v4.x
-
-#. Start Code Composer Studio and create a new target configuration. See
-   `Quick
-   Tips#Target_Setup.C2.A0 <http://processors.wiki.ti.com/index.php/Quick_Tips#Target_Setup.C2.A0>`__
-#. Select XDS100 as connection type (either XDS100 v1 or XDS100 v2)
-#. Select device.
-
-.. rubric:: Installation for Code Composer Studio v3.3 (XDS100v1
-   Hardware Only)
-   :name: installation-for-code-composer-studio-v3.3-xds100v1-hardware-only
-
-|
-
-+-----------------------------------------------------------------------+
-| .. raw:: html                                                         |
-|                                                                       |
-|    <div style="text-align: center">                                   |
-|                                                                       |
-| **Code Composer Studio v3.3 Support** (XDS100v1 HW only)              |
-|                                                                       |
-| .. raw:: html                                                         |
-|                                                                       |
-|    </div>                                                             |
-+-----------------------------------------------------------------------+
-
-+-----------------+-----------------+-----------------+-----------------+
-| ***Processor    | **XDS100        | ***Code         | ***Notes***     |
-| Family***       | Hardware        | Composer Studio |                 |
-|                 | Version**       | Release/Version |                 |
-|                 |                 | ***             |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C28xx     | v1              | CCS v3.3        | Included with   |
-|                 |                 | Platinum        | `CCS Service    |
-|                 |                 | Edition (TI     | Release12`_     |
-|                 |                 | part #:         | and newer.      |
-|                 |                 | TMDSCCSALL-1)   |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C28xx     | v1              | `CCS v3.3 for   | XDS100 SW       |
-|                 |                 | C2000 Full      | required.       |
-|                 |                 | Version         | Download        |
-|                 |                 | (version        | `here <http://s |
-|                 |                 | #3.3.78.2) (TI  | oftware-dl.ti.c |
-|                 |                 | part #:         | om/dsps/dsps_re |
-|                 |                 | TMDSCCS2000-1)  | gistered_sw/sdo |
-|                 |                 | <http://www.ti- | _ccstudio/CCSv3 |
-|                 |                 | estore.com/Merc | /Drivers/XDS100 |
-|                 |                 | hant2/merchant. | _v1_1_RTM.exe>` |
-|                 |                 | mvc?Screen=PROD | __.             |
-|                 |                 | &Product_Code=T |                 |
-|                 |                 | MDSCCS2000-1>`_ |                 |
-|                 |                 | _               |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C28xx     | v1              | CCS v3.3 for    | XDS100 SW       |
-|                 |                 | C2000 DSK       | included in CCS |
-|                 |                 | Version         | Installation.   |
-|                 |                 | (version        | No additional   |
-|                 |                 | #3.3.81.28, 3.3 | SW required.    |
-|                 |                 | .83.16 or       |                 |
-|                 |                 | newer)          |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| TMS320C674x     | v1              | CCS v3.3        | Included with   |
-|                 |                 | Platinum        | CCS Service     |
-|                 |                 | Edition (TI     | Release 12 and  |
-|                 |                 | part #:         | newer.          |
-|                 |                 | TMDSCCSALL-1)   |                 |
-+-----------------+-----------------+-----------------+-----------------+
-
-.. _CCS Service Release12: <http://processors.wiki.ti.com/index.php/CCStudio_FAQ#Q:_How_can_I_find_out_which_CCStudio_3.3_Service_Release_number_is_installed3F>
-
-| **Note**: Code Composer Studio v3.3 ONLY supports XDS100v1 hardware
-  emulator. XDS100v2 hardware is NOT supported on Code Composer Studio
-  v3.3.
-
-| **Note**: Blackhawk has a model D version of XDS100v2 which can be
-  configured to work as a v1 or v2 product. They provide a utility to
-  re-program the device to act as a xds100v1, so the same product can be
-  used with both CCS3.3 and CCS4. The firmware update utilities can be
-  found on their `Blackhawk XDS100 Support
-  Page. <http://www.blackhawk-dsp.com/support/xds100>`__
-| A. Install Code Composer Studio and XDS100 Software before connecting
-  XDS100 USB hardware.
-
-#. Install the Code Composer Studio version, service release and/or
-   XDS100 SW as detailed in the table below prior to connecting the
-   XDS100 SW.
-
-B. Connect the XDS100 hardware
-
-#. Make sure the XDS100 Software is installed FIRST per the table above
-   **before** plugging in the XDS100 HW to the PC.
-#. Connect USB cable from the PC to the XDS100 hardware. Connect the
-   JTAG to the target board (be careful to plug it in correctly: pin 1
-   should go to pin 1. Red strip usually indicates the side of pin 1)
-#. You will notice small popups to inform user that USB hardware is
-   recognized and installed correctly. No input are required.
-
-C. Setup Code Composer Studio v3.3
-
-#. Select CC Setup icon from the desktop.
-#. From the filters panel, select the platform "xds100usb emulator".
-   This will give you a list of predefined configurations. Select the
-   one appropriate for your device
-#. Save your configuration and exit CC Setup
-#. Start Code Composer Studio
-#. In Code Composer Studio, go Debug-->Connect. Note: "connect to
-   target" may take long time (>5 seconds) for the first time XDS100 USB
-   is connected to target. It is not the case with subsequent "connect"
-   operations.
-
-.. rubric:: What are the known issues?
-   :name: what-are-the-known-issues
-
--  XDS100 debuggers suffer a **severe performance impact** when using
-   Virtual Machines (VMware, Virtualbox, Parallels, etc.) and Linux as a
-   guest OS. Additional details are shown `at this
-   page <http://processors.wiki.ti.com/index.php/VMware_with_CCS#Linux_as_a_guest_OS>`__.
--  While loading a large program or program section, the file load
-   status bar may appear frozen when it is not frozen. The status bar is
-   showing section load start and completion.
--  When a second FTDI device is plugged in (ex: FT232RL), and it
-   receives a lower chain number, the XDS100 SW will address it instead
-   of the FT2232 used by the XDS100. Solution: only plug the XDS100 HW
-   into the PC. This has been fixed with `Code Composer Studio
-   v4 <http://processors.wiki.ti.com/index.php/Code_Composer_Studio_v4>`__ support for the XDS100v2
-   **ONLY** (XDS100v1 still has this issue).
--  XDS100 SW Driver does not install properly under Windows Vista 64 bit
-   using CCSv3.3
--  If "Option" under CCSv3.3 “connect to target at CCS startup” is
-   enabled and c674x target board is connected, then the following error
-   is reported when you try to "Disconnect" for the 1st time. It works
-   fine on 2nd attempt to disconnect. Note, this has been fixed for CCS
-   v4.
-
-::
-
-    Error:
-    Error 0xA0002020/-150
-    Error during: Execution, Control,
-    This error was generated by TI's USCIF driver.
-
-    SC_ERR_POD_FAIL <-150>
-    This utility failed to operate the adapter for a custom emulator.
-    The adapter returned an error for unknown reasons.
-
--  When selecting OMAPL137 configuration in CCS 4.0.2, the GEL files
-   cause the connection to be hung. Remove the GEL file from the target
-   configuration. This has been fixed in CCSv5.2 and newer.
--  ETB for OMAPL137/8 is not working. Error of "ETB definitions cannot
-   be loaded. Device not supported." is reported. ETB11 for OMAPL137/138
-   is not supported at this time. This has been fixed in CCSv5 and
-   newer.
--  When installating XDS100v2 patch via update manager, CCS says that
-   the feature is not digitally signed. Continue installation. This has
-   been fixed in CCSv5 releases.
--  Target power loss detection is not working in CCS v4.1/v4.1.x. This
-   has been fixed in CCS v4.2.
--  Adaptive clocking use with OMAPL138/ARM9 cores connection reliability
-   varies by card. This results in connection errors. A fix has been
-   identified by upgrading the CPLD on XDS100v2 designs. Please see
-   `XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F>`__
-
-|
-
-|
-
-|
-
-|
-
-.. rubric:: Troubleshooting
-   :name: troubleshooting
-
--  Check whether the installation process was followed.
--  Please check the FAQ questions below. (`Troubleshooting
-   FAQ <http://processors.wiki.ti.com/index.php/XDS100#Troubleshooting_FAQ>`__)
--  **Please check the section regarding `Troubleshooting
-   CCS <http://processors.wiki.ti.com/index.php/Troubleshooting_CCS>`__.**
--  Check your Windows System Devices. When properly installed, the
-   XDS100 should look like the below image. If the XDS100 does not show
-   up in the Windows device manager or shows with an error, then it is
-   likely that the XDS100 was not programmed properly (contact
-   manufacturer), there is a conflict with another FTDI based USB device
-   (see FAQ below for details) or the drivers became corrupt (check the
-   reinstall section above the screenshots)
-
-   -  You can run the utility <xds100serial.exe> to find out which
-      VID/PID are programmed in the device. This utility is typically
-      located at the directory
-      ``CCS_INSTALL_DIR/ccsv6/ccs_base/common/uscif``
-
--  Check USB cable or change the USB port the emulator is connected
--  Power cycle your target
--  You may want to check the `VID/PID EEPROM was programed
-   correctly <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F>`__
--  Sometimes the use of different drivers such as libFTDI (used by
-   OpenOCD, for example) or a simple corruption on other Windows .inf
-   files may cause an improper initialization of the XDS100 device
-   drivers. Please check `this forum
-   thread <https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/522774/1904904>`__
-   for details.
-
-|
-
-.. raw:: html
-
-   <div class="toccolours mw-collapsible mw-collapsed"
-   style="width:1200px">
-
-To reinstall the Windows device drivers:
-
-.. raw:: html
-
-   <div class="mw-collapsible-content">
-
--  Right-click on node *XDS100 Channel A*
--  Select *Update Driver Software* → *Browse my computer for driver
-   software*
--  Select *Let me pick from a list of device drivers on my computer*. If
-   the drivers are already installed, the XDS100 Class Debug Port
-   drivers will show. Select this one. Otherwise, repeat but skip this
-   step.
--  Click on Browse and select the directory
-   C:\ti\ccsv7\ccs_base\emulation\windows\xds100_drivers
--  Repeat for *XDS100 Channel B*
-
-That should get you the same driver as installed by CCS.
-
-If Windows refuses to update the driver, they need to be fully removed.
-
--  Right-click on node *XDS100 Channel A*
--  Select *Uninstall...*
--  Check the box *Delete the driver software for this device* and click
-   **OK**
--  Repeat for *XDS100 Channel B*
--  Do the procedure above to reinstall the drivers
-
-.. Image:: /images/Xds100onWin10-sysdevices.png
-
-.. rubric:: Roadmap
-   :name: roadmap
-
--  SW Update for improved performance.
--  Lower cost design.
-
-.. rubric:: Where to get an XDS100 / Where to buy an XDS100
-   :name: where-to-get-an-xds100-where-to-buy-an-xds100
-
-.. rubric:: XDS100v3
-   :name: xds100v3
-
--  Spectrum Digital, Inc., offers an XDS100v3 USB CJTAG/JTAG Emulator
-   `here <http://www.spectrumdigital.com/product_info.php?&products_id=251>`__
--  Olimex LTD, manufactures and sells a low-cost XDS100v3
-   `here <https://www.olimex.com/Products/DSP/Emulators/TMS320-XDS100-V3/>`__
--  00ic.com offers an XDS100v3 in china mainland with black plastic
-   shell `here <https://world.tmall.com/item/521413174572.htm>`__
--  Embest offers one
-   `here <http://www.embest-tech.com/prod_view.aspx?TypeId=107&Id=365&FId=t3:107:3>`__
-
-.. rubric:: XDS100v2
-   :name: xds100v2
-
--  Ashling's Opella-XDS100v2 is now available. Check it out
-   `here <http://ashling.com/index.php?option=com_content&task=view&id=332>`__
-   and buy
-   `here <http://ashling.com/index.php?option=com_content&task=view&id=129&Itemid=375>`__
--  Blackhawk has one
-   `available <http://www.blackhawk-dsp.com/products/USB100.aspx>`__
-   (and our latest model supports both CCS v3.3 and v4., so no more
-   deciding which model to buy)
--  Olimex manufactures and sells an XDS100v2 debugger
-   `here <https://www.olimex.com/Products/DSP/Emulators/TMS320-XDS100-V2/>`__
--  Embest has one
-   `here <http://www.timll.com/chinese/product/XDS100.asp>`__
--  Spectrum Digital, Inc., offers an XDS100v2 USB JTAG Emulator
-   `here <http://www.spectrumdigital.com/product_info.php?cPath=22&products_id=230>`__
--  TI Estore has a lifetime buy of the `20 pin compact
-   TI <http://processors.wiki.ti.com/index.php/JTAG_Connectors#TI_20-pin_Header_Information>`__
-   version `available <http://www.ti.com/tool/TMDSEMU100V2U-20T>`__.
-
-.. rubric:: XDS100v1
-   :name: xds100v1
-
--  Blackhawk offers a USB 2.0 HIGH-SPEED XDS100-class JTAG Emulator with
-   dual headers (14 and 20cTI)
-   `here <http://www.blackhawk-dsp.com/products/usb100.aspx>`__
--  Olimex offers an XDS100 emulator
-   `here <http://www.olimex.com/dev/tms320-jtag-usb.html>`__.
--  Realtime offers an XDS100 emulator
-   `here <http://www.realtimedsp.com.cn/product/detail.asp?ID=271>`__.
--  SeedDSP offers an XDS100 emulator
-   `here <http://www.seeddsp.com/news/details.php?id=564>`__ and
-   `here <http://www.seeddsp.com/pop/28027/28027.html>`__.
--  C28x has the XDS100 is integrated onto the c28x Piccolo controlstick
-   `here <http://focus.ti.com/docs/toolsw/folders/print/tmdx28027usb.html>`__
-   and
-   `here <http://focus.ti.com/docs/toolsw/folders/print/tmdxdock28027.html>`__.
--  5505 has the XDS100 integegrated onto the 5505 eZDSP USB
-   stick\ `here <http://focus.ti.com/docs/toolsw/folders/print/tmdx5505ezdsp.html?DCMP=DSP_c5505usbstick&HQS=Other+OT+c5505ezdsp-prprod>`__
--  `ZLG (China) <http://www.embedtools.com/pro_kaifa/dsp/XDS100.asp>`__
--  `Bilkon <http://bilkon-kontrol.com.tr/index.php?/eng/Products/Embedded-Systems/XDS100>`__
--  `Pantech Solution Pvt
-   Ltd. <http://www.pantechsolutions.net/UltraLowcostEmulator.html>`__
--  `Lierda has one
-   (China) <http://www.lierda.com/product_show/id/75/display.html>`__
-
-.. rubric:: How to make an XDS100 / How to build an XDS100 hardware
-   emulator
-   :name: how-to-make-an-xds100-how-to-build-an-xds100-hardware-emulator
-
--  You can make your own XDS100 by using the schematic and programming
-   instructions below.
-
-.. rubric:: XDS100v3 (only recommended for cJTAG based devices)
-   :name: xds100v3-only-recommended-for-cjtag-based-devices
-
-.. rubric:: Q: Where can I get the design / schematic / BOM for the
-   XDS100v3?
-   :name: q-where-can-i-get-the-design-schematic-bom-for-the-xds100v3
-
--  A: It is available from
-   `here <http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_ccstudio/XDS/xds100v3_v2.0.zip>`__
-   (registration required).
--  The design files (schematic, gerbers, etc.) are provided. Scrambled
-   FPGA VHDL is also included.
--  Please read the included readme for details.
-
-.. rubric:: Q: What should the USB device's UID (VID/PID) be?
-   :name: q-what-should-the-usb-devices-uid-vidpid-be
-
--  A: The EEPROM needs to be programmed for a VID=0403 PID=A6D1. The
-   device name string should be, “Texas Instruments Inc.XDS100 Ver 3.0”.
--  A: FTDI has a utility called MProg. See
-   `here <http://www.ftdichip.com/Resources/Utilities.htm#MProg>`__. To
-   program the FTDI chip you will need a MPROG template file that can be
-   downloaded from `this link </images/b/bd/XDS100v3.zip>`__.
-
-.. rubric:: Q: I want to put an XDS100v3 on my EVM / DSK / card. Can I
-   do this?
-   :name: q-i-want-to-put-an-xds100v3-on-my-evm-dsk-card.-can-i-do-this
-
--  A: Yes, but please make sure to re-use the entire XDS100 design as-is
-   to ensure compatibility with the existing software!
-
-.. rubric:: XDS100v2 (Recommended)
-   :name: xds100v2-recommended
-
-.. rubric:: Q: Where can I get the design / schematic / BOM for the
-   XDS100v2?
-   :name: q-where-can-i-get-the-design-schematic-bom-for-the-xds100v2
-
--  A: It is available from
-   `here <http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_ccstudio/XDS/XDS100v2Schematic(rev2)-Setup.zip>`__
-   (registration required).
--  The design files (schematic, gerbers, etc.) are drawn in the program
-   KiCAD. PDF schematic is included. Bill of Materials (BOM) is
-   included. MPROG script file is included. CPLD VHD and JED sources are
-   included.
--  Please read the included readme for details.
--  Note as of 4/28/2010, the design package was updated with new CPLD
-   source code. This is to fix the issues related to `Adaptive
-   Clocking <http://processors.wiki.ti.com/index.php/Adaptive_Clocking>`__ on ARM9.
-
-.. rubric:: Q: What should the USB device's UID (VID/PID) be?
-   :name: q-what-should-the-usb-devices-uid-vidpid-be-1
-
--  A: The EEPROM needs to be programmed for a VID=0403 PID=A6D0. The
-   device name string should be, “Texas Instruments Inc.XDS100 Ver 2.0”.
--  A: FTDI has a utility called MProg. See
-   `here <http://www.ftdichip.com/Resources/Utilities.htm#MProg>`__. To
-   program the FTDI chip you will need a MPROG template file that can be
-   downloaded from `this link </images/d/d9/XDS100v2.zip>`__.
-
-.. rubric:: Q: XDS100-based C5505 and C5515 EzDSP USB Stick does connect
-   when using "Target Connect"
-   :name: q-xds100-based-c5505-and-c5515-ezdsp-usb-stick-does-connect-when-using-target-connect
-
-I get: "Error connecting to the target: Error 0x80000240/-600 Fatal
-Error during: Initialization, OCS"
-
--  A: This can happen if the FDTI USB driver have not been properly
-   uninstalled / re-installed (i.e. if CCSv4 uninstall did not complete
-   properly). I resolved it by going to Device Manager then right click
-   on:
-
-TI XDS100 Channel B -> Uninstall then TI XDS100 Channel A -> Uninstall
-Then it re-installed itself when re-connecting the XDS100-based USB
-stick and "Target Connect" worked afetr re-starting CCSv4
-
-.. rubric:: Q: I want to put an XDS100v2 on my EVM / DSK / card. Can I
-   do this?
-   :name: q-i-want-to-put-an-xds100v2-on-my-evm-dsk-card.-can-i-do-this
-
--  A: Yes, but please make sure to re-use the entire XDS100 design as-is
-   to ensure compatibility with the software! Removing the CPLD
-   implementing with discrete logic will result in a design that is just
-   as complex and expensive as using the CPLD.
-
-.. rubric:: Q: Can I use port B as a UART?
-   :name: q-can-i-use-port-b-as-a-uart
-
--  A: Yes. The TI XDS100v2 reference design uses the port A of the
-   FTDI2232H to be for JTAG. This leaves the port B available for use
-   either to program the CPLD and/or for use as a UART. The XDS100v2
-   design puts the CPLD JTAG programming on a selected number of pins
-   (see XDS100v2 readme for details). This allows the CPLD to be
-   programmed via the FTDI device, greatly simplifying manufacturing.
--  Please note that there is a known issue with the current XDS100v2
-   reference design with the placement of the BCBUS. If you plan to use
-   the port B, please check the readme of the XDS100v2 reference design
-   for details. Generally, a serial port on BCBUS should connect the
-   CPLD as follows: BCBUS1 -> CPLD TCK, BCBUS2 -> CPLD TDI, BCBUS5 ->
-   CPLD TDO, BCBUS6 -> CPLD TMS.
--  Please note that using UART mode simultaneously with `Code Composer
-   Studio v4 <http://processors.wiki.ti.com/index.php/Code_Composer_Studio_v4>`__ has NOT been tested
-   on the XDS100v2 design and is not officially supported. Experience
-   with C2000 ControlCards which implement this functionality indicate
-   the FTDI driver can handle such an interaction. \*The C2000 control
-   card does implement a serial port simultaneous with JTAG, but it is
-   done with an XDS100v1 design. There is a thread on the forum at
-   `[1] <http://e2e.ti.com/forums/p/7493/30331.aspx#30331>`__. The FTDI
-   driver gives each half of the FTDI chip a seperate USB handle and USB
-   endpoint, so they are essentially independent. The FTDI supplied
-   software is the software that is needed to get this support; there is
-   no TI specific software needed for this support.
-
-.. rubric:: Q: I see both 14 pin and 20 pin compact TI headers. Do I
-   need both?
-   :name: q-i-see-both-14-pin-and-20-pin-compact-ti-headers.-do-i-need-both
-
--  A: Both are in the reference schematic for testing Code Composer
-   Studio support. In the TI prototypes, we populate just one of the 2
-   headers. This allows use to test the extended capability available
-   with the 20 pin connection. Please use the header that is needed for
-   your target card.
-
-.. rubric:: XDS100v1 (Legacy)
-   :name: xds100v1-legacy
-
-.. rubric:: Q: Where can I get the schematic for the XDS100v1?
-   :name: q-where-can-i-get-the-schematic-for-the-xds100v1
-
--  A: It is available from
-   `here <http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_ccstudio/CCSv3/Drivers/setup_xds100_v1_0_schematic.exe>`__
-   (registration required).
--  A: The C2000 control card schematics implement an XDS100 design
-   optimized for C28x processors. The design is available as part of
-   their baseline SW packages. These can be downloaded
-   `here <http://focus.ti.com/mcu/docs/mcuprodmsptoolsw.tsp?sectionId=95&tabId=1222&familyId=916&toolTypeId=1&DCMP=C2000_F28x&HQS=Other+OT+c2000tools>`__
-
-.. rubric:: Q: What should the USB device's UID (VID/PID) be?
-   :name: q-what-should-the-usb-devices-uid-vidpid-be-2
-
--  A: The EEPROM needs to be programmed for a VID=0403 PID=A6D0. The
-   device name string should be, “Texas Instruments Inc.XDS100 Ver 1.0”.
--  A: FTDI has a utility called MProg. See
-   `here <http://www.ftdichip.com/Resources/Utilities.htm#MProg>`__. To
-   program the FTDI chip you will need a MPROG template file that can be
-   downloaded from `this link </images/7/7c/XDS100v1.zip>`__.
-
-   -  For 28x development cards, you may want to see this [`\|
-      post <http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/172/t/21086.aspx>`__]
-
-|
-
-|
-
-|
-
-|
-
-.. rubric:: Frequently Asked Questions (FAQ)
-   :name: frequently-asked-questions-faq
-
-.. rubric:: General FAQ
-   :name: general-faq
-
-.. rubric:: Q: Where can I find out more about Emulators which are
-   compatible with TI devices?
-   :name: q-where-can-i-find-out-more-about-emulators-which-are-compatible-with-ti-devices
-
--  A: A general overview of TI emulation capabilities is
-   `here <http://focus.ti.com/dsp/docs/dspfindtoolswbytooltype.tsp?sectionId=3&tabId=2093&toolTypeId=12&familyId=44>`__.
-   For additional performance and capabilities, you may wish to review
-   the `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ and `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__
-   product lines which support TI devices.
-
-.. rubric:: Q: I would like to purchase a faster emulator, which one is
-   recommended?
-   :name: q-i-would-like-to-purchase-a-faster-emulator-which-one-is-recommended
-
--  A: TMS320C28x: The Spectrum Digital C2000 XDS510LC JTAG emulator is
-   available, details may be found
-   `here <http://focus.ti.com/dsp/docs/thirdparty/catalog/devtoolsproductfolder.tsp?actionPerformed=productFolder&productId=2621>`__.
-   The Blackhawk C2000 USB controller (TI part #TMDSEMU2000U) is
-   available from TI
-   `here <http://focus.ti.com/dsp/docs/thirdparty/catalog/devtoolsproductfolder.tsp?actionPerformed=productFolder&productId=3158>`__.
--  A: TMS320C674x: The Blackhawk `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__\ (TI
-   part #TMDSEMU560U  for USB and TI part #TMDSEMU560PCI for PCI) are
-   available from TI
-   `here <http://focus.ti.com/docs/toolsw/folders/print/xds560.html>`__.
-   The Spectrum Digital `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__\ (TI part
-   #TMDSEMU510U for USB) is available from TI
-   `here <http://focus.ti.com/docs/toolsw/folders/print/xds510.html>`__.
-
-.. rubric:: Q: On the c28x, C674x, and C64x+ processor, does the XDS100
-   support `Real-Time Mode <http://processors.wiki.ti.com/index.php/Real-Time_Mode>`__?
-   :name: q-on-the-c28x-c674x-and-c64x-processor-does-the-xds100-support-real-time-mode
-
--  A: Yes. Learn more about `Real-Time
-   Mode <http://processors.wiki.ti.com/index.php/Real-Time_Mode>`__.
-
-.. rubric:: Q: How to maximize performance of XDS100 under CCS?
-   :name: q-how-to-maximize-performance-of-xds100-under-ccs
-
-A: A couple of things can be done to improve performance under CCS.
-Generally, the goal is to minimze the amount of information transferred
-for every action
-
--  Make the disassembly window smaller or close the disassembly window.
-   Stepping and general performance are better in the "C" language
-   environment if the disassembly window is closed.
--  Minimize the number of registers shown.
--  Minimize the number of watch windows/variable windows.
--  Turn off mixed C/disassembly mode.
--  Make sure you are plugged into a High Speed USB2.0 port (XDS100v2)
--  Single step debugging is rather slow, therefore a better performance
-   is obtained by running straight to specific points in your code by
-   setting breakpoints in these locations.
-
-.. rubric:: Q: Does the XDS100 support debugging the C672x processor?
-   :name: q-does-the-xds100-support-debugging-the-c672x-processor
-
--  A: No.
-
-.. rubric:: Q: Does the XDS100 support debugging the C24x processor?
-   :name: q-does-the-xds100-support-debugging-the-c24x-processor
-
--  A: No.
-
-.. rubric:: Q: Does DSP/BIOS Real Time Analysis with RTDX work?
-   :name: q-does-dspbios-real-time-analysis-with-rtdx-work
-
--  Q: When using DSP/BIOS and the Real Time Analysis setup for RTDX, I
-   get the cpu graph and real time logs updating. Does this mean RTDX is
-   working/supported on the XDS100?
--  A: RTDX is not supported on the XDS100. Please see the seciton `What
-   features does the XDS100 NOT
-   support <http://processors.wiki.ti.com/index.php/XDS100#Features_NOT_supported.C2.A0>`__
-
-.. rubric:: Q: Can I use `Advanced Event
-   Triggering <http://processors.wiki.ti.com/index.php/Advanced_Event_Triggering>`__ with XDS100?
-   :name: q-can-i-use-advanced-event-triggering-with-xds100
-
--  A: Yes.
-
-.. rubric:: Q: Can I plug more than one XDS100 (multiple XDS100) into a
-   PC?
-   :name: q-can-i-plug-more-than-one-xds100-multiple-xds100-into-a-pc
-
--  With CCS v4.1 (with the XDS100v2 SW) and above you can plug more than
-   one XDS100 on a single PC. This is not supported with CCSv3.3.
--  Each XDS100 must have a unique serial number. Run xds100serial.exe
-   installed under CCSv4.1 "<install_dir>/ccsv4/common/uscif/utility" to
-   get the serial number of each connected XDS100 emulator. Create
-   Target Configuration for 2 emulators, Under “connection properties”,
-   change “emulator selection” to “select by serial number” option.
-   Enter the corresponding serial number for each emulator. Save and
-   launch debugger.
--  With CCSv5, the xds100serial.exe utility is located in the folder
-   "<install_dir>/ccsv5/ccs_base/common/uscif"
--  With older versions of CCS (ex: CCS v3.3), there is a known issue
-   (see above) which prevents the CCS XDS100 driver from seeing more
-   than one XDS100 in a system. If more than one is in a system, only
-   the first one is recognized.
--  xds100serial.exe can detect both XDS100v1 and XDS100v2 emulators.
-
-|
-
-|
-
-|
-
-|
-
-.. rubric:: Q: Can I use the XDS100 with Stellaris Cortex M3 devices?
-   :name: q-can-i-use-the-xds100-with-stellaris-cortex-m3-devices
-
--  A: Stellaris is supported with CCS v4.2.2 and newer. You may also
-   want to look at: `TI tools support for Cortex
-   M3 <http://processors.wiki.ti.com/index.php/TI_tools_support_for_Cortex_M3>`__
-
-.. rubric:: Q: Can I use the XDS100v2 as JTAG simultaneously with the
-   second port being a serial port (UART)?
-   :name: q-can-i-use-the-xds100v2-as-jtag-simultaneously-with-the-second-port-being-a-serial-port-uart
-
--  A: Please check for additional details in the XDS100v2 hardware
-   design section. See
-   `XDS100#Q:_Can_I_use_port_B_as_a_UART.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_Can_I_use_port_B_as_a_UART.3F>`__.
-
-.. rubric:: Q: How can I use the XDS100v2's second port as a serial port
-   (UART)?
-   :name: q-how-can-i-use-the-xds100v2s-second-port-as-a-serial-port-uart
-
--  A: Ensure that there is a physical connection between the FTDI Port B
-   TX and RX pins and your target serial device and then follow these
-   steps:
-
-#. Click Start, Right click on My Computer, and select Properties
-#. Navigate to the Hardware tab of the System Properties dialog box and
-   select Device Manager
-#. In the list of devices, expand the group titled Universal Serial Bus
-   controllers and look for a device named TI XDS100 Channel B
-#. Right click on this device and select Properties
-#. On the Advanced tab of this dialog box, ensure that the box labeled
-   "Load VCP" (virtual COM port) is checked. Click OK when you are done.
-#. Unplug and replug the XDS100v2
-#. After the XDS100V2 has been re-connected, look for a group called
-   Ports (COM & LPT) in Device Manager. Expand this group and look for
-   an entry labaled USB Serial Port (COMXXX).
-#. The COM number associated with this port is the one you want to use
-   in Hyperterminal, PuTTy, or your favorite terminal application.
-
-.. rubric:: Q: How can I turn on adaptive clocking?
-   :name: q-how-can-i-turn-on-adaptive-clocking
-
--  A: You need to select the `Adaptive
-   Clocking <http://processors.wiki.ti.com/index.php/Adaptive_Clocking>`__ option in the setup box
-   (CCS v4.x).
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/Xds100v2_adaptiveb.jpg
-
-.. raw:: html
-
-   </div>
-
--  You can change the timeouts from the target as well. This is helpful
-   if you get many timeout messages.
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/Xds100v2_dm365_timeout.jpg
-
-.. raw:: html
-
-   </div>
-
--  Note that the XDS100v2 users should upgrade to the latest CPLD. An
-   upgrade of the CPLD will improve reliability for adaptive clocking
-   connections. To update the XDS100v2 CPLD, please see
-   `XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F>`__
-
-.. rubric:: Q: My XDS100v2 does not work reliabily with the OMAPL138 /
-   DM365 / ARM926 core
-   :name: q-my-xds100v2-does-not-work-reliabily-with-the-omapl138-dm365-arm926-core
-
--  A: This can be caused by a variety of issues such as where the PLL is
-   programmed to the use of `Adaptive
-   Clocking <http://processors.wiki.ti.com/index.php/Adaptive_Clocking>`__ emulator. Usually, it is
-   seen as a problem around the PLL setup. This is because the core PLL
-   clock is changing. Example error message:
-
-::
-
-    ARM9: GEL Output: Setup PLL0...
-
-    ARM9: Trouble Writing Memory Block at 0x1c40900 on Page 0 of Length 0x4: 0x00000004/-2030 @ marker 1026 Error during: Register, Access to an unknown or invalid register was attempted.
-
-    ARM9: GEL: Error while executing OnTargetConnect(): target access failed.
-
-A couple of things to try:
-
-#. Setup the PLL by executing code (ex: UBoot, etc.) instead of using
-   the GEL file. (preferred)
-#. Turn on adaptive clocking
-   `XDS100#Q:_How_can_I_turn_on_adaptive_clocking.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_turn_on_adaptive_clocking.3F>`__
-   and setup the timeouts to very slow. In this mode, it is still better
-   to "run" the code and not "step" it.
-#. Make sure you have the latest CPLD version. To update the XDS100v2
-   CPLD, please see
-   `XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_update_the_CPLD_on_my_XDS100v2.3F>`__
-
-.. rubric:: Q: Can I use the XDS100 with OMAP-L138/C6748 EVM board?
-   :name: q-can-i-use-the-xds100-with-omap-l138c6748-evm-board
-
--  A: See `How to connect to the OMAP-L138/C6748 EVM board using
-   CCS? <http://processors.wiki.ti.com/index.php/How_to_connect_to_the_OMAP-L138/C6748_EVM_board_using_CCS%3F>`__
--  A: See also
-   `XDS100#Q:_My_XDS100v2_does_not_work_reliabily_with_the_OMAPL138_.2F_DM365_.2F_ARM926_core. <http://processors.wiki.ti.com/index.php/XDS100#Q:_My_XDS100v2_does_not_work_reliabily_with_the_OMAPL138_.2F_DM365_.2F_ARM926_core.>`__
-
-.. rubric:: Q: Does XDS100 work with Window 7 64 bit?
-   :name: q-does-xds100-work-with-window-7-64-bit
-
--  The current driver in XDS100v2 works with Windows 7 (64 bit).
-
-.. rubric:: Q: Can I use the XDS100 without CCS? Is there an API to
-   access it's functions?
-   :name: q-can-i-use-the-xds100-without-ccs-is-there-an-api-to-access-its-functions
-
--  Not at this time.
--  We have some requests for an API to read/write targets,
-   run/halt/step, load memory and handle STDIO. If you have requests,
-   please post them in the support forum.
--  If you need API for accessing CCS, without a GUI, you may want to
-   consider `Debug Server
-   Scripting <http://processors.wiki.ti.com/index.php/Debug_Server_Scripting>`__
-
-.. rubric:: Q: Can I use the XDS100v1/v2 with CC13xx/CC26xx SimpleLink
-   ULP devices?
-   :name: q-can-i-use-the-xds100v1v2-with-cc13xxcc26xx-simplelink-ulp-devices
-
--  A: No, only XDS100v3 supports the CC13xx/CC26xx device family. See
-   `CC13xx CC26xx Tools
-   Overview <http://processors.wiki.ti.com/index.php/CC13xx_CC26xx_Tools_Overview>`__ for more
-   details on debugger support for these devices.
-
-|
-
-|
-
-|
-
-|
-
-.. rubric:: Installation FAQ
-   :name: installation-faq
-
-.. rubric:: Q: Where are the drivers for the hardware? Windows is asking
-   for the drivers.
-   :name: q-where-are-the-drivers-for-the-hardware-windows-is-asking-for-the-drivers.
-
--  A: Please see Installation instructions and
-   `troubleshooting <http://processors.wiki.ti.com/index.php/XDS100#Troubleshooting>`__ section.
-
-.. rubric:: Q: What operating systems are supported?
-   :name: q-what-operating-systems-are-supported
-
--  A: Please see `System
-   Requirements <http://processors.wiki.ti.com/index.php/System_Requirements>`__ for Operating System
-   support for CCS.
-
-.. rubric:: Q: I do not see my F28x Piccolo device listed in the CCS
-   setup menu.
-   :name: q-i-do-not-see-my-f28x-piccolo-device-listed-in-the-ccs-setup-menu.
-
--  A: You have an older version of the XDS100 SW/CCS. The F28x Piccolo
-   device configuration files are included in the latest versions of the
-   SW. Please see the installation notes above.
-
-.. rubric:: Q: What does the windows messages look like in Windows XP
-   upon successful installation?
-   :name: q-what-does-the-windows-messages-look-like-in-windows-xp-upon-successful-installation
-
--  A: See
-   `here <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/CCSv4/Demos/xds100installinxp.htm>`__.
-   Note that after the first installation, there are no subsequent
-   messages in Windows XP from the USB driver.
-
-.. rubric:: Q: I am using CCSv3.3 today. Can I get a driver to support
-   XDS100 for my processor?
-   :name: q-i-am-using-ccsv3.3-today.-can-i-get-a-driver-to-support-xds100-for-my-processor
-
-A: All new XDS100 development is being done on `Code Composer Studio
-v4 <http://processors.wiki.ti.com/index.php/Code_Composer_Studio_v4>`__. Existing processors
-supported by XDS100 in CCSv3.3 will continue to be supported, but newer
-processors will not be added.
-
-.. rubric:: Q: Can I use `Code Composer Studio
-   v4 <http://processors.wiki.ti.com/index.php/Code_Composer_Studio_v4>`__ with XDS100?
-   :name: q-can-i-use-code-composer-studio-v4-with-xds100
-
-A: There is a free license for `Code Composer Studio
-v4 <http://processors.wiki.ti.com/index.php/Code_Composer_Studio_v4>`__ when used with XDS100. Code
-Composer Studio v4 can be downloaded from the `Code Composer Studio
-v4 <http://processors.wiki.ti.com/index.php/Code_Composer_Studio_v4>`__ page. When you install CCS,
-you need to select the correct license. See below on how to select the
-correct license. This license is designed to be use with XDS100 only,
-and not `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ or `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__
-emulators. Please see `Activating
-CCS#Generate_and_Install_a_License_File <http://processors.wiki.ti.com/index.php/Activating_CCS#Generate_and_Install_a_License_File>`__
-for details.
-
-.. Image:: /images/CCSV4xds100license.jpg
-
-|
-
-.. rubric:: Troubleshooting FAQ
-   :name: troubleshooting-faq
-
-.. rubric:: Q: Why is the download frozen?
-   :name: q-why-is-the-download-frozen
-
--  A: While loading a large program or program section, the file load
-   status bar may appear frozen when it is not frozen. The status bar is
-   showing section load start and completion.
-
-.. rubric:: Q: Windows is recognizing the XDS100 as "Dual RS232 USB
-   Serial Bridge" instead of the TI XDS100 JTAG emulator.
-   :name: q-windows-is-recognizing-the-xds100-as-dual-rs232-usb-serial-bridge-instead-of-the-ti-xds100-jtag-emulator.
-
--  Q: I have a C2000 Experimenter kits/Piccolo USB Stick that includes
-   the onboard USB JTAG emulation, but the onboard USB JTAG emulation is
-   being recognized by Windows as "Dual RS232 USB Serial Bridge" instead
-   of the TI XDS100 JTAG emulator.
-
--  A: See this
-   `post <http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/172/t/21086.aspx>`__
-   on the forums.
-
--  A: You may want to check
-   `XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F_if_your_VID.2FPID_are_programmed_correctly <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F_if_your_VID.2FPID_are_programmed_correctly>`__
-
-.. rubric:: Q: I used the FTClean utility on my computer and now I can't
-   connect to the XDS100! What can I do?
-   :name: q-i-used-the-ftclean-utility-on-my-computer-and-now-i-cant-connect-to-the-xds100-what-can-i-do
-
--  A: Running FTClean will remove the windows FTDI drivers for the
-   XDS100. The TI XDS100 FTDI drivers were installed with the CCS
-   installation or service patch. The XDS100 drivers are signed for the
-   VID/PID combination. To recover, please re-install the CCS
-   version/path you were last using before running FTClean which
-   included the TI signed XDS100 drivers.
-
-.. rubric:: Q: My XDS560 stopped working when I installed the XDS100...
-   :name: q-my-xds560-stopped-working-when-i-installed-the-xds100...
-
--  A: Note that the XDS100 software is included and installed with CCS
-   v3.3 SR12 or newer and/or CCSv4. For CCS v3.3 and SR12, it is
-   recommended that users install the new Blackhawk XDS560 driver from
-   Blackhawk website. There is no need to install a new Blackhawk driver
-   with CCS v4.
-
-.. rubric:: Q: My JTAG is not working with CCS...
-   :name: q-my-jtag-is-not-working-with-ccs...
-
-A: Please check: `Debugging JTAG Connectivity
-Problems <http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems>`__
-
-.. rubric:: Q: I see in my Windows Device Manager an error for a TI
-   `XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__ emulator.
-   :name: q-i-see-in-my-windows-device-manager-an-error-for-a-ti-xds560-emulator.
-
-A: The XDS100 will not be affected by this. Please see
-`XDS560#Q:_Why_does_my_Windows_Device_Manager_show_a_warning_for_the_TI_XDS560_PCI_Emulator.3F <http://processors.wiki.ti.com/index.php/XDS560#Q:_Why_does_my_Windows_Device_Manager_show_a_warning_for_the_TI_XDS560_PCI_Emulator.3F>`__
-
-.. rubric:: Q: I see a Windows device manager problem with Texas
-   Instruments XDS560 PCI JTAG emualtor. Does this affect the XDS100?
-   :name: q-i-see-a-windows-device-manager-problem-with-texas-instruments-xds560-pci-jtag-emualtor.-does-this-affect-the-xds100
-
-A: No. This error is caused by the Texas Instruments XDS560 PCI JTAG
-emulator not being installed. This service may be used by other
-`XDS560 <http://processors.wiki.ti.com/index.php/XDS560>`__ emulators. A proper setup in Windows
-device manager will look like the image in
-`XDS100#Troubleshooting <http://processors.wiki.ti.com/index.php/XDS100#Troubleshooting>`__.
-
-.. rubric:: Q: Can I use an XDS100v2 hardware with a older version of
-   Code Composer Studio? (Ex: CCS v3.3)
-   :name: q-can-i-use-an-xds100v2-hardware-with-a-older-version-of-code-composer-studio-ex-ccs-v3.3
-
--  A: No. The XDS100v2 will not work with older versions of Code
-   Composer Studio that do not support the XDS100v2. Code Composer
-   Studio v3.3 is not supported by the XDS100v2 hardware. For Code
-   Composer Studio v4 users, please upgrade to the latest software
-   versions as listed in the software installation section. If you use a
-   XDS100v2 hardware unit with a version of CCS which does not support
-   it, the software will just see a zero-bit scan chain. If you use
-   `DBGJTAG <http://processors.wiki.ti.com/index.php?title=DBGJTAG&action=edit&redlink=1>`__ to test
-   the JTAG scan path, it will look like the below, with a zero-bit scan
-   path on both IR and DR.
-
-::
-
-    C:\ccsv4\ccsv4\common\uscif>dbgjtag -f "C:\ccsv4\ccsv4\DebugServer\bin\win32\BrdDat\ccBoard0.dat" -rv -S pathlength
-    -----[Print the reset-command software log-file]-----------------------------
-
-    This utility will use the original port address '0'.
-    The controller does not use a programmable FPGA.
-    The emulator adapter uses the JIO interface.
-    The emulator adapter is named 'jioserdesusb.dll'.
-    The emulator adapter is version '35.34.0.7'.
-    The controller has a version number of '4' (0x00000004).
-    The controller has an insertion length of '0' (0x00000000).
-    This utility will now attempt to reset the controller.
-    This utility has successfully reset the controller.
-
-    -----[Print the reset-command hardware log-file]-----------------------------
-
-    The scan-path will be reset by toggling the JTAG TRST signal.
-    The controller is the FTDI FT2232 with USB interface.
-    The link from controller to target is direct (without cable).
-    The software is configured for FTDI FT2232 features.
-    The controller cannot monitor the value on the EMU[0] pin.
-    The controller cannot monitor the value on the EMU[1] pin.
-    The controller cannot control the timing on output pins.
-    The controller cannot control the timing on input pins.
-    The scan-path link-delay has been set to exactly '0' (0x0000).
-    This utility will use the original port address '0'.
-    The emulator adapter uses the JIO interface.
-    The emulator adapter is named 'jioserdesusb.dll'.
-    The emulator adapter is version '35.34.0.7'.
-    The controller has a version number of '4' (0x00000004).
-    The controller has an insertion length of '0' (0x00000000).
-    The local memory has a word capacity of '1048576' (0x00100000).
-
-    -----[Perform the standard path-length test on the JTAG IR and DR]-----------
-
-    This path-length test uses blocks of 512 32-bit words.
-
-    The test for the JTAG IR instruction path-length succeeded.
-    The JTAG IR instruction path-length is 0 bits.
-
-    The test for the JTAG DR bypass path-length succeeded.
-    The JTAG DR bypass path-length is 0 bits.
-
-.. rubric:: Q: On connecting the USB, I get the error message "The file
-   FTDIBUS.SYS on FTDI USB Drivers Disk is needed"
-   :name: q-on-connecting-the-usb-i-get-the-error-message-the-file-ftdibus.sys-on-ftdi-usb-drivers-disk-is-needed
-
--  A: The USB drivers are likely missing. Please see the installation
-   instructions above to install the software before trying to connect
-   the XDS100.
--  A: It may also be that the FTDI EEPROM is not properly progrmmed.
-   Please contact your XDS100 vendor to have the problem corrected. You
-   could also see the section on
-   `Xds100#How_to_make_an_XDS100 <http://processors.wiki.ti.com/index.php/Xds100#How_to_make_an_XDS100>`__
-   to program the EEPROM.
-
-.. rubric:: Q: I got a -150 SC_ERR_POD_FAIL error, what does this mean?
-   :name: q-i-got-a--150-sc_err_pod_fail-error-what-does-this-mean
-
--  For an XDS100, this means that Code Composer Studio is having a
-   problem talking to the XDS100. The problem is with the communication
-   between the adapter and the FTDI chip. Either the FTDI driver has
-   returned an error, or the chip failed to return the expected number
-   of bytes to Code Composer Studio. In practice, this has usually been
-   found to be a problem with the FTDI drivers. Either the wrong drivers
-   were installed, or there is a conflict with FTDI drivers used for
-   another device, or a software process that hasn’t completely
-   terminated and is holding the device open. In the case where a
-   software process hasn't terminated, it may be that Code Composer
-   Studio may not have terminated properly. Check the Windows Task
-   Manager that Code Composer Studio related processes are terminated
-   prior to re-starting.
-
-.. rubric:: Q: I got an "Error connecting to the target: Error
-   0x80000240/-151 Fatal Error during: Initialization, OCS" when trying
-   to connect to the target in `Code Composer Studio
-   v4 <http://processors.wiki.ti.com/index.php/Code_Composer_Studio_v4>`__
-   :name: q-i-got-an-error-connecting-to-the-target-error-0x80000240-151-fatal-error-during-initialization-ocs-when-trying-to-connect-to-the-target-in-code-composer-studio-v4
-
-.. Image:: /images/Xds100v1poderror.jpg
-
--  A: This can occur for several reasons. With XDS100 systems, this can
-   occur because the EEPROM was not programmed properly. Please check
-   with your XDS100 manufacturer.
--  A: More details on checking your EEPROM are
-   `XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F>`__
-
-.. rubric:: Q: I was following `Debugging JTAG Connectivity
-   Problems <http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems>`__ and I a
-   -151 SC_ERR_POD_OPEN error with `Dbgjtag <http://processors.wiki.ti.com/index.php/Dbgjtag>`__.
-   :name: q-i-was-following-debugging-jtag-connectivity-problems-and-i-a--151-sc_err_pod_open-error-with-dbgjtag.
-
-.. Image:: /images/Xds100v1nopiddbgjtagpodfail.jpg
-
--  A: This can occur for several reasons. With XDS100 systems, this can
-   occur because the EEPROM was not programmed properly. Please check
-   with your XDS100 manufacturer.
--  A: More details on checking your EEPROM are
-   `XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F>`__
-
-.. rubric:: Q: What happens when I plug a XDS100v2 in to my card but
-   select XDS100v1 or XDS100 as the emulator?
-   :name: q-what-happens-when-i-plug-a-xds100v2-in-to-my-card-but-select-xds100v1-or-xds100-as-the-emulator
-
--  A: The output from a `path length
-   test <http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems>`__ will look
-   like it is passing, with a zero - bit path length. This is because
-   the XDS100v2 has a loopback mode which is used in testing. When the
-   XDS100v1 software is used, it invokes this loopback mode.
-
-::
-
-    -----[Perform the standard path-length test on the JTAG IR and DR]-----------
-    This path-length test uses blocks of 512 32-bit words.
-    The test for the JTAG IR instruction path-length succeeded.
-
-    The JTAG IR instruction path-length is 0 bits.
-    The test for the JTAG DR bypass path-length succeeded. The JTAG DR bypass path-length is 0 bits.
-
--  From Code Composer Studio, the error may look like an unrecoverable
-   emulation error:
-
-::
-
-    Error connecting to the target:
-    Error 0x00001200/-1135
-    Error during: OCS, Target,
-    Unrecoverable emulation error
-
-.. rubric:: Q: What happens when I plug a XDS100v1 into a card but
-   select an XDS100v2 in CCS?
-   :name: q-what-happens-when-i-plug-a-xds100v1-into-a-card-but-select-an-xds100v2-in-ccs
-
--  A: The output from `path length
-   test <http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems>`__ will vary
-   with the target device. This is because the XDS100v2 uses the pins on
-   the communications chip different from how it was used on the
-   XDS100v1. On some devices such as c28x, it may cause the device to
-   enter an unexpected bootmode. For the example with a 28x core, a
-   3-bit path length was seen vs a 38-bit path lengh (expected). This
-   was because a bootmode was selected.
-
-.. rubric:: Q: I just upgraded to CCS 4.1.2 and now my XDS100 is not
-   working. It was working before!
-   :name: q-i-just-upgraded-to-ccs-4.1.2-and-now-my-xds100-is-not-working.-it-was-working-before
-
--  A: `Check your VID/PID
-   value. <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F>`__
-   If it does not match, you need to contact your manufacturer, or get
-   the VID/PID EEPROM programmed properly.
--  A: With CCS 4.1.2 and newer, a bug was fixed so that the XDS100
-   software could properly connect only to a XDS100 VID/PID values. In
-   older versions of CCS, the XDS100 software would connect to any
-   VID/PID value causing incompatibilties with non-XDS100 FTDI based
-   devices plugged into the same PC.
-
-.. rubric:: Q: I was using CCS v3.3 SR12 before and upgraded to CCS
-   4.1.2 (or newer) and now my XDS100 is not working. It was working
-   before!
-   :name: q-i-was-using-ccs-v3.3-sr12-before-and-upgraded-to-ccs-4.1.2-or-newer-and-now-my-xds100-is-not-working.-it-was-working-before
-
--  `Please see previous
-   topic <http://processors.wiki.ti.com/index.php/Xds100#Q:_I_just_upgraded_to_CCS_4.1.2_and_now_my_XDS100_is_not_working._It_was_working_before.21>`__
-
-.. rubric:: Hardware FAQ
-   :name: hardware-faq
-
-.. rubric:: Q: Where can I find out about pinout of JTAG connectors?
-   :name: q-where-can-i-find-out-about-pinout-of-jtag-connectors
-
--  A: Please check the page on `JTAG
-   Connectors <http://processors.wiki.ti.com/index.php/JTAG_Connectors>`__.
-
-.. rubric:: Q: What if I need electrical isolation?
-   :name: q-what-if-i-need-electrical-isolation
-
--  A: If you are working with a target which has high voltages, you may
-   want to use an isolation adapter.
--  There is an isolation adapter available
-   `here <http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html>`__
-   and a usb isolation adapter available in china mainland
-   `here <https://item.taobao.com/item.htm?spm=a1z10.5-c.w4002-5359301182.14.b19Chh&id=41050855660>`__
-
-|
-
-.. rubric:: Q: What device voltages are supported by the XDS100v1?
-   :name: q-what-device-voltages-are-supported-by-the-xds100v1
-
--  A: The XDS100v1 reference design supports 1.8V and 3.3V targets. The
-   SN74CBT3125 (U3) and SN74LVC2T45 (U5) perform the voltage buffering.
-   The MCP6041 (IC5) and TLC393 (IC1B) are used for voltage sensing. The
-   74HC74(IC3A) and TLC393 (IC1A) form the power detect circuit by
-   reaching the TVO pin.
-
-.. rubric:: Q: I work with high voltages, where can I get an isolation
-   adapter?
-   :name: q-i-work-with-high-voltages-where-can-i-get-an-isolation-adapter
-
--  A: TI offers an isolation adapter (TI part #: TMDSADP1414-ISO)
-   `here <http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html>`__.
-
-.. rubric:: Q: Can I change the serial number on my XDS100v2?
-   :name: q-can-i-change-the-serial-number-on-my-xds100v2
-
--  A: Yes, using the FTDI MProg utility and one of the configurations in
-   `Media:Xds100v2serial.zip </images/8/85/Xds100v2serial.zip>`__ so you
-   can change the serial number of an XDS100v2 product if desired.
--  **NOTE: Support for MProg is being deprecated in favor of FT_Prog
-   (also available on the same site). If you are having issue with
-   MProg, try FT_Prog**
--  If you plan to use 1 or more XDS100v2 emulators in CCSv4
-   simultaneously then each XDS100v2 must have a unique serial number.
--  For ease of use Spectrum Digital generally programs the XDS100v2 with
-   a fixed serial number as this is the most common use case and is
-   consistent with other low cost Spectrum Digital products.
-
-::
-
-    Steps:
-    1) Launch MProg.
-    2) Load the desired configuration.
-         For Fixed Serial Number:         File->Open SDXDS100v2_FIXED.EPT
-         For Autogenerated Serial Number: File->Open SDXDS100v2.EPT
-    3) Enable programming of pre-programmed devices if needed.
-           File->Edit and uncheck "Only Program Blank Devices"
-    4) Program the ROM
-          Device->Program
-
-.. rubric:: Q: What frequencies are supported by XDS100v2? Can I change
-   it?
-   :name: q-what-frequencies-are-supported-by-xds100v2-can-i-change-it
-
--  A: The default frequency is 1Mhz. Other frequencies can be selected,
-   but they are not supported.
-
-.. rubric:: Q: On XDS100v1 design, what does the OE signal do? (pin 12
-   of FTDI)
-   :name: q-on-xds100v1-design-what-does-the-oe-signal-do-pin-12-of-ftdi
-
--  A: On the XDS100v1 design, this OE signal on pin 12 of the FTDI chip
-   comes from the ICA3A device (74HC74, flip flop). The ICA3A/IC1A
-   section of the circuit samples the TVD signal to detect whether there
-   is target power. This signal is read by the debugger via the GPIO on
-   the FTDI. This signal has an opposite signal /OE which goes to U3. U3
-   provides a buffer which performs the voltage translation.
-
-.. rubric:: Q: How can I check if the VID/PID for the EEPROM are
-   programmed correctly?
-   :name: q-how-can-i-check-if-the-vidpid-for-the-eeprom-are-programmed-correctly
-
--  A: You can find the VID/PID in windows by using the windows device
-   manager and selecting details. You can also use the FTDI utilities
-   such as MPROG or FT_Prog. When using MPROG or FT_Prog, you need to
-   scan devices to read the ID.
-
-**IMPORTANT!** This is not applicable for BeagleBone Rev A5 and greater
-(which uses a XDS100). Check `this
-FAQ <http://processors.wiki.ti.com/index.php/FAQ_-_CCSv5#Q:_I_can.27t_connect_to_my_BeagleBone_in_CCSv5._What_is_happening.3F>`__
-entry.
-
-.. Image:: /images/Xd100damagedvidpid.jpg
-
--  Expected XDS100 VID/PID should be as described in the sections `how
-   to make an
-   XDS100 <http://processors.wiki.ti.com/index.php/XDS100#How_to_make_an_XDS100_.2F_How_to_build_an_XDS100_hardware_emulator>`__
--  A: If your hardware VID/PID does not match what is described in `How
-   to make an
-   XDS100 <http://processors.wiki.ti.com/index.php/XDS100#How_to_make_an_XDS100_.2F_How_to_build_an_XDS100_hardware_emulator>`__,
-   please contact your hardware manufacturer.
-
-**Note:**\ It is possible to reprogram the EEPROM using MPROG or FT_Prog
-and the .ept file. The .ept file depends on the type of device you have.
-If you have a *FT2232C* device download the following `FT2232C EPT
-file </images/0/00/XDS100_wUART.zip>`__. If you have a *FT2232H* device
-download the following `FT2232H EPT
-file </images/f/f8/XDS100_wUART_FT2232H.zip>`__. Refer to the
-instructions in the `How to make an XDS100
-section <http://processors.wiki.ti.com/index.php/XDS100#How_to_make_an_XDS100_.2F_How_to_build_an_XDS100_hardware_emulator>`__
-
--  A: For some 28x based cards, a similar problem may
-   `occur <http://processors.wiki.ti.com/index.php/XDS100#Q:_Windows_is_recognizing_the_XDS100_as_.22Dual_RS232_USB_Serial_Bridge.22_instead_of_the_TI_XDS100_JTAG_emulator.>`__
-
-|
-
-.. rubric:: Q: How do I reprogram the VID/PID EEPROM if it has not been
-   programmed correctly?
-   :name: q-how-do-i-reprogram-the-vidpid-eeprom-if-it-has-not-been-programmed-correctly
-
--  A If your VID/PID EEPROM has been programmed incorrectly, or not
-   programmed at all, you can reprogram it with these simple steps
-
-#. Download and Install MPROG from FDTI. You can get MPROG 3.5 from
-   `here <http://www.ftdichip.com/Support/Utilities/MProg3.5.zip>`__
-#. Download and extract the ept file from
-   `here </images/0/00/XDS100_wUART.zip>`__
-#. Connect your XDS100 to the PC via the USB Cable
-#. Execute MProg.exe from within the directory structure where you
-   installed MPROG. You should see a screen like the one pictured below.
-#. Select File->Open, and select the XDS100_wUART.ept file you extracted
-#. Select Device->Scan to verify that it will talk to your XDS100
-#. Select Device->Erase to erase the existing programming
-#. Select Device->Program to program the correct settings
-#. Close MPROG
-
-.. Image:: /images/MPROG_3.5.jpg
-
-You should now be able to follow the directions
-`Here <http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F>`__
-to verify that it has been programmed correctly. If it has, you should
-now be able to use your XDS100 with CCS.
-
-.. rubric:: Q: Does the XDS100v2 latch data on the rising or falling
-   edge?
-   :name: q-does-the-xds100v2-latch-data-on-the-rising-or-falling-edge
-
--  A: Falling edge.
-
-.. rubric:: Q: How do I tell what the CPLD version is on my XDS100v2?
-   :name: q-how-do-i-tell-what-the-cpld-version-is-on-my-xds100v2
-
--  A: Please contact your manufacturer. They may be able to tell from
-   the manufacturing ID. There is no ID in the cpld code, so it cannot
-   be determined by software.
-
-.. rubric:: Q: How can I update the CPLD on my XDS100v2?
-   :name: q-how-can-i-update-the-cpld-on-my-xds100v2
-
--  A: If your manufacturer built the XDS100v2 according to the reference
-   design, you will be able to upgrade the XDS100v2 CPLD via SW. If your
-   manufacturer did not follow the XDS100v2 reference design, please
-   contact your manufacturer directly.
--  As of 4/28/2010, an enhancment to improve reliability with devices
-   which require `Adaptive Clocking <http://processors.wiki.ti.com/index.php/Adaptive_Clocking>`__
-   (ex: ARM9) is included with the updated CPLD. The specific items
-   implemented in this CPLD update are:
-
-#. TCK loopback when a power loss is detected
-#. Fixed definitions of certain signals from "inout" to "output" (EMUs
-   and TMS). T_SRST remains "inout".
-
--  For XDS100v2 designs which have followed the TI reference design, the
-   CPLD can be re-programmed through the USB by using the utility
-   `here <http://support.spectrumdigital.com/ccs40/xds100v2/>`__. Usage
-   instructions are included in the installation.
--  Blackhawk has placed XDS100v1/v2 updates
-   `here <http://www.blackhawk-dsp.com/support/xds100/>`__. *This
-   includes the CPLD update as well as instructions for updating a
-   Blackhawk v1 USB100 device to v2.*
--  Please note that this CPLD update is designed for use with CCS v4.1.1
-   and newer.
-
-.. rubric:: Q: How do I perform a system reset (SRST) using
-   the XDS100v3?
-   :name: q-howdo-iperform-a-system-reset-srstusing-thexds100v3
-
-| A: There is an issue in the FPGA VHDL released in the XDS100v3 Design
-  Kit v1.0 on 1 June 2011 which inadvertently disables this feature.  It
-  will be corrected in the next XDS100v3 Design Kit update. 
-
-.. rubric:: Older Versions
-   :name: older-versions
-
-| `XDS100 v1.0 RTM
-  SW <https://www-a.ti.com/apps/advisor/xt_download.asp?sku=XDS100&download_file=XDS100_RTM_Release.exe>`__:
-  It is recommended that users upgrade to the latest versions of the
-  XDS100 SW. Please check the Software section above. Do NOT install
-  this if you are using CCS v3.3 SR12 or newer, a CCS which came with
-  your C2000 Control Stick, or CCSv4.
-
-|
-
-|
-
-|
-
---------------
-
-`essay writing <http://custom-essay.ws/index.php>`__
-
diff --git a/source/rtos/Tools/Code_Composer_Studio/_XDS560_Emulator_Info.rst b/source/rtos/Tools/Code_Composer_Studio/_XDS560_Emulator_Info.rst
deleted file mode 100644
index 2d1056b44..000000000
--- a/source/rtos/Tools/Code_Composer_Studio/_XDS560_Emulator_Info.rst
+++ /dev/null
@@ -1,630 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/XDS560
-
-.. rubric:: Overview
-   :name: overview
-
--  The XDS560 Emulator is a high speed JTAG connection between Code
-   Composer Studio and the target device.
--  More information can be found here:
-   `[1] <http://focus.ti.com/docs/toolsw/folders/print/xds560.html>`__
--  The XDS560 Emulators support `High Speed RTDX
-   (HSRTDX) <http://processors.wiki.ti.com/index.php/High_Speed_RTDX_(HSRTDX)>`__
-
-+-----------------------------------+-----------------------------------+
-| **Warning**:                      | As of 6/24/2010 RTDX and HS-RTDX  |
-|                                   | are no longer supported.          |
-|                                   | Alternative transports should be  |
-|                                   | considered for the acquision of   |
-|                                   | data, such as serial ports and    |
-|                                   | ethernet. If you are currently    |
-|                                   | using the technology and have no  |
-|                                   | issues, there is no need to       |
-|                                   | change. However, no action will   |
-|                                   | be taken for support inqueries.   |
-+-----------------------------------+-----------------------------------+
-
--  The XDS560 Emulators support `Advanced Event
-   Triggering <http://processors.wiki.ti.com/index.php/Advanced_Event_Triggering>`__
--  The XDS560 Emulators support `IEEE 1149.1
-   (JTAG) <http://processors.wiki.ti.com/index.php/IEEE_1149.1_(JTAG)>`__
--  A general overview of TI emulation capabilities is
-   `here <http://focus.ti.com/dsp/docs/dspfindtoolswbytooltype.tsp?sectionId=3&tabId=2093&toolTypeId=12&familyId=44>`__.
--  For information about JTAG headers, please check the WIKI page `JTAG
-   Connectors <http://processors.wiki.ti.com/index.php/JTAG_Connectors>`__.
--  For debugging issues with JTAG, you may want to check the topic
-   `Debugging JTAG Connectivity
-   Problems <http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems>`__
--  An XDS560 with Ethernet LAN support is available from
-   `here <http://www.blackhawk-dsp.com/Lan560.aspx>`__
--  `XDS560v2 System Trace <http://processors.wiki.ti.com/index.php/XDS560v2_System_Trace>`__
-
-|
-
-.. rubric:: XDS560v2 System Trace
-   :name: xds560v2-system-trace
-
--  The `XDS560v2 System Trace <http://processors.wiki.ti.com/index.php/XDS560v2_System_Trace>`__
-   emulator is now available. It offers increased performance and
-   features.
-
-.. rubric:: XDS560 Rev D Cable
-   :name: xds560-rev-d-cable
-
-In addition to the standard XDS560 features, the XDS560 Rev D cable also
-supports:
-
--  Compact TI 20-pin target card connector
--  Adaptive clocking for TI devices with ARM processors
--  EMU pin boot modes
--  Remote system reset `System Reset
-   (Emulation) <http://processors.wiki.ti.com/index.php/System_Reset_(Emulation)>`__
--  RTCK/TCK looback
-
-Rev D cables can be identified by their "00D" at the end of the cable
-serial number.
-
-The TI 20-pin target card connector reduces the PWB foot print over the
-traditional TI 14-pin target connector while expanding the number of EMU
-pins supported. See `JTAG Connectors <http://processors.wiki.ti.com/index.php/JTAG_Connectors>`__
-Wiki page for the TI 20-pin cable's pin assignments and target card
-connector part number. The board requirements provided in `XDS560
-Emulator Technical
-Reference <http://focus.ti.com/lit/ug/spru589a/spru589a.pdf>`__ are
-valid except in the adaptive clocking case. The additional EMU pins are
-treated electrically identical to EMU0 and EMU1. See below for SYSRST
-board requirment.
-
-Adaptive clocking for ARM devices can be enabled through CCSetup’s
-Connection Properties page (see “JTAG TCKL Frequency (MHz)” selection
-options). See the `Adaptive Clocking <http://processors.wiki.ti.com/index.php/Adaptive_Clocking>`__
-Wiki page for more information and board requirements. Generally, in CCS
-3.3 Setup, you may need to select the create board option to enable the
-rev D capabilities. This can be seen in the screen shot below.
-
-.. Image:: /images/Ccsetup-02.jpg
-
-Once this is done, in the connnection properties, it is possible to
-select the "Adaptive Clocking" options.
-
-.. Image:: /images/Ccsetup-04.jpg
-
-For devices that support EMU Boot modes the XDS560 Rev D cable drives
-the selected EMU pin polarity on the rising edge of nTRST or TVD. The
-EMU pin polarity selection is enabled through CCSetup’s Connection
-Properties page (see “JTAG nTRST Boot Mode” or “Power on-Reset Boot
-Mode” selection options).To determine if your device supports boot
-modes, which modes are supported and the proper polarity for each boot
-mode see your device’s data sheet.
-
-.. Image:: /images/Ccsetup-05.jpg
-
-The XDS560 Rev D cable supports a remote system reset capability. The
-SYSRST signal from the 20-pin Emulator header on your board must be
-pulled up (we suggest a 4.7 ohm pull-up) to the target voltage level
-required by your board’s power-up-reset circuit. You can then remotely
-through CCS apply a reset your target system from the Debug->Advance
-Reset->System Reset menu. The STSRST signal will be active for ~1
-millisecond.
-
-.. rubric:: Adapters
-   :name: adapters
-
-**This page is no longer maintained and is kept here for reference only!
-Please go to this
-`link <http://dev.ti.com/tirex/#/?link=Development%20Tools%2FDebug%20Probes%2FXDS%2FDocuments%2FJTAG%20Adapters>`__
-for the most current version.**
-
-.. rubric:: JTAG Adapter Overview
-   :name: jtag-adapter-overview
-
-There are two types of connectors:
-
-#. Emulator-This is the connector on the emulator/JTAG ICE/UIF/XDS unit
-#. Target-This is the connector on the target card
-
-Types of adapters:
-
-#. Pin Converters-Passive conversion of one connector type to another
-#. Adapter-Some active components for different purposes. Ex: Addition
-   of adaptive clocking, buffering of TCK/RTCK signals, Isolation, etc.
-
-.. rubric:: JTAG connectors cross reference
-   :name: jtag-connectors-cross-reference
-
-| TI Part Number, Link to product, or 3rd party product Number
-| **Note:** The table below only references adapters available by TI and
-  its direct third parties. It is possible to find other adapters for
-  sale from external companies.
-
-**Target connector**
-
-**10-pin ARM**
-
-**14-pin TI**
-
-**20-pin TI**
-
-**20-pin ARM**
-
-**60-pin TI**
-
-**60-pin MIPI**
-
-**microSD**
-
-**Emulator Connector**
-
-**10-pin ARM**
-
-N/A
-
-N/A
-
-N/A
-
-**`MDL-ADA2 <http://processors.wiki.ti.com/index.php/JTAG_Adapters#MDL-ADA2>`__**
-
-N/A
-
-N/A
-
-N/A
-
-**14-pin TI**
-
-N/A
-
-| **`TMDSADP1414-ISO <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADP1414-ISO>`__**\ :sup:`1`
-| **`TMDSADP1414 <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADP1414>`__**\ :sup:`2,3,4`
-| **701208**\ :sup:`2,7`
-| **701210**\ :sup:`2,3,4,7`
-
-| **`TMDSADP1420 <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADP1420>`__**\ :sup:`2,3,4`
-| **`TMDSADPEMU-20T <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADPEMU-20T>`__**\ :sup:`3`
-| **701212**\ :sup:`2,3,4,7`
-| **701219**\ :sup:`7`
-| **14e_TI-20t_cTI**\ :sup:`6`
-
-| **`TMDSADPEMU-20A <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADPEMU-20A>`__**\ :sup:`3`
-| **701280**\ :sup:`7`
-
-| **`TMDSADP1460 <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADP1460>`__**
-| **14e_TI-60t_TI**\ :sup:`6`
-
- **`701282 <http://www.spectrumdigital.com/product_info.php?cPath=33&products_id=264&osCsid=0275b43739c81e0cb6aae06df25ced81>`__**\ :sup:`7`
-
-N/A
-
-**20-pin TI**
-
-**selected emulators**\ :sup:`8,15`
-
-| **20e_cTI-14t_TI**\ :sup:`6`
-| **701218**\ :sup:`7`
-| **selected emulators**\ :sup:`8,9,10,11,12,15`
-
-N/A
-
-| **20e_cTI-20t_ARM**\ :sup:`6`
-| **selected emulators**\ :sup:`10,15`
-
-**20e_cTI-60t_TI**\ :sup:`6`
-
-N/A
-
-**701206**\ :sup:`7`
-
-**20-pin ARM**
-
-**`MDL-ADA2 <http://processors.wiki.ti.com/index.php/JTAG_Adapters#MDL-ADA2>`__**
-
-**LA-7748**\ :sup:`5`
-
-**`TMDSADPEMU-20T <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADPEMU-20T>`__**\ :sup:`3`
-
-**`TMDSADPEMU-20A <http://processors.wiki.ti.com/index.php/JTAG_Adapters#TMDSADPEMU-20A>`__**\ :sup:`3`
-
-N/A
-
-N/A
-
-N/A
-
-**60-pin TI**
-
-N/A
-
-**60e_TI-14t_TI**\ :sup:`6`
-
-N/A
-
-N/A
-
-**60e_TI-60t_TI**\ :sup:`6`
-
-N/A
-
-N/A
-
-**60-pin MIPI**
-
-N/A
-
-| **60e_MIPI-14t_TI**\ :sup:`6`
-| **selected emulators**\ :sup:`13,14`
-
-| **60e_MIPI-20t_cTI**\ :sup:`6`
-| **selected emulators**\ :sup:`13,14`
-
-| **60e_MIPI-20t_ARM**\ :sup:`6`
-| **selected emulators**\ :sup:`13,14`
-
-| **60e_MIPI-60t_TI**\ :sup:`6`
-| **selected emulators**\ :sup:`14`
-
-N/A
-
-N/A
-
-|
-| :sup:`1` Isolation adapter
-| :sup:`2` Voltage Translation
-| :sup:`3` RTCK Signal Boost
-| :sup:`4` Adaptive Clocking
-| :sup:`5` http://www.lauterbach.com/frames.html?order/ord__7748.html -
-  Code JTAG-ARM-CON-20-TI14
-| :sup:`6` http://www.blackhawk-dsp.com/products/PinConverters.aspx
-| :sup:`7` http://www.spectrumdigital.com/index_orig.php?cPath=33
-| :sup:`8` Bundled with `Blackhawk XDS100v2 Model
-  D <http://www.blackhawk-dsp.com/products/USB100v2D.aspx>`__
-| :sup:`9` Bundled with `Spectrum Digital
-  XDS100v3 <http://www.spectrumdigital.com/product_info.php?cPath=22&products_id=251>`__
-| :sup:`10` Bundled with Spectrum Digital
-  `XDS200 <http://www.spectrumdigital.com/product_info.php?cPath=22&products_id=261>`__
-  and
-  `XDS220 <http://www.spectrumdigital.com/product_info.php?cPath=22&products_id=260>`__
-  emulators
-| :sup:`11` Bundled with Blackhawk XDS560 emulators:
-  `BP <http://www.blackhawk-dsp.com/products/USB560BP.aspx>`__ (only 20
-  TI to 14 TI),
-  `m <http://www.blackhawk-dsp.com/products/USB560.aspx>`__,
-  `LAN <http://www.blackhawk-dsp.com/products/LAN560.aspx>`__,
-  `PCI <http://www.blackhawk-dsp.com/products/PCI560.aspx>`__.
-| :sup:`12` Bundled with `Spectrum Digital XDS560v2 LC
-  Traveler <http://www.spectrumdigital.com/product_info.php?products_id=254>`__
-  and `Spectrum Digital XDS560v2 STM
-  Traveler <http://www.spectrumdigital.com/product_info.php?cPath=22&products_id=249>`__
-| :sup:`13` Bundled with `Blackhawk
-  USB560v2 <http://www.blackhawk-dsp.com/products/USB560v2.aspx>`__
-| :sup:`14` Bundled with `Blackhawk
-  XDS560v2 <http://www.blackhawk-dsp.com/products/XDS560v2.aspx>`__ and
-  `Spectrum Digital XDS560v2 STM with target
-  adapters <http://www.spectrumdigital.com/product_info.php?cPath=22&products_id=236>`__
-| :sup:`15` Bundled with `Blackhawk
-  XDS200 <http://store.blackhawk-dsp.com/default/usb200-jtag-emulator-1.html>`__
-  emulators
-
-Part numbers:
-=============
-
-TMDSADP1414
------------
-
-| Product page:
-  http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/TMDSADP1414.jpg
-
-.. raw:: html
-
-   </div>
-
-|
-
-TMDSADP1414-ISO
----------------
-
-| Product page:
-  http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/TMDSADP1414-ISO.jpg
-
-.. raw:: html
-
-   </div>
-
-|
-
-TMDSADP1420
------------
-
-| Product page:
-  http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/TMDSADP1420.jpg
-
-.. raw:: html
-
-   </div>
-
-|
-
-TMDSADP1460
------------
-
-| Product page:
-  http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/TMDSADP1460.jpg
-
-.. raw:: html
-
-   </div>
-
-|
-
-TMDSADPEMU-20A
---------------
-
-| Product page:
-  http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/TMDSADPEMU-20A.png
-
-.. raw:: html
-
-   </div>
-
-|
-
-TMDSADPEMU-20T
---------------
-
-| Product page:
-  http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/TMDSADPEMU-20T.png
-
-.. raw:: html
-
-   </div>
-
-|
-
-MDL-ADA2
---------
-
-| Replica of the old Luminary product page at
-  `Digi-key <http://media.digikey.com/pdf/Data%20Sheets/Texas%20Instruments%20PDFs/MDL-ADA2.pdf>`__
-  and at `Farnell <http://www.farnell.com/datasheets/1520171.pdf>`__
-
-.. raw:: html
-
-   <div class="floatnone">
-
-.. Image:: /images/MDL-ADA2_cables.jpg
-
-.. raw:: html
-
-   </div>
-
-|
-
-|
-
-|
-
---------------
-
-Frequently Asked Questions
-==========================
-
-Q: I have an XDS560 right now, but it is an older one (ex: XDS560 v1 but not revision D). How do I upgrade my XDS560 cable to gain the additional features such as wait in reset, additional connection types, etc. (i.e. revison D)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
--  A: You can order from TI distributors the part number: TMDSCBL560
-   (6/18/2010: This product is no longer available. You may be able to
-   order one from Blackhawk)
--  A: Recommend you contact your XDS560 manufacturer and determine what
-   upgrade options are available.
-
-Q: What if I want to use the XDS560 Trace capability to collect trace from the pins?
-------------------------------------------------------------------------------------
-
--  A: You will need the XDS560 Trace unit. There are more details here:
-   `XDS560 Trace <http://processors.wiki.ti.com/index.php/XDS560_Trace>`__
-
-Q: Do any XDS560-class Emulators support Linux Operating Systems?
------------------------------------------------------------------
-
--  A: Yes. Starting with CCS v5, the following Blackhawk models support
-   operation on Linux:
-
-**LAN560** (BH-LAN-560), **USB560-M** (BH-USB-560m), **USB560-BP**
-(BH-USB-560bp), **USB560** (BH-USB-560)
-
-For XDS560v2 models, see `XDS560v2 System
-Trace <http://processors.wiki.ti.com/index.php/XDS560v2_System_Trace>`__
-
-Q: Does the XDS560 support ARM Adaptive clocking?
--------------------------------------------------
-
--  A: Yes, any XDS560 which is Revision D and above supports adaptive
-   clocking. See: `Adaptive Clocking <http://processors.wiki.ti.com/index.php/Adaptive_Clocking>`__
-   for details on Adaptive Clocking.
--  A: For CCSv3.3 with Service Release 12 and above, you can setup for
-   adaptive clocking as in the photo below:
-
-.. Image:: /images/Ccsv33adaptive.jpg
-
--  A: For CCS v4.x, you can setup adaptive clocking as in the photo
-   below:
-
-.. Image:: /images/Ccsv4adaptive.jpg
-
-Q: What is the difference between `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ and XDS560?
-----------------------------------------------------------------------------
-
--  A: XDS560 is capable of `High Speed RTDX
-   (HSRTDX) <http://processors.wiki.ti.com/index.php/High_Speed_RTDX_(HSRTDX)>`__, essentially it has
-   the same functionality of an `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ class
-   emulator but is significantly faster, with data rates of over 2MBps.
-
-Q: Where to get an XDS560
--------------------------
-
--  XDS560 are available from `TI E-store <http://www.ti.com/xds560>`__.
--  Embest's TDS560 plus
-   `Here <http://www.timll.com/chinese/product/TDS560.asp>`__.
--  Ashling's Opella-XDS560
-   `here <http://ashling.com/index.php?option=com_content&task=view&id=326>`__.
-
-Q: Problems with XDS560.sys Loading
------------------------------------
-
--  A: While working with CCS emulation (Blackhawk) setup, receives error
-   stating TMS320C62XX" is not supported. It is because "XDS560.SYS" was
-   not loading correctly.
-
-There are two versions of xds560.sys in the system. Version A and
-Version B
-
-Version A: c:\winnt\system32\xds560.sys Version B:
-c:\winnt\system32\drivers\xds560.sys
-
-The system actually looks in the second location for the driver, but
-this version (B) can hang at boot time. Sometimes the xds560.inf file
-may not copy the correct files from/to the appropriate directories.
-Rather than edit xds560.inf, the workaround is to create a dummy
-directory c:\winnt\system32\drivers\Win2000_XP and put the working (A)
-version of the file in it. Then the New Hardware Found dialogue runs to
-completion and copies the correct file to the correct directory.
-
-Q: I have a Blackhawk XDS560 USB/Lan560. What does the LED indicate?
---------------------------------------------------------------------
-
--  A: On the USB560m/LAN560, the USB LED is bi-color (red and green).
-   This is the same for the USB560bp LED on the end panel.
-
-Start-up: Power-up: RED Enumeration Complete: GREEN
-
-|
-| In operation, USB status: Ready: GREEN Busy: RED
-
-Q: My JTAG is not working with CCS...
--------------------------------------
-
--  A: Please check: `Debugging JTAG Connectivity
-   Problems <http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems>`__
-
-Q: Are there lower cost options?
---------------------------------
-
--  A: Yes, Please see `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__ and
-   `XDS100 <http://processors.wiki.ti.com/index.php/XDS100>`__
--  Ashling's Opella-XDS560
-   `here <http://ashling.com/index.php?option=com_content&task=view&id=326>`__
-   is less than $1500.
-
-Q: Why does my Windows Device Manager show a warning for the TI XDS560 PCI Emulator?
-------------------------------------------------------------------------------------
-
-.. Image:: /images/560pcierror.jpg
-
--  A: The Windows Device Manager is showing this error because a TI
-   XDS560 PCI emulator is not installed. Windows cannot start the driver
-   because the hardware is not installed in the PC. If you are NOT using
-   this hardware emulator, then there is no issue and other emulators
-   are not affected.
-
-Q: I am a TI 3rd party, and I want to create my own XDS510. What do I do?
--------------------------------------------------------------------------
-
--  A: Approved, TI 3rd parties can purchase an `Emulation Porting
-   Kit <http://processors.wiki.ti.com/index.php/Emulation_Porting_Kit>`__
-
-Q: How do I get looback in a TI XDS560 Rev D cable to work?
------------------------------------------------------------
-
--  A: You will need to fix the connection XML file or as an extra board
-   config file. You will need to insert one of the following
-   combinations depending on what you are doing. (Note, this is not
-   tested extensively.)
--  A: This has been filed as an enhancement request (SDSCM00036610) for
-   a fix in a future release.
-
-::
-
-    # This combination loops the TCLKO/TCKI signals in the pod – the timing between return data and clock is modified.
-    # DBGJTAG handles this OK if the target provides compatible return data timing.
-    # CCS drivers won’t will handle this OK if the target provides compatible return data timing.
-    # The XDS560 Trace pod also comprehends this combination and uses it with specific targets.
-    loopback_mode=enable
-    loopback_value=clock
-
-    # this combination loops the TDI/TDO signals in the pod – the IR/DR scan-paths become 0-bits long
-    # DBGJTAG handles this OK.
-    # CCS drivers fail – they won’t find the target DSP/ARM/icepick
-    loopback_mode=enable
-    loopback_value=data
-
-    # This combination loops the TDI/TDO and TCLKO/TCKI signals in the pod and disables the cable-break/power-loss detection.
-    # The intention is to allow DBGJTAG to run emulator and cable tests even when the cable is not connected to any target al all.
-    # DBGJTAG handles this OK.
-    # CCS drivers fail – they won’t find the target DSP/ARM/icepick
-    loopback_mode=enable
-    loopback_value=total
-
-    # this combination does nothing
-    loopback_mode=disable
-    loopback_value=disable
-
-Q: How do I get loopback in a Blackhawk XDS560 with a 20 pin cable (Rev D) cable to work?
------------------------------------------------------------------------------------------
-
--  In CCS v4.x, you need to select the loopback option.
-
-.. Image:: /images/Bh560m-revd-loopbackenable.jpg
-
-Q: Can I use Boundary Scan with XDS560?
----------------------------------------
-
--  Corelis has software which works with Blackhawk XDS560. See
-   `here <http://blackhawk-dsp.com/boundaryscan.aspx>`__
-
-Q: Is RTDX supported with C2000 processors on the XDS560?
----------------------------------------------------------
-
--  No
-
-Related
-=======
-
--  `XDS100 <http://processors.wiki.ti.com/index.php/XDS100>`__
--  `XDS510 <http://processors.wiki.ti.com/index.php/XDS510>`__
--  `XDS560v2 System Trace <http://processors.wiki.ti.com/index.php/XDS560v2_System_Trace>`__
--  `XDS560 Trace <http://processors.wiki.ti.com/index.php/XDS560_Trace>`__
diff --git a/source/rtos/_Boot.rst b/source/rtos/_Boot.rst
deleted file mode 100644
index d6c2ebfd6..000000000
--- a/source/rtos/_Boot.rst
+++ /dev/null
@@ -1,114 +0,0 @@
-Overview
-==========
-
-This page provides an overview about the Secondary Bootloader support
-provided in Processor SDK RTOS.
-
-The Secondary Bootloader (SBL) sets-up the PLL clocks, powers on the
-I/O Peripherals, initializes the DDR, loads the application image into
-DDR & brings the target cores for applicable SOCs out of reset.
-Additional details including execution boot flow is covered in more
-elaborate detail under individual SOC section.
-
-Boot Modes
-============
-
-MMCSD
----------
-
-MMCSD bootloader is required to boot target using an SD card containing
-bootloader and application images. When the board is powered ON the ROM
-bootloader detects the MMCSD bootloader image and loads it to the
-internal memory.The bootloader initializes the board, copies the
-application image from SD card to the DDR memory and gives control to
-the application.
-
-QSPI
-------
-
-A flash device interfaced with QSPI is flashed with QSPI bootloader and
-application images. When the board is powered ON the ROM bootloader
-detects the bootloader image from flash device and loads it to the
-internal memory. The Bootloader initializes the board, copies the
-application image from QSPI device to the DDR memory and gives control
-to the application.
-
-UART
------
-
-A Serial connection is used for transferring the bootloader binary from
-PC to target board through XMODEM protocol. The bootloader on execution
-prompts for application image to transfer through XMODEM. On providing
-the path, the application binary is transferred through serial
-connection to DDR memory and the control is passed to application to
-execute.
-
-MCSPI/SPI
------------
-
-A SPI flash device flashed with MCSPI/SPI bootloader and application
-images is used for booting the board. When the board is powered ON the
-ROM bootloader detects the bootloader image from flash device and loads
-it to the internal memory. The Bootloader initializes the board, copies
-the application image from flash to the DDR memory and gives control to
-the application.
-
-NAND
--------
-
-NAND flash with bootloader and and application images is used for
-booting the board. When the board is powered ON the ROM bootloader
-detects the bootloader image from flash device and loads it to the
-internal memory. The bootloader initializes the board, copies the
-application image from flash to the DDR memory and gives control to the
-application.
-
-.. note::
-    For information on boot mode setting, see the applicable :ref:`EVM Hardware User Guide <RTOS-SDK-Supported-Platforms>`
-
-
-Platforms
-==============
-
-AM335x/AM437x
----------------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM335x_AM437x.rst
-
-
-AM57x
----------------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM57x.rst
-
-AM65x/J721E
----------------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_AM65x_J721E.rst
-
-C66x
----------------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_C66x.rst
-
-
-K2G
----------------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2G.rst
-
-
-K2H/K2E/K2L
----------------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_K2H_E_L.rst
-
-
-OMAPL137/OMAPL138/C6748
--------------------------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_BOOT_OMAPL13x.rst
-
-
-Bootloader Debugging
-========================
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Boot_Debug.rst
-
-UART AppLoader
-========================
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_UART_Apploader.rst
-
-.. raw:: html
diff --git a/source/rtos/_MPM.rst b/source/rtos/_MPM.rst
deleted file mode 100644
index cf43cdbd6..000000000
--- a/source/rtos/_MPM.rst
+++ /dev/null
@@ -1,40 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/MultiprocMgr
-
-.. rubric:: Introduction
-   :name: introduction
-
-| The Multiple Proc Manager (MPM) Package distributed with Processor SDK
-  RTOS installer has multiple software modules.
-| Broadly the modules can be grouped into two categories:
-
--  Multi Proc Manager Linux module
--  Modules that facilitate Interprocess communication between the
-   multiple cores.
-
-.. rubric:: Multi Proc Manager Linux module
-   :name: multi-proc-manager-linux-module
-
-The Multi Proc Manager Linux module is used to load and run DSP images
-from ARM Linux user space. The download and run operations can be
-exercised by using user space API calls. MPM also provides a MPM Client
-Application which can be used to load and run DSP through command line.
-
-.. rubric:: Interprocessor Communication related packages
-   :name: interprocessor-communication-related-packages
-
-The Multi Proc Manager package also includes couple of software modules
-that facilitates Inter processor communication between ARM running linux
-and DSP running RTOS. These components provide APIs in both ARM linux as
-well as on DSP RTOS.
-
-.. rubric:: MPM Mailbox module
-   :name: mpm-mailbox-module
-
-Mailbox is used for exchanging control messages between the host and
-individual DSP cores.
-
-.. rubric:: MPM Sync module
-   :name: mpm-sync-module
-
-Sync Module implements support for Multicore Barriers and Locks.
-
diff --git a/source/rtos/_NDK.rst b/source/rtos/_NDK.rst
deleted file mode 100644
index 50804721e..000000000
--- a/source/rtos/_NDK.rst
+++ /dev/null
@@ -1,987 +0,0 @@
-===============================================
-Processor SDK RTOS NDK - Texas Instruments Wiki
-===============================================
-
-.. raw:: html
-
-   <div id="mw-page-base" class="noprint">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="mw-head-base" class="noprint">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="content" class="mw-body" role="main">
-
-.. raw:: html
-
-   <div id="siteNotice">
-
-.. raw:: html
-
-   <div id="localNotice" lang="en" dir="ltr">
-
-|
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div class="mw-indicators">
-
-.. raw:: html
-
-   </div>
-
-.. rubric:: Processor SDK RTOS NDK
-   :name: firstHeading
-   :class: firstHeading
-
-.. raw:: html
-
-   <div id="bodyContent" class="mw-body-content">
-
-.. raw:: html
-
-   <div id="siteSub">
-
-From Texas Instruments Wiki
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="contentSub">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="jump-to-nav" class="mw-jump">
-
-Jump to: `navigation <#mw-head>`__, `search <#p-search>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="mw-content-text" class="mw-content-ltr" lang="en" dir="ltr">
-
-.. raw:: html
-
-   <div class="hf-nsheader">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div class="hf-header">
-
-.. raw:: html
-
-   </div>
-
-|
-
-+-----------------------+-----------------------+-----------------------+
-| `RTOS Software        | →                     | Networking            |
-| Developer             |                       |                       |
-| Guide </index.php/Pro |                       |                       |
-| cessor_SDK_RTOS_Softw |                       |                       |
-| are_Developer_Guide>` |                       |                       |
-| __                    |                       |                       |
-+-----------------------+-----------------------+-----------------------+
-
-|
-
-|
-
-+-------------------------------------------------+-----------------------------------+
-| .. rubric:: **Overview**                        | .. rubric:: **User Interface**    |
-|    :name: overview                              |    :name: user-interface          |
-|                                                 |                                   |
-| - `NDK Overview </index.php/Processor           |                                   |
-|   _SDK_RTOS_NDK#NDK_Overview>`__                |                                   |
-| - `NIMU Transport </index.php/Processo          |                                   |
-|   r_SDK_RTOS_NDK#NIMU_Transport>`__             |                                   |
-|                                                 |                                   |
-|   - `NIMU for                                   |                                   |
-|     CPSW </index.php/Processor_                 |                                   |
-|     SDK_RTOS_NDK#NIMU_FOR_CPSW>`__              |                                   |
-|                                                 |                                   |
-|   - `NIMU for                                   |                                   |
-|     ICSS </index.php/Processor_                 |                                   |
-|     SDK_RTOS_NDK#NIMU_FOR_ICSS>`__              |                                   |
-|                                                 |                                   |
-| - `Additional Documentation                     |                                   |
-|   References </index.php/Process                |                                   |
-|   or_SDK_RTOS_NDK#Additional_Docume             |                                   |
-|   ntation_References>`__                        |                                   |
-|                                                 |                                   |
-+-------------------------------------------------+-----------------------------------+
-| .. rubric:: **Application**                     | .. rubric:: **Debug**             |
-|    :name: application                           |    :name: debug                   |
-|                                                 |                                   |
-| - `Examples </index.php/Processo                | - `FAQ </index.php/Processor_SDK  |
-|   r_SDK_RTOS_NDK#Examples>`__                   |   _RTOS_NDK#FAQ>`__               |
-|                                                 |                                   |
-|    - `PING Example </index.php/Process          |                                   |
-|      or_SDK_RTOS_NDK#PING_Example>`__           |                                   |
-|                                                 |                                   |
-|    - `CCLink Example </index.php/Process        |                                   |
-|      or_SDK_RTOS_NDK#CCLink_Example>`_          |                                   |
-|                                                 |                                   |
-+-------------------------------------------------+-----------------------------------+
-
-.. rubric:: NDK Overview
-   :name: ndk-overview
-
-The Network Development Kit (NDK) is a platform for development and
-demonstration of network enabled RTOS applications on TI processors and
-includes demonstration software showcasing capabilities across a range
-of network enabled applications. The NDK serves as a rapid prototype
-platform for the development of network and packet processing
-applications, or to add network connectivity to existing applications
-for communications, configuration, and control. Using the components
-provided in the NDK, developers can quickly move from development
-concepts to working implementations attached to the network.
-
-The NDK provides an IPv6 and IPv4 compliant TCP/IP stack working with
-the TI-RTOS Kernel real-time operating system. Its primary focus is on
-providing the core Layer 3 and Layer 4 stack services along with
-additional higher-level network applications such as HTTP server and
-DHCP.
-
-| The NDK itself does not include any platform or device specific
-  software. The NDK interfaces through well-defined transport interface,
-  Network Interface Management UNIT(NIMU) to the PDK and platform
-  software elements needed for operation. NIMU support. NIMU provides an
-  interface between the stack and the device drivers through which the
-  stack can talk to multiple instances of a single or various device
-  drivers concurrently.
-
-**Network Development Kit Summary**
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-**Component Type**
-
-Library
-
-**Install Package**
-
-NDK
-
-**Install Directory**
-
-ndk_<version>\packages\ti\ndk
-
-**Project Type**
-
-`Eclipse RTSC <http://www.eclipse.org/rtsc/>`__
-
-**Endian Support**
-
-Little
-
-**Library Name**
-
-For details of the libraries delivered as part of the NDK component,
-please refer to `[1] <http://www-s.ti.com/sc/techlit/spru523.pdf>`__
-
-**Library Path**
-
-$(NDK_INSTALL_DIR)\packages\ti\ndk
-
-**Include Paths**
-
-| NDK_INSTALL_DIR is set automatically by CCS based on the version of
-  NDK you have checked to build with.
-
-| ${NDK_INSTALL_DIR}\packages\ti\ndk\inc
-| ${NDK_INSTALL_DIR}\packages\ti\ndk\inc\tools
-
-|
-
-NIMU Transport
-==============
-
-| The NDK transport component of the PDK currently provided 2
-  implementations for the NIMU layer as described in the sections below.
-  The following diagram is a high level depiction of the NDK/NIMU
-  architecture with reference to the NIMU implementations. For details
-  for the NDK/NIMU architecture, please refer to NDK Programmer's
-  Reference Guide `[2] <http://www-s.ti.com/sc/techlit/spru524.pdf>`__
-| |NDK ARCH.png|
-
-NIMU for CPSW
--------------
-
-NIMU for CPSW provides a common CPSW interface library for NDK to
-communicate with when network stack is being implemented in the TI's
-Common Platform Ethernet Switch for ethernet packet processing. The
-library uses the CSL-R based API interfaces to provide NIMU interface
-for NDK. This package has NDK unit test examples for all supported EVMS
-as indicated in the table above.
-
-| **Note**: This module is only intended to be used with NDK. As such,
-  users should not tie up to its API directly.
-
-**NIMU for CPSW Summary**
-
-**Component Type**
-
-Library
-
-**Install Package**
-
-PDK
-
-**Install Directory**
-
-$(TI_PDK_INSTALL_DIR)\packages\ti\transport\ndk\nimu
-
-**Project Type**
-
-`Eclipse RTSC <http://www.eclipse.org/rtsc/>`__
-
-**Endian Support**
-
-Little
-
-**Library Path**
-
-$(TI_PDK_INSTALL_DIR)\packages\ti\transport\ndk\nimu\lib
-
-**Reference Guides**
-
-None
-
-|
-
-NIMU for ICSS
--------------
-
-NIMU for ICSS (PRU-ICSS is Programmable Real-Time Unit Industrial
-Communications Subsystem) provides a common PRU-ICSS interface library
-for NDK to communicate with when network stack is being implemented in
-the PRU-ICSS subsytem for ethernet packet processing (firmware based
-switch running on PRU's which are part of the ICSS). The library used
-the ICSS_EMAC LLD to provide NIMU interface for NDK. This package has
-NDK unit test examples for all supported Devices as indicated in the
-table above. For details of the PRU-ICSS, please refer to
-`ICCS-EMAC <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_ICSS-EMAC>`__.
-
-| **Note**: This module is only intended to be used with NDK and
-  requires ICSS-EMAC low level driver. As such, users should not tie up
-  to its API directly.
-
-**NIMU for ICSS Summary**
-
-**Component Type**
-
-Library
-
-**Install Package**
-
-PDK
-
-**Install Directory**
-
-$(TI_PDK_INSTALL_DIR)\packages\ti\transport\ndk\nimu_icss
-
-**Project Type**
-
-`Eclipse RTSC <http://www.eclipse.org/rtsc/>`__
-
-**Endian Support**
-
-Little
-
-**Library Path**
-
-$(TI_PDK_INSTALL_DIR)\packages\ti\transport\ndk\nimu_icss\lib
-
-**Reference Guides**
-
-None
-
-|
-
-Examples
-========
-
-PING Example
-------------
-
-All NDK examples using CPSW interface can be found at the following
-location:
-
--  $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu/example
-
-All NDK examples using PRU-ICSS interface can be found at the following
-location:
-
--  $(TI_PDK_INSTALL_DIR)/packages/ti/transport/ndk/nimu_icss/example
-
-Building the NDK examples
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-| Use pdkProjectCreate.sh for Linux environment or pdkProjectCreate.bat
-  for Windows.
-| This can be found under the <PDK>/packages folder. The only
-  modification to these scripts, if any, is to update the
-  CCS_INSTALL_PATH variable to point to CCS location if its not in the
-  c:\ti\ccsv6 directory . Please refer to `Rebuilding
-  PDK <http://processors.wiki.ti.com/index.php/Rebuilding_The_PDK>`__ for details of example project
-  creation and how to run the example projects using CCS.
-
-NDK Example Description
-~~~~~~~~~~~~~~~~~~~~~~~
-
-For each EVM Type supported, there is a example which demonstates "ping"
-use case. Once the application is loaded via CCS and run, you will be
-able to ping the configured IP address as specificed int he examples
-config file. For example, the config file for NIMU for CPSW for
-idkAM572x, can be found in
-ti/transport/ndk/nimu/example/am572x/armv7/bios/nimu_idk.cfg. If you
-wish to re-configure the IP address of the CPSW interface you will need
-to modify the following configuration parameters
-
--  Ip.address = "new ip address"
--  Ip.mask = "new ip mask"
--  Ip.gatewayIpAddr = "new gatewayIpAddr"
-
-| If you you do change these settings, you will be required to re-build
-  the Example Project using CCS.
-
-+-----------------+-----------------+-----------------+-----------------+
-| Name            | Description     | EVM             | Expected        |
-|                 |                 | Configuration   | Results         |
-+=================+=================+=================+=================+
-| NIMU_BasicExamp | | Example       | | icev2AM335x:  | | Run ping from |
-| le_evmXXXX_armE |   demonstrates  |   Jumpers J18   |   any other PC  |
-| xampleproject   |   ping from     |   and J19 need  |   in the same   |
-|                 |   external      |   to be set     |   subnet        |
-|                 |   source to     |   properly to   |                 |
-|                 |   Gigabit       |   select CPSW   | Ping response   |
-|                 |   Ethernet port |   or ICSS mode. | from the EVM    |
-|                 |   on EVM.       |                 | verifies        |
-|                 |                 | | Pin2 and Pin3 | successful      |
-|                 |                 |   need to be    | execution of    |
-|                 |                 |   connected for | example.        |
-|                 |                 |   ICSS mode and |                 |
-|                 |                 |   Pin1 and Pin2 |                 |
-|                 |                 |   for CPSW      |                 |
-|                 |                 |   mode.         |                 |
-|                 |                 |                 |                 |
-|                 |                 | Update \*.cfg   |                 |
-|                 |                 | file with       |                 |
-|                 |                 | static IP to    |                 |
-|                 |                 | test. NIMU for  |                 |
-|                 |                 | CPSW test Tests |                 |
-|                 |                 | requires        |                 |
-|                 |                 | connection of   |                 |
-|                 |                 | configured      |                 |
-|                 |                 | Ethernet port   |                 |
-|                 |                 | under test to   |                 |
-|                 |                 | external PC on  |                 |
-|                 |                 | same subnet.    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-| NIMU_ICSS_Basic | | Example       | | icev2AM335x:  | Run ping from   |
-| Example_evmXXXX |   demonstrates  |   Jumpers J18   | any other PC in |
-| _armExampleproj |   ping from     |   and J19 need  | the same subnet |
-| ect             |   external      |   to be set     |                 |
-|                 |   source to     |   properly to   | Ping response   |
-|                 |   PRU-ICSS      |   select CPSW   | from the EVM    |
-|                 |   Ethernet port |   or ICSS mode. | verifies        |
-|                 |   on EVM.       |                 | successful      |
-|                 |                 | | Pin2 and Pin3 | execution of    |
-|                 |                 |   need to be    | example.        |
-|                 |                 |   connected for |                 |
-|                 |                 |   ICSS mode and |                 |
-|                 |                 |   Pin1 and Pin2 |                 |
-|                 |                 |   for CPSW      |                 |
-|                 |                 |   mode.         |                 |
-|                 |                 |                 |                 |
-|                 |                 | Update \*.cfg   |                 |
-|                 |                 | file with       |                 |
-|                 |                 | static IP to    |                 |
-|                 |                 | test. NIMU for  |                 |
-|                 |                 | CPSW test Tests |                 |
-|                 |                 | requires        |                 |
-|                 |                 | connection of   |                 |
-|                 |                 | configured      |                 |
-|                 |                 | PRU-ICSS        |                 |
-|                 |                 | Ethernet port   |                 |
-|                 |                 | under test to   |                 |
-|                 |                 | external PC on  |                 |
-|                 |                 | same subnet.    |                 |
-+-----------------+-----------------+-----------------+-----------------+
-
-|
-
-Running NDK example on ARM core of Keystone II devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Before running the NDK example on ARM core of Keystone II
-devices(K2H/L/E/G), the following steps need to be performed.
-
--  Increase the NS_BootTask stack from 2048 to 4096 in netctrl.c:
-
-::
-
-    TaskCreate( NS_BootTask, "ConfigBoot", OS_TASKPRINORM, 4096,(UINT32)hCfg, 0, 0 );
-
--  Rebuild the NDK
--  Rebuild NIMU driver
-
-|
-
-CCLink Example
---------------
-
-Refer
-`Processor_SDK_RTOS_CCLINK <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_CCLINK>`__ for
-details on steps for running cclink controller and device examples on NDK.
-
-FAQ
----
-
-How to check which versions of NIMU driver is for my SOC?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There are several versions of NIMU driver for different SOCs. Please
-check packages\ti\transport\ndk\nimu\build\makefile.mk
-
--  V0: C6657
--  V1: C6678
--  V2: K2H, K2K
--  V3: K2L, K2E
--  V4: AM572x, AM571x, AM437x, AM335x
--  V5: K2G
-
-Is there any multicast streams limitation using the NDK?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In the NDK, the limit is defined by a macro at ti/ndk/stack/igmp/igmp.c:
-#define IGMP_MAX_GROUP 32 It is then used to create an array of IGMP
-records: static IGMP_REC igmp[IGMP_MAX_GROUP]; The IGMP_MAX_GROUP value
-can be increased, then rebuild the NDK stack.
-
-Additional Documentation References
-===================================
-
-+-----------------------------------+-----------------------------------+
-| **Document**                      | **Location**                      |
-+-----------------------------------+-----------------------------------+
-| NDK Programmer's Reference Guide  | http://www-s.ti.com/sc/techlit/sp |
-|                                   | ru524.pdf                         |
-+-----------------------------------+-----------------------------------+
-| NDK User's Guide                  | http://www-s.ti.com/sc/techlit/sp |
-|                                   | ru523.pdf                         |
-+-----------------------------------+-----------------------------------+
-| Network Developers Kit FAQ        | http://processors.wiki.ti.com/ind |
-|                                   | ex.php/Network_Developers_Kit_FAQ |
-+-----------------------------------+-----------------------------------+
-| NDK Support Package Ethernet      | http://www-s.ti.com/sc/techlit/sp |
-| Driver Design Guide               | rufp2.pdf                         |
-+-----------------------------------+-----------------------------------+
-| Rebuilding_the_NDK_Core           | http://processors.wiki.ti.com/ind |
-| Rebuilding NDK Core               | ex.php/Rebuilding_the_NDK_Core    |
-+-----------------------------------+-----------------------------------+
-
-.. raw:: html
-
-   <div class="hf-footer">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div class="hf-nsfooter">
-
-.. list-table::
-
-   * - |E2e.jpg|
-
-     - For technical support please post your questions at http://e2e.ti.com.
-       Please post only comments about the article **Processor SDK RTOS NDK**
-       here.
-
-|Hyperlink blue.png|
-
-.. raw:: html
-
-   </div>
-
-**Links**
-
-.. list-table::
-
-   * - `Amplifiers & Linear
-       <http://www.ti.com/lsds/ti/analog/amplifier_and_linear.page>`_
-
-     -
-
-        - `Audio <http://www.ti.com/lsds/ti/analog/audio/audio_overview.page>`_
-
-        - `Broadband RF/IF & Digital Radio
-          <http://www.ti.com/lsds/ti/analog/rfif.page>`_
-
-        - `Clocks & Timers
-          <http://www.ti.com/lsds/ti/analog/clocksandtimers/clocks_and_timers.page>`_
-
-        - `Data Converters
-          <http://www.ti.com/lsds/ti/analog/dataconverters/data_converter.page>`_
-
-   * - `DLP & MEMS <http://www.ti.com/lsds/ti/analog/mems/mems.page>`_
-
-     -
-
-        - `High-Reliability
-          <http://www.ti.com/lsds/ti/analog/high_reliability.page>`__
-
-        - `Interface <http://www.ti.com/lsds/ti/analog/interface/interface.page>`__
-
-        - `Logic <http://www.ti.com/lsds/ti/logic/home_overview.page>`__
-
-        - `Power Management
-          <http://www.ti.com/lsds/ti/analog/powermanagement/power_portal.page>`__
-
-   * - `Processors <http://www.ti.com/lsds/ti/dsp/embedded_processor.page>`__
-
-     -
-
-        - `ARM Processors <http://www.ti.com/lsds/ti/dsp/arm.page>`__
-
-        - `Digital Signal Processors (DSP)
-          <http://www.ti.com/lsds/ti/dsp/home.page>`__
-
-        - `Microcontrollers (MCU)
-          <http://www.ti.com/lsds/ti/microcontroller/home.page>`__
-
-        - `OMAP Applications Processors
-          <http://www.ti.com/lsds/ti/omap-applications-processors/the-omap-experience.page>`__
-
-   * - `Switches & Multiplexers
-       <http://www.ti.com/lsds/ti/analog/switches_and_multiplexers.page>`__
-
-     -
-
-        - `Temperature Sensors & Control ICs
-          <http://www.ti.com/lsds/ti/analog/temperature_sensor.page>`__
-
-        - `Wireless Connectivity
-          <http://focus.ti.com/wireless/docs/wirelessoverview.tsp?familyId=2003&sectionId=646&tabId=2735>`__
-
-
-.. raw:: html
-
-   <div id="tiPrivacy">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div class="printfooter">
-
-Retrieved from
-"http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_NDK&oldid=232568"
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="catlinks" class="catlinks">
-
-.. raw:: html
-
-   <div id="mw-normal-catlinks" class="mw-normal-catlinks">
-
-`Category <http://processors.wiki.ti.com/index.php/Special:Categories>`__:
-
--  `PROCESSOR-SDK <http://processors.wiki.ti.com/index.php/Category:PROCESSOR-SDK>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div class="visualClear">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="mw-navigation">
-
-.. rubric:: Navigation menu
-   :name: navigation-menu
-
-.. raw:: html
-
-   <div id="mw-head">
-
-.. raw:: html
-
-   <div id="p-personal" role="navigation"
-   aria-labelledby="p-personal-label">
-
-.. rubric:: Personal tools
-   :name: p-personal-label
-
--  `Log in
-  <http://processors.wiki.ti.com/index.php?title=Special:UserLogin&returnto=Processor+SDK+RTOS+NDK>`__
-
--  `Request account
-  <http://processors.wiki.ti.com/index.php/Special:RequestAccount>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="left-navigation">
-
-.. raw:: html
-
-   <div id="p-namespaces" class="vectorTabs" role="navigation"
-   aria-labelledby="p-namespaces-label">
-
-.. rubric:: Namespaces
-   :name: p-namespaces-label
-
--  `Page <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_NDK>`__
-
--  `Discussion
-  <http://processors.wiki.ti.com/index.php?title=Talk:Processor_SDK_RTOS_NDK&action=edit&redlink=1>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="p-variants" class="vectorMenu emptyPortlet"
-   role="navigation" aria-labelledby="p-variants-label">
-
-.. rubric:: Variants\ ` <#>`__
-   :name: p-variants-label
-
-.. raw:: html
-
-   <div class="menu">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="right-navigation">
-
-.. raw:: html
-
-   <div id="p-views" class="vectorTabs" role="navigation"
-   aria-labelledby="p-views-label">
-
-.. rubric:: Views
-   :name: p-views-label
-
-- `Read <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_NDK>`__
-
-- `View source
-  <http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_NDK&action=edit>`__
-
-- `View history
-  <http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_NDK&action=history>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="p-cactions" class="vectorMenu emptyPortlet"
-   role="navigation" aria-labelledby="p-cactions-label">
-
-.. rubric:: More\ ` <#>`__
-   :name: p-cactions-label
-
-.. raw:: html
-
-   <div class="menu">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="p-search" role="search">
-
-.. rubric:: Search
-   :name: search
-
-.. raw:: html
-
-   <div id="simpleSearch">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="mw-panel">
-
-.. raw:: html
-
-   <div id="p-logo" role="banner">
-
-`<http://processors.wiki.ti.com/index.php/Main_Page>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="p-navigation" class="portal" role="navigation"
-   aria-labelledby="p-navigation-label">
-
-.. rubric:: Navigation
-   :name: p-navigation-label
-
-.. raw:: html
-
-   <div class="body">
-
-- `Main Page <http://processors.wiki.ti.com/index.php/Main_Page>`__
-
-- `All pages <http://processors.wiki.ti.com/index.php/Special:AllPages>`__
-
-- `All categories http://processors.wiki.ti.com/index.php/Special:Categories>`__
-
-- `Recent changes
-  http://processors.wiki.ti.com/index.php/Special:RecentChanges>`__
-
-- `Random page <http://processors.wiki.ti.com/index.php/Special:Random>`__
-
-- `Help <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="p-coll-print_export" class="portal" role="navigation"
-   aria-labelledby="p-coll-print_export-label">
-
-.. rubric:: Print/export
-   :name: p-coll-print_export-label
-
-.. raw:: html
-
-   <div class="body">
-
-- `Create a book
-  <http://processors.wiki.ti.com/index.php?title=Special:Book&bookcmd=book_creator&referer=Processor+SDK+RTOS+NDK>`__
-
-- `Download as PDF
-  <http://processors.wiki.ti.com/index.php?title=Special:Book&bookcmd=render_article&arttitle=Processor+SDK+RTOS+NDK&oldid=232568&writer=rl>`__
-
-- `Printable version
-  <http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_NDK&printable=yes>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="p-tb" class="portal" role="navigation"
-   aria-labelledby="p-tb-label">
-
-.. rubric:: Toolbox
-   :name: p-tb-label
-
-.. raw:: html
-
-   <div class="body">
-
-- `What links here
-  <http://processors.wiki.ti.com/index.php/Special:WhatLinksHere/Processor_SDK_RTOS_NDK>`__
-
-- `Related changes
-  <http://processors.wiki.ti.com/index.php/Special:RecentChangesLinked/Processor_SDK_RTOS_NDK>`__
-
-- `Special pages
-  <http://processors.wiki.ti.com/index.php/Special:SpecialPages>`__
-
-- `Permanent link
-  <http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_NDK&oldid=232568>`__
-
-- `Page information
-  <http://processors.wiki.ti.com/index.php?title=Processor_SDK_RTOS_NDK&action=info>`__
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   <div id="footer" role="contentinfo">
-
-- This page was last modified on 27 December 2017, at 15:28.
-
-- This page has been accessed 6,887 times.
-
-- Content is available under `Creative Commons Attribution-ShareAlike
-  <http://creativecommons.org/licenses/by-sa/3.0/>`__ unless otherwise noted.
-
-- `Privacy policy
-  <http://processors.wiki.ti.com/index.php/Project:Privacy_policy>`__
-
-- `About Texas Instruments Wiki
-  <http://processors.wiki.ti.com/index.php/Project:About>`__
-
-- `Disclaimers
-  <http://processors.wiki.ti.com/index.php/Project:General_disclaimer>`__
-
-- `Terms of Use
-  <http://processors.wiki.ti.com/index.php/Project:Terms_of_Service>`__
-
-- |Creative Commons Attribution-ShareAlike|
-
-- |Powered by MediaWiki|
-
-.. raw:: html
-
-   <div style="clear:both">
-
-.. raw:: html
-
-   </div>
-
-.. raw:: html
-
-   </div>
-
-.. |NDK ARCH.png| image:: /images/0/0a/NDK_ARCH.png
-   :width: 561px
-   :height: 504px
-   :target: /index.php/File:NDK_ARCH.png
-
-.. |E2e.jpg| image:: /images/8/82/E2e.jpg
-   :width: 305px
-   :height: 63px
-   :target: /index.php/File:E2e.jpg
-
-.. |Hyperlink blue.png| image:: /images/9/9f/Hyperlink_blue.png
-   :width: 96px
-   :height: 96px
-   :target: /index.php/File:Hyperlink_blue.png
-
-.. |Creative Commons Attribution-ShareAlike| image:: /resources/assets/licenses/cc-by-sa.png
-   :width: 88px
-   :height: 31px
-   :target: http://creativecommons.org/licenses/by-sa/3.0/
-
-.. |Powered by MediaWiki| image:: /resources/assets/poweredby_mediawiki_88x31.png
-   :width: 88px
-   :height: 31px
-   :target: //www.mediawiki.org/
diff --git a/source/rtos/_Tools.rst b/source/rtos/_Tools.rst
deleted file mode 100644
index c6e4858eb..000000000
--- a/source/rtos/_Tools.rst
+++ /dev/null
@@ -1,42 +0,0 @@
-Processor SDK RTOS top-level Makefile
-======================================
-.. include:: Development_Tools/_PSDK_RTOS_Top_level_Makefile.rst
-
-
-Pin Mux Tool
-=============
-`Pin Mux Tool <http://www.ti.com/tool/PINMUXTOOL>`__
-
-
-Clock Tree Tool
-================
-`Clock Tree Tool <http://www.ti.com/tool/CLOCKTREETOOL>`__
-
-
-Code Composer Studio
-=====================
-
-
-CCS v6 Getting Started Guide
-------------------------------
-.. include:: Tools/Code_Composer_Studio/_CCS_v6_Getting_Started.rst
-
-
-XDS560 Emulator Information
--------------------------------
-.. include:: Tools/Code_Composer_Studio/_XDS560_Emulator_Info.rst
-
-
-XDS100 Emulator Information
--------------------------------
-.. include:: Tools/Code_Composer_Studio/_XDS100_Emulator_Info.rst
-
-
-Multi-core System Analyzer
--------------------------------
-.. include:: Tools/Code_Composer_Studio/_Multi_Core_System_Analyzer.rst
-
-
-Runtime Object Viewer
-------------------------
-`Runtime Object Viewer <http://rtsc.eclipse.org/docs-tip/Runtime_Object_Viewer>`__
diff --git a/source/rtos/index.rst b/source/rtos/index.rst
deleted file mode 100644
index cd9e86bda..000000000
--- a/source/rtos/index.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-.. _rtos-index:
-
-.. include:: Overview/_Processor_SDK_RTOS_Software_Developers_Guide.rst
-
-.. toctree::
-   :maxdepth: 5
-   :hidden:
-   :numbered:
-
-   Overview
-   Release_Specific
-   Board_EVM_Abstration
-   Foundational_Components
-   DSP_Software
-   Device_Drivers
-   PRU_ICSS
-   Compilers
-   Examples_and_Demonstrations
-   How_to_Guides
-   FAQ
-   Documentation_Tarball
-
-|
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: ../images/E2e.jpg   | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/rtos/index_Foundational_Components.rst b/source/rtos/index_Foundational_Components.rst
deleted file mode 100644
index c4811d0e1..000000000
--- a/source/rtos/index_Foundational_Components.rst
+++ /dev/null
@@ -1,260 +0,0 @@
-.. _foundational-components-ti-rtos-kernel:
-
-***************
-TI-RTOS Kernel
-***************
-- `SYSBIOS <https://www.ti.com/tool/SYSBIOS>`__
-
-
-.. _foundational-components-xdais:
-
-*******
-XDAIS
-*******
-- `XDAIS <http://processors.wiki.ti.com/index.php?title=Category:XDAIS>`__
-
-
-.. _foundational-components-fc:
-
-****
-FC
-****
-- `Framework Components <http://processors.wiki.ti.com/index.php?title=Category:Framework_Components>`__
-
-.. _foundational-components-ipc:
-
-*******
-IPC
-*******
-
-.. note:: This section mainly provides details of the software distributed part of the IPC 3.x package (installed under ipc_<version>). The IPC package provides the IPC APIs with higher level software abstraction. In addition,starting from  Processor SDK 6.1 release, a lower level IPC driver (IPC LLD) using rpmsg based transport is included specifically for AM6x/J7 platforms. See the following link for additional details `IPC 3.x vs IPC LLD`_
-
-.. note:: Starting with releases after the 6.3 release, IPC3.x will be deprecated on the AM65x device and IPC LLD is the only IPC stack supported. Please stop new development on top of IPC3.x for AM65x, and migrate to IPC LLD stack. Please see `IPC LLD for AM65x/J721E <index_device_drv.html#ipclld>`_ for information on IPC LLD.
-
-IPC User's Guide
-================
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_Users_Guide.rst
-
-Use Cases for IPC
-=============================
-.. include:: /rtos/PDK_Platform_Software/IPC/_Use_Cases_for_IPC.rst
-
-
-
-IPC Examples
-=============
-
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_examples.rst
-
-IPC Training
-=============
-
-.. include:: /common/IPC/_IPC_Training.rst
-
-TI SDO IPC Package
-====================
-.. include:: /rtos/PDK_Platform_Software/IPC/_The_ti.sdo.ipc_Package.rst
-
-IPC Module
-------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_Module.rst
-
-MessageQ Module
------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_MessageQ_Module.rst
-
-ListMP Module
------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_ListMP_Module.rst
-
-HeapMP Module
------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_HeapMP_Modules.rst
-
-GateMP Module
------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_GateMP_Module.rst
-
-GateMP Support for UIO and Misc Driver
----------------------------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_GateMP_Support_for_UIO_and_Misc_Driver.rst
-
-Notify Module
------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_Notify_Module.rst
-
-Shared Region Module
-----------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_SharedRegion_Module.rst
-
-
-
-TI SDO Utils Package
-=====================
-.. include:: /rtos/PDK_Platform_Software/IPC/_The_ti.sdo.utils_Package.rst
-
-List Module
---------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_List_Module.rst
-
-MultiProc Module
--------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_MultiProc_Module.rst
-
-NameServer Module
--------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_NameServer_Module.rst
-
-
-Optimizing IPC Applications
-=============================
-.. include:: /rtos/PDK_Platform_Software/IPC/_Optimizing_IPC_Applications.rst
-
-Rebuilding IPC
-================
-.. include:: /rtos/PDK_Platform_Software/IPC/_Rebuilding_IPC.rst
-
-
-|
-
-IPC Transports
-===============
-.. include:: /common/IPC/_IPC_Transports.rst
-
-IPC Benchmarking
-==================
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_BenchMarking.rst
-
-IPC 3.x
-========
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_3.x.rst
-
-Resource Custom Table
-----------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_Resource_customTable.rst
-
-Resource Usage
----------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_Resource_Usage.rst
-
-IPC 3.x vs IPC LLD
-==================
-
-IPC 3.x APIs provide High level IPC APIs that scale across all TI platforms.
-
-Instead of the IPC 3.x APIs, in certain cases customers can choose to use the IPC Low level Driver (IPC LLD).
-
-In general, the IPC LLD can be used, if the customer application falls under the following categories.
-
-a) Non-RTOS bare metal applications (Note: IPC 3.x is closely coupled with  SYSBIOS and XDC tools)
-b) Applications does not need the high level API abstraction and all the features (like GateMP etc) and would like to call the low level driver to just establish basic communication between the cores.
-c) Application needs the same RPMSG/Virtio transport mechanism to communicate with a core running linux and other cores running other operating systems.
-
-Please refer to the following page for details on the IPC LLD: `IPC LLD for AM65x/J721E <index_device_drv.html#ipclld>`_
-
-IPC FAQ
-========
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_3.x_FAQ.rst
-
-FAQ For Keystone Devices
--------------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_FAQ_for_Keystone_Devices.rst
-
-IPC Install Guides
-====================
-The IPC package now comes bundled with Processor SDK RTOS and can be built using the top-level makefile located in the Processor SDK RTOS folder. These install guides have been kept here for those using older, legacy versions of IPC.
-
-BIOS Install Guide
--------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_BIOS.rst
-
-Linux Install Guide
--------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_Linux.rst
-
-QNX Install Guide
--------------------
-.. include:: /rtos/PDK_Platform_Software/IPC/_IPC_Install_Guide_QNX.rst
-
-
-.. _foundational-components-opencl:
-
-***************
-OpenCL
-***************
-`OpenCL <http://downloads.ti.com/mctools/esd/docs/opencl/index.html>`__
-
-
-.. _foundational-components-boot:
-
-***************
-Boot
-***************
-.. _FC-Boot-label:
-.. include:: /rtos/_Boot.rst
-
-
-.. _foundational-components-mpm:
-
-*****
-MPM
-*****
-.. include:: /rtos/_MPM.rst
-
-
-.. _foundational-components-openmp:
-
-*******
-OpenMP
-*******
-.. include:: /rtos/Compute/_OpenMP.rst
-
-
-.. _foundational-components-pktlib:
-
-***************
-PKTLIB
-***************
-.. include:: /rtos/PDK_Platform_Software/Device_Drivers/_PKTLIB.rst
-
-.. _foundational-components-network:
-
-***************
-Network
-***************
-CCLink
-=======
-.. include:: /rtos/PDK_Platform_Software/Network_and_Transport/_CCLink.rst
-
-.. _foundational-components-ndk:
-
-NDK
-=======
-.. include:: /rtos/PDK_Platform_Software/Network_and_Transport/_NDK.rst
-
-.. _foundational-components-nwal:
-
-NWAL
-***************
-.. include:: /rtos/PDK_Platform_Software/Device_Drivers/_NWAL.rst
-
-.. _foundational-components-transport:
-
-***************
-Transport
-***************
-TimeSync (PTP)
-==============
-.. include:: /rtos/PDK_Platform_Software/Network_and_Transport/_TimeSync.rst
-
-.. _foundational-components-tools:
-
-***************
-Tools
-***************
-- `Processor SDK RTOS Tools <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Tools>`__
-
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/rtos/index_board.rst b/source/rtos/index_board.rst
deleted file mode 100644
index e0b2b5c70..000000000
--- a/source/rtos/index_board.rst
+++ /dev/null
@@ -1,36 +0,0 @@
-.. _board-board-support:
-
-Board Support
-==============
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Board_Support.rst
-
-.. _index-board-diagnostics:
-
-Diagnostics
-============
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics.rst
-
-Diagnostics Execution
-======================
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Diagnostics_Execution.rst
-
-.. _board-power-on-self-test:
-
-Power-On Self Test
-===================
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_POST.rst
-
-Board Utils
-============
-Uniflash
---------
-.. include:: PDK_Platform_Software/Boot_Board_and_EVM_Abstractions/_Uniflash.rst
-
-UART Apploader
---------------
-UART AppLoader is a standalone application to download the application images over UART.
-Check the link `UART AppLoader <index_Foundational_Components.html#uart-apploader>`__ for more details on UART AppLoader.
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: ../images/E2e.jpg   | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/rtos/index_device_drv.rst b/source/rtos/index_device_drv.rst
deleted file mode 100644
index 551c4a2f7..000000000
--- a/source/rtos/index_device_drv.rst
+++ /dev/null
@@ -1,280 +0,0 @@
-.. _device-driver-csl:
-
-***********
-CSL
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_CSL.rst
-
-
-.. _device-driver-uart:
-
-***********
-UART
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_UART.rst
-
-
-.. _device-driver-usb:
-
-***********
-USB
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_USB.rst
-
-
-.. _device-driver-pcie:
-
-***********
-PCIe
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_PCIe.rst
-
-
-.. _device-driver-gpio:
-
-***********
-GPIO
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_GPIO.rst
-
-
-.. _device-driver-i2c:
-
-***********
-I2C
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_I2C.rst
-
-.. _device-driver-serdes-diag:
-
-***********
-Serdes Diag
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_Serdes_Diag.rst
-
-
-.. _device-driver-mcspi-qspi-ospi:
-
-***************
-McSPI-QSPI-OSPI
-***************
-.. include:: PDK_Platform_Software/Device_Drivers/_QSPI_McSPI.rst
-
-
-.. _device-driver-edma3:
-
-***********
-EDMA3
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_EDMA3.rst
-
-
-.. _device-driver-icss-emac:
-
-*********************************
-ICSS-EMAC
-*********************************
-.. include:: PDK_Platform_Software/Device_Drivers/_ICSS_EMAC_LLD_FW.rst
-
-
-.. _device-driver-pruss:
-
-***********
-PRUSS
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_PRUSS.rst
-
-
-.. _device-driver-fatfs:
-
-***********
-FATFS
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_FATFS.rst
-
-
-.. _device-driver-mmcsd:
-
-***********
-MMCSD
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_MMCSD.rst
-
-
-.. _device-driver-qmss:
-
-***********
-QMSS
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_QMSS.rst
-
-
-.. _device-driver-cppi:
-
-***********
-CPPI
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_CPPI.rst
-
-
-.. _device-driver-pa:
-
-***********
-PA
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_PA.rst
-
-
-.. _device-driver-sa:
-
-***********
-SA
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_SA.rst
-
-
-.. _device-driver-srio:
-
-***********
-SRIO
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_SRIO.rst
-
-
-.. _device-driver-hyplnk:
-
-***********
-HYPLNK
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_HYPLNK.rst
-
-
-.. _device-driver-tsip:
-
-***********
-TSIP
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_TSIP.rst
-
-
-.. _device-driver-mcbsp:
-
-***********
-MCBSP
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_MCBSP.rst
-
-
-.. _device-driver-emac:
-
-***********
-EMAC
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_EMAC.rst
-
-
-.. _device-driver-mcasp:
-
-***********
-MCASP
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_MCASP.rst
-
-
-.. _device-driver-dss:
-
-***********
-DSS
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_DSS.rst
-
-
-.. _device-driver-cal:
-
-***********
-CAL
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_CAL.rst
-
-
-.. _device-driver-udma:
-
-***********
-UDMA
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_UDMA.rst
-
-
-.. _device-driver-pm:
-
-***********
-PM
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_PM.rst
-
-
-.. _device-driver-rm:
-
-***********
-RM
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_RM.rst
-
-
-.. _device-driver-gpmc:
-
-***********
-GPMC
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_GPMC.rst
-
-
-.. _device-driver-sciclient:
-
-***********
-SCICLIENT
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_SCICLIENT.rst
-
-
-.. _device-driver-ipclld:
-
-***********
-IPCLLD
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_IPCLLD.rst
-
-
-.. _device-driver-vps-drivers:
-
-***********
-VPS Drivers
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_VPS_Drivers.rst
-
-
-.. _device-driver-iolink:
-
-***********
-IOLINK
-***********
-.. include:: PDK_Platform_Software/Device_Drivers/_IOLINK.rst
-
-
-.. _device-driver-osal:
-
-***********
-OSAL
-***********
-.. include:: PDK_Platform_Software/Device_Driver_Utilities/_OSAL.rst
-
-.. _device-driver-profiling:
-
-***********
-Profiling
-***********
-.. include:: PDK_Platform_Software/Device_Driver_Utilities/Profiling.rst.inc
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/rtos/index_dsp_sw.rst b/source/rtos/index_dsp_sw.rst
deleted file mode 100644
index 733347c9d..000000000
--- a/source/rtos/index_dsp_sw.rst
+++ /dev/null
@@ -1,48 +0,0 @@
-.. ************************
-.. DSP Optimized Libraries
-.. ************************
-
-.. _dsp-sw-dsp-optimized-libraries:
-
-.. include:: DSP_Software/_DSP_Optimized_Libraries.rst
-
-********************
-DSP Debug and Trace
-********************
-.. _dsp-sw-ctoolslib:
-
-CToolsLib
-==========
-.. include:: DSP_Software/DSP_Debug_and_Trace/_CToolsLib.rst
-
-.. _dsp-sw-uia:
-
-UIA
-=====
-.. include:: DSP_Software/DSP_Debug_and_Trace/_UIA.rst
-
-
-.. _dsp-sw-trace:
-
-Trace
-======
-.. include:: DSP_Software/DSP_Debug_and_Trace/_Trace.rst
-
-
-.. _dsp-sw-fault-management:
-
-Fault Management
-=================
-.. include:: DSP_Software/DSP_Debug_and_Trace/_Fault_Management.rst
-
-
-.. _dsp-sw-wdt:
-
-WDT
-======
-.. include:: DSP_Software/DSP_Debug_and_Trace/_WDT.rst
-
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/rtos/index_examples_demos.rst b/source/rtos/index_examples_demos.rst
deleted file mode 100644
index d0978e276..000000000
--- a/source/rtos/index_examples_demos.rst
+++ /dev/null
@@ -1,98 +0,0 @@
-**********************************
-Template Application Workshop
-**********************************
-.. _Demo-RTOS-Template-Application-label:
-.. include:: Examples_and_Demonstrations/_RTOS_Template_App.rst
-
-**********************
-Image Processing Demo
-**********************
-.. include:: Examples_and_Demonstrations/_Image_Processing_Demo.rst
-
-
-**********************
-POSIX-SMP Demo
-**********************
-.. include:: Examples_and_Demonstrations/_Posix_SMP_Demo.rst
-
-
-***************************
-Audio Benchmark Starterkit
-***************************
-.. include:: Examples_and_Demonstrations/_Audio_Benchmark_Starterkit.rst
-
-
-***************************
-Audio Pre-Processing Demo
-***************************
-.. include:: Examples_and_Demonstrations/_Audio_Pre_Processing.rst
-
-
-***************************
-Performance Audio Demo
-***************************
-.. include:: Examples_and_Demonstrations/_Performance_Audio.rst
-
-
-***************************
-Big Data IPC Example
-***************************
-.. include:: Examples_and_Demonstrations/_Big_Data_IPC_Examples.rst
-
-
-***************************
-TI-RTOS Kernel Example
-***************************
-.. include:: Examples_and_Demonstrations/_RTOS_Examples.rst
-
-
-***************************
-No OS (Bare Metal) Example
-***************************
-.. include:: Examples_and_Demonstrations/_Bare_Metal_Examples.rst
-
-
-***************************
-Gravity Simulator Demo
-***************************
-.. include:: Examples_and_Demonstrations/_Gravity_Simulator_Demo.rst
-
-
-***************************
-Jailhouse Hypervisor
-***************************
-.. include:: Examples_and_Demonstrations/_Jailhouse_Hypervisor.rst
-
-
-***************************
-K2G AUDIO DC AddOn
-***************************
-.. include:: Examples_and_Demonstrations/_AUDK2G_AddOn.rst
-
-
-***************************
-CMB AddOn
-***************************
-.. include:: Examples_and_Demonstrations/_CMB_AddOn.rst
-
-
-***************************
-SimpleLink WiFi Demo
-***************************
-.. _Demo-SimpleLink-WiFi-Demo-label:
-.. include:: Examples_and_Demonstrations/_SimpleLink_WiFi_Demo.rst
-
-***************************
-CAN-Eth Gatway Demo
-***************************
-.. include:: Examples_and_Demonstrations/_Can_Eth_Gateway_Demo.rst
-
-**********************
-Interrupt Latency Benchmark
-**********************
-.. include:: Examples_and_Demonstrations/_Interrupt_Latency_Benchmark.rst
-
-**************************************************
-Sofware Diagnostics Reference and Test Framework
-**************************************************
-.. include:: Examples_and_Demonstrations/_Sofware_Diagnostics_Reference.rst
diff --git a/source/rtos/index_faq.rst b/source/rtos/index_faq.rst
deleted file mode 100644
index 35867ca2c..000000000
--- a/source/rtos/index_faq.rst
+++ /dev/null
@@ -1,1379 +0,0 @@
-.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_FAQ
-
-General Support
-===============
-
-.. rubric:: What are the main advantages of using the Processor SDK RTOS
-   software?
-   :name: what-are-the-advantages-of-using-the-processor-sdk-rtos-software
-
-Here are some key features of the Processor SDK RTOS that maximize
-software reuse for application developers:
-
--  **Common API Interface**: Processor SDK RTOS software is designed to
-   maximize application software reuse and reduce the time to market for
-   end application developers. It provides a unified approach to
-   software by maintaining a common API interface in low-level drivers,
-   inter-processor communication (IPC) drivers, and optimized libraries
-   across all supported platforms. The API interface also enables ease
-   of migration for TI MCU customers moving to TI ARM or DSP platforms
-   by maintaining the same API interface for common IPs like SPI, I2C,
-   UART,etc.
-
--  **Ease of Migration to Custom Platform**: Processor SDK RTOS
-   consolidates all board-specific software into a single software
-   component referred to as the "board library". All of the other
-   components rely on this board library to configure the underlying
-   hardware. Migration to a custom platform requires only modification
-   of the board library.
-
--  **Integrated Board Diagnostic Software**: The board diagnostic
-   software included in the SDK allows for quick validation of the board
-   functionality using bare-metal (no-OS) unit tests.
-
--  **Reduces Need to Relearn TI Software**: All future software releases
-   for TI SoC platforms will use this software methodology and will
-   maintain the common API interface for a given peripheral. Application
-   developers who have already developed their software on one of TI`s
-   Processors using Processor SDK will not need to re-learn working with
-   the TI software.
-
--  **Feature Addition and Reduced Software Costs**: Due to the ease of
-   migration of baseline software across platforms, developers can spend
-   more time customizing their application and add more features to
-   enhance it. This also helps to reduce the duration of the application
-   development cycle and helps reduce software development costs.
-
--  **Quarterly Software Updates**: Processor SDK RTOS is updated every
-   three months with bug fixes, new features, and new platform support.
-   Users can subscribe to updates by using the "Alert Me" button for the
-   package from the software download page on ti.com.
-
-.. note::
-   If you are unable to locate the "Alert Me" option, please check
-   the screenshot here:
-
-.. Image:: ../images/Alert_Me.png
-
-|
-
-.. rubric:: How do I make a feature request or file bugs for Processor
-   SDK RTOS?
-   :name: how-do-i-make-a-feature-request-or-file-bugs-for-processor-sdk-rtos
-
-TI E2E device-specific forums can be used to report a bug or a feature
-addition request:
-
--  `E2E Processor Support <https://e2e.ti.com/support/processors/>`__
-
-.. rubric:: How do I know the list of known issues and bugs resolved in
-   Processor SDK RTOS release?
-   :name: how-do-i-know-the-list-of-known-issues-and-bugs-resolved-in-processor-sdk-rtos-release
-
-The information on known issues and bug fixes in Processor SDK RTOS can
-be found in the :ref:`Release Notes <processor-sdk-rtos-release-notes>`
-for the version of the SDK you wish to use.
-
-.. rubric:: I am a current Sitara Starterware user. Should I migrate to
-   Processor SDK RTOS?
-   :name: i-am-a-current-sitara-starterware-user.-should-i-migrate-to-processor-sdk-rtos
-
-Starterware software is no longer active and will not have any further
-releases. Existing starterware users should refer the following article
-to determine the migration path: :ref:`Processor SDK RTOS Migration Guide
-<RTOS-SDK-Migration-Guide-label>`.
-For all new development, we recommend that users start with the
-Processor SDK RTOS, which is currently under active development and
-provides periodic updates and bug fixes.
-
-.. rubric:: Is Processor SDK RTOS replacing MCSDK? How do I migrate from
-   MCSDK to Processor SDK RTOS for KeyStone devices?
-   :name: is-processor-sdk-rtos-replacing-mcsdk-how-do-i-migrate-from-mcsdk-to-processor-sdk-rtos-for-keystone-devices
-
-Yes. We recommend that for all new development, users should use
-Processor SDK RTOS for application development. For existing users, the
-Processor SDK RTOS provides an easy migration path for existing MCSDK
-3.x (K2X) and MCSDK 2.x (C66xx) developers to move their application to
-the new software package. For complete details please refer to the wiki
-`MCSDK to Processor SDK RTOS
-Migration <http://processors.wiki.ti.com/index.php/MCSDK_to_Processor_SDK_Migration#Processor_SDK_RTOS>`_.
-
-.. rubric:: How do I download earlier version of Processor SDK RTOS?
-   :name: how-do-i-download-earlier-version-of-processor-sdk-rtos
-
-The download page for every Processor SDK RTOS release contains links to
-the previous release. Users can revert back to earlier releases using
-this link provided under the section "Previous Release."
-
-.. rubric:: Does processor SDK RTOS release support all device part numbers in supported device family?
-   :name: does-processor-sdk-rtos-release-support-all-device-part-numbers-in-supported-device-family
-
-Processor SDK RTOS software is tested and validated on TI evaluation platforms that generally includes the superset part
-in the device family however, the software components like CSL, LLD drivers and RTOS are applicable on reduced feature set
-variant of the devices. Most of the code in the Processor SDK RTOS for multi-core devices is independent of how many cores
-exists on the device as they provide baseline platform software that can be run from any core.
-
-It is the users responsibility to modify components that deploy tasks/software on slave cores like OpenMP, OpenCL, IPC and MultiProc Manager
-so that they use the feature set that is available on their device. In most cases software documentation will provide guidance on updating
-the software package however this should not be considered a comprehensive list of software components to be updated
-to run the software on a reduced feature set device variant.
-
-Example: `Processor SDK RTOS porting guide for AM571x/AM570x Speed
-Grades <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Porting_Guide_for_AM571x/AM570x_Speed_Grades>`_
-
-Features noted as “not supported,” in device datasheet must not be used. Their functionality is not supported by TI for this
-family of devices. These features are subject to removal without notice on future device revisions. Any information regarding
-the unsupported features has been retained in the documentation solely for the purpose of clarifying signal names or for consistency
-with previous feature descriptions.
-
-|
-
-Training and Documentation
-==========================
-
-.. rubric:: Is there any training content available for Processor SDK
-   RTOS?
-   :name: is-there-any-training-content-available-for-processor-sdk-rtos
-
-There are multiple Processor SDK RTOS training modules available online
-as part of the `Processor SDK Training
-Series <https://training.ti.com/processor-sdk-training-series>`__. Link
-to the complete series or refer to the direct links below:
-
-Training URLs:
-
--  `Processor SDK RTOS Overview Part
-   I <https://training.ti.com/introduction-processor-sdk-rtos-part-1?cu=519268>`__
--  `Processor SDK RTOS Overview Part
-   II <https://training.ti.com/introduction-processor-sdk-rtos-part-2?cu=519268>`__
--  `Application Development Using Processor SDK
-   RTOS <https://training.ti.com/application-development-using-processor-sdk-rtos?cu=519268>`__
-
-.. rubric:: What documentation exists for Processor SDK RTOS?
-   :name: what-documentation-exists-for-processor-sdk-rtos
-
-There are three main documents for Processor SDK RTOS:
-
--  :ref:`Getting Started Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-   Provides information on setting up software and running basic
-   examples/demonstrations bundled within the Processor SDK.
--  :ref:`Software Developer
-   Guide <rtos-index>`:
-   Provides information on features, functions, delivery package, and
-   compile tools for the Processor SDK RTOS release. This guide also
-   provides detailed information regarding software elements and
-   software infrastructure to allow developers to start creating
-   applications.
--  :ref:`Migration Guide <RTOS-SDK-Migration-Guide-label>`: Provides
-   migration information for applications built on top of the Processor
-   SDK for RTOS.
-
-|
-
-Host and Target Setup
-=====================
-
-.. rubric:: How do I setup the build environment with custom Processor
-   SDK RTOS and CCS Installation paths on the host machine?
-   :name: how-do-i-setup-the-build-environment-with-custom-processor-sdk-rtos-and-ccs-installation-paths-on-the-host-machine
-
-The steps to set up CCS and Processor SDK RTOS when the SDK or the IDE
-is installed in a location other than the default location are described
-below: `Processor SDK RTOS Setup with CCS <How_to_Guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__.
-
-A common gotcha while setting up the build environment is
-compatibility with CCS version. Please refer to :ref:`Release
-Notes <processor-sdk-rtos-release-notes>` for the
-recommended version of CCS.
-
-.. rubric:: Can I install multiple versions of the Processor SDK RTOS in
-   the same folder?
-   :name: can-i-install-multiple-versions-of-the-processor-sdk-rtos-in-the-same-folder
-
-Typically, the version numbers of most components (PDK, Processor SDK,
-BIOS, XDC, etc.) will be updated in the newer release. However there are
-components like DSPLIB, IMGLIB, etc. and EDMA drivers that may remain
-the same. The safe option would be to install the most current Processor
-SDK in a custom location. You can have multiple versions of the SDK for
-different devices on your machine and install all of them in custom
-folders. For example, if you have a project with AM335x and AM437x that
-requires you to download the Processor SDK RTOS for those device, we
-recommend that you install them under different directories say
-C:\\ti\\PRSDK_AM3x and C:\\ti\\PRSDK_AM4x
-
-.. note::
-   When you install the SDK in a custom location, there are few additional
-   steps to follow:
-
-   -  CCS auto-detects components only in C:\\ti path. So you will need to
-      add the custom path to discovery as described in `Setup
-      CCS <How_to_Guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__.
-   -  Assuming CCS is installed in the default path, the process to set the
-      custom SDK path while building the SDK is provided in `Install in
-      Custom Path <How_to_Guides.html#update-environment-when-installing-to-a-custom-path>`
-
-.. rubric:: What are the typical flows for a new user to setup the
-   Processor SDK RTOS development environment?
-   :name: what-are-the-typical-flows-for-a-new-user-to-setup-the-processor-sdk-rtos-development-environment
-
-The typical Processor SDK RTOS setup steps have been described below:
-
-.. rubric:: Step 1: Basic Hardware, SDK, and IDE Setup
-   :name: step-1-basic-hardware-sdk-and-ide-setup
-
-Setup the software and hardware as described in the :ref:`Getting Started
-Guide <Processor-SDK-RTOS-Getting-Started-Guide-label>`
-At this stage, you should have the CCS IDE environment, the Processor
-SDK RTOS installed and be able to connect to your target using an
-emulator.
-
-.. note::
-   If you have installed CCS and/or the Processor SDK RTOS in a custom
-   location, you need to manually add the SDK install path to CCS as
-   described here
-   `CCS_and_SDK_installed_in_different_directories <How_to_Guides.html#ccs-and-sdk-installed-in-different-directories>`__
-
-.. rubric:: Step 2: Run the Out-of-Box Examples or Diagnostics
-   :name: step-2-run-the-out-of-box-examples-or-diagnostics
-
-The SDK and CCS ships with some pre-built out-of-box
-demonstrations/examples that can be flashed on to the EVM, copied over
-to an SD card, or loaded over emulator so that you can bring up and test
-the EVM hardware. The steps to flash and run the out-of-box examples are
-described here:
-
--  `Running_examples.2Fdemonstrations <Examples_and_Demonstrations.html#examples-and-demonstrations>`__
-
-.. rubric:: Step 3: Build Environment Setup
-   :name: step-3-build-environment-setup
-
-Processor SDK RTOS provides a script to set up the Windows and Linux
-environment with the component and compiler PATHs. Running the script
-and rebuilding the Processor SDK from the root directory is described in
-the wiki article `Setup build Environment <Overview.html#setup-environment>`.
-
-.. note::
-
-   -  The script assumes that CCS and Processor SDK RTOS are installed in
-      the default location. If you have installed CCS and/or the Processor
-      SDK RTOS in a custom location, then modify the setup file to the
-      custom path. Please setup the environment using the steps described
-      in the wiki article
-      `Processor SDK RTOS Install in Custom Path <How_to_Guides.html#update-environment-when-installing-to-a-custom-path>`__
-   -  After the script executes, it prints all the PATH macros set for the
-      different variables. Be sure that the compiler and component paths
-      have been setup correctly.
-
-
-.. rubric:: Step 4: Rebuilding the SDK
-   :name: step-4-rebuilding-the-sdk
-
-The critical device-specific components of the Processor SDK RTOS can be
-rebuilt from the top-level make file provided in the root directory
-processor_sdk_rtos_x_xx_xx_xx. Invoking the build and available options
-from top-level make files is described in the wiki article `Rebuilding
-SDK
-Components <Overview.html#top-level-makefile>`__.
-
-.. note::
-   The SDK offers command line build for all the components. CCS projects
-   are only supported for DSP libraries and PDK driver examples.
-
-.. rubric:: Step 5: Generate and Run Peripheral Driver Examples
-   :name: step-5-generate-and-run-peripheral-driver-examples
-
-The PDK component in Processor SDK RTOS provides drivers for different
-IPs on the SOC and provides unit tests and examples for the drivers to
-test them on a specific board/hardware. These examples do not ship with
-pre-generated CCS projects and require users to generate a project
-create script to generate the CCS project for the unit tests. The
-procedure to generate the CCS projects for a given SOC is described in
-this article
-`PDK_Example_and_Test_Project_Creation <How_to_Guides.html#pdk-example-and-test-project-creation>`__.
-
-.. rubric:: Step 6: Exploring Other Components in the SDK
-   :name: step-6-exploring-other-components-in-the-sdk
-
-The SDK package includes several other components that allow application
-developers to develop software for multi-core devices. This includes an
-inter-processor communication component known as (IPC). For SOCs that
-contain an C66x DSP, the SDK provides several optimized DSP libraries
-(DSPLIB, MATHLIB and IMGLIB). These components also ship with pre-built
-examples that can be built using build steps described in their
-documentation that is linked at the top level :ref:`Software Developer
-Guide <rtos-index>`.
-
-|
-
-.. rubric:: How can I optimize the build time when rebuilding the
-   Processor SDK RTOS ?
-   :name: how-can-i-optimize-the-build-time-when-rebuilding-the-processor-sdk-rtos
-
-Processor SDK RTOS top level build will rebuild IPC, all components
-inside the PDK package for all supported cores and evaluation platforms.
-Building all components can cause long build times. If you wish to only
-rebuild a section of the package, the build times can be significantly
-optimized if you invoke make for specific components in the SDK instead
-of making all components. Also, for the PDK users can invoke the build
-using the following syntax
-
-::
-
-    make LIMIT_BOARDS="<BOARD>" LIMIT_SOCS="<SOC>" LIMIT_CORES="<CORE>"
-
-**SOC** can be am335x, am437x, am571x, am572x, k2g,k2h,k2e, etc.
-
-**CORE** can be “a15_0”, “c66x”, or “ipu1_0”, for a15, c66, m4
-respectively.
-
-**BOARD** can be any evaluation hardware platform that your SOC
-supports.
-
-::
-
-    For Example:
-    make LIMIT_BOARDS="evmK2G iceK2G" LIMIT_SOCS="k2g" LIMIT_CORES="a15_0"
-|
-
-.. rubric:: Why am I not able to connect to the DSP core in CCS when
-   Linux is booted on KeyStone II devices?
-   :name: why-am-i-not-able-to-connect-to-the-dsp-core-in-ccs-when-linux-is-booted-on-keystone-ii-devices
-
-The U-boot code that is booted before booting Linux puts the DSP core in
-reset. In order to connect to the DSP, you need to run a GEL script in
-CCS as described in this article
-`Taking_the_C66x_Out_Of_Reset_with_Linux_Running_on_the_ARM_A15 <How_to_Guides.html#taking-the-c66x-out-of-reset-with-linux-running-on-the-arm-a15>`__.
-
-.. rubric:: How can I create a SD card for Processor SDK RTOS?
-   :name: how-can-i-create-a-sd-card-for-processor-sdk-rtos
-
-Many of the TI-supported EVMs ship with an SD card with Linux Booting as
-part of the EVM out-of-box experience. Users are required to create a
-separate SD card if they want to boot their EVM with Processor SDK RTOS
-out-of-box demonstrations or run board diagnostics. The procedure to
-create an SD differs depending on whether you are doing this on a
-Windows or Linux host machine, as described in the two articles shown
-here:
-
--  `Create an SD card on Windows Host (AMx, K2G only) <Overview.html#windows-sd-card-creation-guide>`__
-
--  `Create an SD card on Linux Host (AMx, K2G only) <Overview.html#linux-sd-card-creation-guide>`__
-
-.. rubric:: How can I restore the firmware on my EVM to factory
-   settings?
-   :name: how-can-i-restore-the-firmware-on-my-evm-to-factory-settings
-
-Most of the Sitara EVMs ship with a bootable SD card that boots Linux.
-To restore the EVM to factory settings, simply reflash the SD card with
-the bootable image using the `SD Card Creation
-Script <http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_create_SD_card_script>`__
-provided in Processor SDK Linux.
-
-For KeyStone Devices, the Processor SDK RTOS provides a `Program EVM
-Script <How_to_Guides.html#default-binaries-and-setup>`__
-with default binaries that reflash images on EEPROM, SPI, and/or NAND
-(depending on the EVM platform used).
-
-.. rubric:: Can I run Processor SDK RTOS on BeagleBone?
-   :name: can-i-run-processor-sdk-rtos-on-beaglebone
-
-Yes, Processor SDK RTOS software can be used to develop and run code on
-BeagleBone platform. In order to test Processor SDK RTOS software on
-BeagleBone, you will need to connect a JTAG to the BeagleBone. With the
-default configuration of the board, we have observed that connecting a
-JTAG causes a reset. Users need to follow the procedure provided here to
-prevent a reset from occurring.
-
--  `Preventing a Reset When Connecting a JTAG on
-   BeagleBone <http://elinux.org/Beagleboard:BeagleBone#Board_Reset_on_JTAG_Connect.28A3.2CA4.2CA5.29>`__
-
-|
-
-Device Drivers
-==============
-
-.. rubric:: How do I find out if a driver is supported in the package
-   for my device?
-   :name: how-do-i-find-out-if-a-driver-is-supported-in-the-package-for-my-device
-
-For all SoC and board-specific driver support, we recommend that you
-refer to the :ref:`Release Notes <RN-Supported-Platforms-label>`
-corresponding to your release.
-
-If you need further details for driver support on all cores on
-heterogeneous multi-core devices, please reach out to the engineering
-team using `E2E forums <http://e2e.ti.com/support/>`__.
-
-.. rubric:: Where can I find example projects for device drivers?
-   :name: where-can-i-find-example-projects-for-device-drivers
-
-The PDK package in processor SDK RTOS does not contain pre-canned CCS
-projects for driver examples. But it does provide scripts to set up the
-development environment and create the example CCS projects based on
-that setup. This allows the SDK the flexibility to create CCS projects
-based on the user-specific host setup. In order to create the example
-projects, users can follow the sequence provided below:
-
-#. Users are required to setup their development environment using
-   `Processor SDK RTOS Setup <Overview.html#setup-environment>`__
-#. Setup the PDK build environment `PDK
-   Setup <How_to_Guides.html#building-pdk-using-gmake-in-windows-environment>`__.
-#. Execute the PdkProjectCreate script in ${PDK_INSTALL_PATH}/packages
-   as described on the `PDK Example and Test Project Creation
-   wiki <How_to_Guides.html#pdk-example-and-test-project-creation>`__
-
-.. rubric:: What is the difference between SOC-specific driver library
-   and the SOC-independent (Generic core-specific) driver library?
-   :name: what-is-the-difference-between-soc-specific-driver-library-and-the-soc-independent-generic-core-specific-driver-library
-
-Each low level driver (LLD) in the PDK package contains two versions of
-the driver library. The naming conventions are as follows:
-
--  **Generic Core-specific Driver Library** :
-   ti.drv.<module>.<core_specific_extension>
-
-Example: ti.drv.gpio.aa15fg (A15 core-specific GPIO driver library)
-
--  **SOC-specific Driver Library**:
-   ti.pdk.<module>.<soc>.<core_specific_extension>
-
-Example: ti.drv.gpio.am572x.aa15fg (A15 GPIO driver library for AM572x)
-
-When using the core-specific driver library, users are required to
-provide SOC-specific driver initialization structures that provide
-information regarding the module instance used, interrupt numbers,
-configuration modes, etc.
-
-The SOC-specific driver library contains a default configuration
-(provided in <module>_soc.c file) built into the library that gets used
-to initialize the driver on TI EVMs and to run sample applications
-provided in driver package. It may need to be modified to suit for a
-custom board and/or target application. The default configuration
-includes a specific peripheral instance, interrupt configuration, etc.
-
-.. rubric:: How to create ARM baremetal CCS project that link to PDK
-   driver libraries using GNU Linker?
-   :name: how-to-create-arm-baremetal-ccs-project-that-link-to-pdk-driver-libraries-using-gnu-linker
-
-The static libraries in Platform development kit (PDK) drivers use the
-convention ti.drv.<module>.a<ARM extension>. For example, the UART
-driver library for A15 is named "ti.drv.uart.aa15fg". This is different
-form the convention of naming the libraries with a suffix of "lib" and
-extension ".a" which is generally the case for ARM compiler libraries
-(e.g., librdimon.a, libgcc.a, libm.a). This is usually not an issue when
-building applications using GCC compiler and make/gmake as libraries can
-be linked using "-l" option. However, when building bare-metal (no-OS)
-ARM projects in CCS, the IDE expects the libraries to have the name with
-suffix "lib" and extension ".a". If developers try to link libraries
-which does not follow this convention, they observe a linking error that
-mentions that the library doesn`t exist. There are a couple of work
-around options available to users when working with baremetal PDK driver
-libraries:
-
-**Option 1:** Add a colon in front of the library name when adding the
-ARM driver library to "Build Settings"->"GNU Linker"->"Libraries" as
-shown below:
-
-.. Image:: ../images/Bare-metal_driver_link.png
-
-**Option 2:** Add driver libraries using linker command file using the
-INPUT syntax
-
-::
-
-    INPUT(
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\drv\gpio\lib\a8\release\ti.drv.gpio.profiling.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\utils\profiling\lib\a8\release\ti.utils.profiling.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\board\lib\icev2AM335x\a8\release\ti.board.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\drv\i2c\lib\a8\release\ti.drv.i2c.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\drv\uart\lib\a8\release\ti.drv.uart.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\csl\lib\am335x\a8\release\ti.csl.aa8fg"
-      "C:\ti\pdk_am335x_1_0_6\packages\ti\osal\lib\tirtos\a8\release\ti.osal.aa8fg"
-    )
-
-|
-
-Chip Support Library (CSL)
-==========================
-
-.. rubric:: Are there any bare-metal examples in the PDK package?
-   :name: are-there-any-bare-metal-examples-in-the-pdk-package
-
-Customers who are wanting to start bare-metal code development can refer
-to the diagnostics package which uses the PDK drivers and does not rely
-on the TI RTOS. There are also CSL examples included in the package
-under the path ${PDK_INSTALL_PATH}\\packages\\ti\\csl\\test.
-
-In addition to CSL example, the PDK contains bare-metal diagnostic test
-cases that help in testing EVM functionality. These can be located under
-pdk_am57xx_x_x_x\\packages\\ti\\board\\diag
-
-Some of the driver examples contain a flag for BARE METAL usage of the
-driver. Example: GPIO/SPI already have these flags implemented.
-
-.. rubric:: Can I read core-specific registers on multi-core devices
-   supported in Processor SDK RTOS using CSL code?
-   :name: can-i-read-core-specific-registers-on-multi-core-devices-supported-in-processor-sdk-rtos-using-csl-code
-
-Yes, SDK provides CSL code to read core status and system configurations
-using the CSL provided for specific core. For CSL code specific to cores
-and peripherals present on your device, please refer to the header files
-provided under ${PDK_INSTALL_PATH}\\packages\\ti\\csl\\src\\ip.
-
-A good example of where you may need to access CSL code to read
-core-specific information is on a multi-core device. You can have code
-shared between multiple cores and would like to use a different code
-path or internal buffer based on core ID. The CSL code helps you
-implement this as follows:
-
-For example, if you need to read the core ID on a multi-core DSP device:
-
-::
-
-     uint32_t coreNum;
-     /* Get the core number. */
-     coreNum = CSL_chipReadReg(CSL_CHIP_DNUM);
-
-To do the same on the multi-core A15 device, you can use the following
-code in the A15 CSL:
-
-::
-
-     unsigned int armNum;
-     armNum = CSL_a15ReadCoreId(); //This gets the core ID using the MPIDR in the A15
-
-.. rubric:: How do I find out which CSL header and source files apply to
-   my device?
-   :name: how-do-i-find-out-which-csl-header-and-source-files-apply-to-my-device
-
-The CSL package that is part of the SDK is a unified CSL that covers all
-devices supported by the Processor SDK RTOS. When you link to the CSL
-library or include the header files for a specific IP, the CSL library
-requires users to add a MACRO definition (-D SOC_XX####) to your build
-to indicate which SOC you are using. In order to locate the IP files for
-your device, always look at the header file at the top of the CSL
-directory pdk_<device>_xx_xx_xx\\packages\\ti\\csl and the files that are
-found under the SOC_XX#### corresponds to the SOC that you are using.
-
-SOC-specific files can also be found under the
-pdk_<device>_xx_xx_xx\\packages\\ti\\csl\\soc\\<device_name>
-
-.. rubric:: What is the system memory map used by the SDK examples?
-   :name: what-is-the-system-memory-map-used-by-the-sdk-examples
-
-The TI RTOS-based examples included in the SDK rely on the platform
-definitions provided inside bios_6_xx_xx_xx\\packages\\ti\\platforms for
-partitioning the SOC memory between all the available cores on the SoC.
-Please take a look at the snapshot below for AM572x:
-
-::
-
-    /*  Memory Map for ti.platforms.evmAM572X
-     *
-     *  Virtual     Physical        Size            Comment
-     *  ------------------------------------------------------------------------
-     *              8000_0000  1000_0000  ( 256 MB) External Memory
-     *
-     *  0000_0000 0 8000_0000        100  ( 256  B) --------
-     *              8000_0100       FF00  ( ~64 KB) --------
-     *  0000_0000   8001_0000        100  ( 256  B) --------
-     *              8001_0100       FF00  ( ~64 KB) --------
-     *  0000_0000   8002_0000        100  ( 256  B) --------
-     *              8002_0100       FF00  ( ~64 KB) --------
-     *  0000_0000   8003_0000        100  ( 256  B) --------
-     *              8003_0100    FE_FF00  ( ~16 MB) --------
-     *            1 8100_0000    40_0000  (   4 MB) --------
-     *              8140_0000    C0_0000  (  12 MB) --------
-     *            2 8200_0000    40_0000  (   4 MB) --------
-     *              8240_0000    C0_0000  (  12 MB) --------
-     *            3 8300_0000    40_0000  (   4 MB) --------
-     *              8340_0000    C0_0000  (  12 MB) --------
-     *            4 8400_0000    40_0000  (   4 MB) --------
-     *              8440_0000    C0_0000  (  12 MB) --------
-     *            5 8500_0000   100_0000  (  16 MB) --------
-     *            6 8600_0000   100_0000  (  16 MB) --------
-     *            7 8700_0000   100_0000  (  16 MB) --------
-     *            8 8800_0000   100_0000  (  16 MB) --------
-     *            9 8900_0000   100_0000  (  16 MB) --------
-     *            A 8A00_0000    80_0000  (   8 MB) IPU1 (code, data), benelli
-     *              8A80_0000    80_0000  (   8 MB) IPU2 (code, data), benelli
-     *            B 8B00_0000   100_0000  (  16 MB) HOST (code, data)
-     *            C 8C00_0000   100_0000  (  16 MB) DSP1 (code, data)
-     *            D 8D00_0000   100_0000  (  16 MB) DSP2 (code, data)
-     *            E 8E00_0000   100_0000  (  16 MB) SR_0 (ipc)
-     *            F 8F00_0000   100_0000  (  16 MB) --------
-     */
-
-For bare-metal code, users are required to use a linker command file for
-each of the cores and partition the memory manually so that there is no
-memory overlap in the applications running on each of the cores. For
-bare-metal linker command files, you can refer to the CCS templates for
-`Hello World <Examples_and_Demonstrations.html#no-os-bare-metal-example>`__
-or the linker command file used in the common folder of the the
-diagnostics package.
-
-|
-
-Board Support
-=============
-
-.. rubric:: What steps are involved when creating a new custom board
-   library?
-   :name: what-steps-are-involved-when-creating-a-new-custom-board-library
-
-The board library consolidates all the board-specific information so
-that all the modifications made when moving to a new custom platform
-using the SOC can be made in the source of this library. The following
-steps are involved in creating custom board library:
-
--  **Modify SOC Clock Settings** The core clocks and module clocks used
-   on the custom board library may vary based on the power requirements
-   and external components used on the boards. TI provides `Clock Tree
-   Tools <http://www.ti.com/tool/CLOCKTREETOOL>`__ to simulate the
-   device clocks. We recommend that you test the settings in CCS by
-   creating a GEL file with the modified settings before modifying the
-   source in the board library.
-
--  **Modify SOC DDR:** The board library has the correct DDR
-   initialization sequence to initialize the DDR memory on your board.
-   You may need to make changes to the AC timings, hardware leveling,
-   and DDR PHY configuration, some or all of which may be different than
-   the TI supported platforms. We recommend that you test the settings
-   in CCS by creating a GEL file with the modified settings before
-   modifying the source in the board library.
-
-**Useful DDR Configuration Resources**
-
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| Sitara Resources:                                                                                                                | Keystone Resources:                                                  |
-+==================================================================================================================================+======================================================================+
-| `AM57x EMIF Tools <http://www.ti.com/lit/pdf/sprac36>`_                                                                          | `KeyStone II DDR Guide <http://www.ti.com/lit/pdf/sprabx7>`_         |
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| `AM437x DDR Configuration Guide <http://processors.wiki.ti.com/index.php/AM437x_DDR_Configuration_and_Programming_Guide>`_       | `KeyStone II DDR Debug Guide <http://www.ti.com/lit/pdf/sprac04>`_   |
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-| `AM335x/AM11x EMIF ConfigurationTools <http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips>`_                 | `KeyStoneI DDR Initialization <http://www.ti.com/lit/pdf/sprabl2>`_  |
-+----------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
-
--  **Modify SoC Pin Mux Settings.** The Pin Mux configuration for a
-   particular platform is obtained by creating a .pinmux project for the
-   device using the `TI Pin Mux
-   Tools <http://www.ti.com/tool/PINMUXTOOL>`__ available on ti.com. The
-   output of the tool can be plugged into the board library to modify
-   the default configuration. The default baseline Pin Mux project
-   (boardname.pinmux) is included in the board library for reference.
-
--  **Modify IO Instance and Configuration to Match Use Case:** If your
-   custom board uses an IO instance different from the TI-supported
-   board, the instance needs to be modified in the Pin Mux setup as well
-   as in the board_cfg.h file in
-   pdk_xx_Xx_xx_xx/packages/ti/board/src/<customBoardName>/
-
--  **Modify Files Corresponding to External Board Components:** The
-   custom board may have external components (flash devices, Ethernet
-   PHY, etc.) that are different from the components populated on the
-   TI-supported EVM. These components and their support files need to be
-   added to the
-   pdk_xx_Xx_xx_xx/packages/ti/board/src/<customBoardName>/device path
-   and linked as part of the board library build.
-
-The above steps have been explained in detail in **Section 9** of the
-**`Application Development Using Processor SDK RTOS
-Training <http://training.ti.com/application-development-using-processor-sdk-rtos/index.html>`__**.
-The slides talk about the different aspects of porting Processor SDK 3.0
-to your custom platform, including incorporating custom Pin Mux,
-clocking, peripheral instance, etc.
-
-Adding custom board to the PDK directory structure and build setup is
-described in the article
-`Adding_Custom_Board_Library_Target_to_Processor_SDK_RTOS_makefiles <How_to_Guides.html#adding-custom-board-library-target-to-processor-sdk-rtos-makefiles>`__
-
-.. note::
-   TI evaluation platforms for Sitara Processors usually have board
-   information stored in an EEPROM which checks for revision number and
-   board name which is used to configure the board. When creating a custom
-   platform if you don`t intend to use an EEPROM then we recommend removing
-   code corresponding to Board_getIDInfo in your board library
-
-.. rubric:: Do I need to do any post processing on PDK files generated
-   by Pin Mux Utility?
-   :name: do-i-need-to-do-any-post-processing-on-pdk-files-generated-by-pin-mux-utility
-
-The Pin Mux utility is designed to automate the integration of a
-custom-designed SOC pin map into the board library software. For AM335x,
-AM437x, and K2G devices, the PDK files generated by the utility can be
-integrated into the board library without any manual edits to the files.
-For AM57x users, there are system design-level considerations that
-require the user to manually select IO delay modes for specific
-peripherals, which may require manual intervention before integrating
-with the board library.
-
-An example for modifying the Pin Mux in the board library to modify the
-UART instance on AM335x is provided in the wiki article `Processor SDK
-RTOS
-Customization <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Customization:_Modifying_Board_library_to_change_UART_instance_on_AM335x>`__.
-
-**For More Information:** Refer to `Application Development Using
-Processor SDK RTOS
-Training <http://training.ti.com/application-development-using-processor-sdk-rtos/index.html>`__
-and `Application Notes on AM57xx Pin Multiplexing
-Utilities <http://www.ti.com/lit/pdf/sprac44>`__.
-
-.. rubric:: How can I modify PLL settings in board libraries?
-   :name: how-can-i-modify-pll-settings-in-board-libraries
-
-The SOC board library in the PDK configures the SOC PLL and module clock
-settings to the nominal settings required to be used with the TI
-evaluation platform. If you want to use different clock settings due to
-power consideration, or if you are using a variant of the device that
-needs to be clocked differently, you can enter the PLL and clock
-settings in the board library. All of the PLL and module clock settings
-are consolidated in the following files:
-
--  <Board>.c: Contains calls related to all board-level initialization.
-   <Board> refers to the evaluation platform (For example, evmam335x)
--  <EVM>_pll.c: Defines the Board_PLLInit() function that configures the
-   dividers and multipliers for the clock tree.
--  <EVM>_clock.c: Defines clock dividers, scalars, and multipliers for
-   individual board modules initialized using the board library.
-
-.. rubric:: Can you provide an example of modifying a board library to
-   use a different peripheral instance as compared to the EVM design?
-   :name: can-you-provide-an-example-of-modifying-a-board-library-to-use-a-different-peripheral-instance-as-compared-to-the-evm-design
-
-A good example of the steps involved in modifying a peripheral instance
-is provided in the application note "`Processor SDK RTOS Customization:
-Modifying UART
-Instance <http://www.ti.com/lit/pdf/sprac32>`__"
-
-|
-
-Secondary Bootloader
-====================
-
-.. rubric:: What board initialization is required in the application
-   after booting using the Secondary Boot Loader (SBL)?
-   :name: what-board-initialization-is-required-in-the-application-after-booting-using-the-secondary-boot-loader-sbl
-
-SBL calls the board library to set up the PLL clock, DDR, and Pin Mux,
-and to power on target cores and the I/O peripheral from which it will
-boot the application. Excluding those just mentioned, any other
-configuration need to be done from the application code. As long as you
-have added all of the device initialization to the board library, you
-will not need to add any initialization code in the application.
-
-.. note::
-   For AM57xx devices, the AVS and ABB settings required for all core rails
-   is added to the SBL code, as this initialization is required only in a
-   production environment.
-
-
-.. rubric:: Where do I locate flashing and boot utilities in the
-   package?
-   :name: where-do-i-locate-flashing-and-boot-utilities-in-the-package
-
-The documentation for the booting and flashing of images to EVMs using
-Processor SDK RTOS is provided from the wiki article :ref:`Processor SDK RTOS
-Boot Documentation <FC-Boot-label>`
-
-The :ref:`Boot and Flashing Utilities <FC-Boot-label>`
-for all devices is located in the PDK package under the path
-pdk_<device_name>_x_x_x\\packages\\ti\\boot\\sbl\\tools.
-
-The SDK provides secondary bootloader code for all devices, which is
-loaded by the ROM bootloader. The SBL is responsible for device
-initialization, waking up secondary cores, and deployment of the
-application code on different cores on multi-core devices. On single
-core devices, the SBL is used to manage the device initialization, as
-well as loading and running applications on the device.
-
-Depending on the boot design you need to implement, the boot and
-flashing tools that are used for formatting and booting the SBL can also
-be leveraged to format and boot the application image directly. The
-flash-writing utilities for different EVMs can be located under the path
-pdk_<device_name>_x_x_x\\packages\\ti\\boot\\sbl\\tools\\flashWriter.
-
-If the intent is to restore the KeyStone II EVM to factory settings,
-then the `Program EVM Script <How_to_Guides.html#flash-bootable-images-c66x-k2h-k2e-k2l-only>`__
-enables users to program the flash on the EVM using the pre-built
-firmware images provided by TI/board manufacturer.
-
-.. rubric:: Why my SD card stopped booting with the latest Processor SDK bootloader ?
-   :name: why-my-sd-card-stopped-booting-with-the-latest-processor-sdk-bootloader
-
-The FATFS library of processor SDK expects the SD card FAT partition entry should be
-in a specific format. The SD card may be having a different partition entry than the
-FATFS library that expects to process the media. The user has to reformat the SD card.
-The documentation for formatting the SD card through windows or linux is provided from
-the wiki article **SDK Create SD Card Script** for `Windows <index_overview.html#windows-sd-card-creation-guide>`__
-and `Linux <index_overview.html#tools-create-sd-card-linux-label>`__.
-
-|
-
-Diagnostics
-===========
-
-.. rubric:: How to I test my EVM functionality? Can I use the same tests
-   on my custom platform?
-   :name: how-to-i-test-my-evm-functionality-can-i-use-the-same-tests-on-my-custom-platform
-
-The Processor SDK RTOS provides unit tests to test interfaces on the EVM
-as part of diagnostics package that can be found in the package in the
-path pdk_<device_namme>_x_x_x\\packages\\ti\\board\\diag. It also provides a
-framework to run each of these tests through a command line serial
-interface. Users can either load the tests using an emulator or they can
-load them over an SD card to test the EVM functionality.
-
-These tests, like all other examples in the SDK, rely on the board
-library to perform the SOC and board initialization. So if you have
-modified the board library to account for the components on your custom
-hardware, then you should be able to re-use the diagnostic tests while
-bringing up your custom hardware. Users will link to the new board
-library and rebuild the diagnostics package to leverage these examples
-on the custom hardware.
-
-**How to test Keystone II serdes interface?**
-
-For Keystone II Serdes, there is also a Serdes diagnostics package which can be
-found in the path pdk_k2hk/k2e_x_x_x/packages/ti/diag/serdes_diag. The tests run
-on C66x and cover BER, EYE and PRBS.
-
-For common Keystone I/II Serdes debug, please refer to "`SERDES Link
-Commissioning on KeyStone I and II Devices
-<http://www.ti.com/lit/an/sprac37/sprac37.pdf>`__"
-
-
-Filesystem Support
-==================
-
-.. rubric:: What filesystem support if provided by Processor SDK RTOS ?
-   Can I use UBIFS, RAMFS, or FATFS with TI RTOS when using external
-   non-volatile memory devices?
-   :name: what-filesystem-support-if-provided-by-processor-sdk-rtos-can-i-use-ubifs-ramfs-or-fatfs-with-ti-rtos-when-using-external-non-volatile-memory-devices
-
-Processor SDK RTOS only supports use of FATFS filesystem for some
-devices. For availability of support for your devices check the :ref:`Release
-Notes <processor-sdk-rtos-release-notes>`
-There are numerous examples for using FATFS with USB driver and SD/MMC
-driver in the SDK that you can use for reference. The FATFS-specific
-documentation for Processor SDK RTOS is available in the `FATFS wiki
-section of the Processor SDK RTOS <Device_Drivers.html#fatfs>`__.
-
-.. rubric:: Is Unicode string supported in FATFS?
-   :name: is-unicode-string-supported-in-fatfs
-
-Processor SDK RTOS only supports ANSI string for the path and file names.
-To switch to Unicode support, please: set the _LFN_UNICODE to 1 in the FATFS (ffconf.h)
-and rebuild the FATFS library. Also, Unicode support uses 16-bit WCHAR for CHAR.
-When calling the FATFS APIs (in ff.h), the application needs to pass WCHAR.
-
-|
-
-TI RTOS
-=======
-
-Useful Resources
-----------------
-
--  `SYSBIOS
-   FAQ <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__
--  `Processor_SDK_RTOS:_TI_RTOS_Tips_And_Tricks <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS:_TI_RTOS_Tips_And_Tricks>`__
--  `TI RTOS
-   Worskshop <https://training.ti.com/ti-rtos-workshop-series>`__
--  `SYS/BIOS_with_GCC_(CortexA) <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)>`__
-
-.. rubric:: How do I start writing my TI RTOS application code? Is there
-   any documentation that describes the process?
-   :name: how-do-i-start-writing-my-ti-rtos-application-code-is-there-any-documentation-that-describes-the-process
-
-The typical recommendation is to start a TI RTOS project using the
-predefined templates provided as part of CCS installation and then add
-custom configuration on top of it. CCS allows users to create a TI RTOS
-project with Minimum, Typical, and a set of generic examples, as you can
-see from `Processor SDK RTOS TI RTOS Getting Started
-Examples <index_overview.html#processor-sdk-rtos-getting-started-guide>`__.
-
-Other than that, there is an TI RTOS workshop that addresses different
-features and use cases of TI RTOS with CCS: `Introduction to the TI-RTOS
-Kernel
-Workshop <http://processors.wiki.ti.com/index.php/Introduction_to_the_TI-RTOS_Kernel_Workshop>`__
-
-The TI RTOS component also ships with user documentation that provides
-information on configuring TI RTOS through scripts APIs and also using
-the graphical XGCONF tool. Full online API and module documentation is
-available here: `TI RTOS API
-Documentation <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_46_00_23/exports/bios_6_46_00_23/docs/cdoc/index.html>`__
-
-.. rubric:: What interrupt latency, foot print, etc. can I expect while
-   using TI RTOS?
-   :name: what-interrupt-latency-foot-print-etc.-can-i-expect-while-using-ti-rtos
-
-Performance and size benchmarks are available for every released
-SYS/BIOS kernel in the TI RTOS package and are shipped as part of the
-standard product documentation. In addition to the benchmark numbers
-themselves, .pdf files provide a detailed description of how the
-benchmarks were implemented. For example, whether they were implemented
-in internal or external memory..
-
-If you do not have access to a release, you can access the release notes
-(and thereby the benchmarks) online by clicking on the following link
-and going to the download link for the TI RTOS version that is part of
-the SDK.
-
-- `SYS/BIOS Releases
-  <http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/index.html>`__
-
-This link enables you to access any TI RTOS products and their
-associated release notes. The release notes may be browsed directly.
-There is no need to download the whole product. You will need to have a
-my.ti login to access this site.
-
-Within the SDK package, TI-RTOS Benchmark Documentation can be found
-under directory path
-*bios_6_xx_xx_xx\\packages\\ti\\sysbios\\benchmarks\\doc-files*
-
-.. rubric:: How do I debug TI-RTOS and driver code?
-   :name: how-do-i-debug-ti-rtos-and-driver-code
-
-In order to single step through code, the driver libraries and the TI
-RTOS libraries should be built with complete symbol definition.
-
-For building a debug-able version of TI RTOS, please refer to the
-following article:
-`Making_a_debug-able_Custom_SYSBIOS_Library <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#1_Making_a_debug-able_Custom_SYS.2FBIOS_Library>`__
-
-Processor SDK RTOS drivers are already built with full symbol
-definition. So you should be able to single step into the drivers in the
-CCS IDE environment. **Note**: You may need to add the source of the
-SYS/BIOS and the drivers in the source search path in CCS.
-
-Advanced debug of TI RTOS applications using system analyzer and ROV
-object viewer is described in the `TI RTOS SYSTEM Anlayzer
-wiki <http://processors.wiki.ti.com/index.php/How_is_SYS/BIOS_related_to_System_Analyzer%3F>`__.
-
-|
-
-.. rubric:: How can I run TI RTOS on secondary ARM cores on multi-core
-   ARM devices
-   :name: how-can-i-run-ti-rtos-on-secondary-arm-cores-on-multi-core-arm-devices
-
-Processor SDK RTOS supports multiple device that have multi-core ARM
-like AM572x and Keystone2 devices. In order to run TI RTOS application
-on the secondary ARM core in non-SMP mode, application developers need
-to add correct coreID to the configuration to their BIOS configuration
-to allow the hardware interrupts to be routed to the secondary core.
-
-For example on AM572x which has 2 A15 cores, to run the TI RTOS example
-on secondary ARM core, application users need to add :
-
-::
-
-    var Core = xdc.useModule('ti.sysbios.family.arm.ducati.Core');
-    Core.id = 1;
-
-|
-
-.. rubric:: Why do I get a "undefined reference to
-   \`ti_sysbios_rts_gnu_ReentSupport_checkIfCorrectLibrary'" error when
-   compiling my application?
-   :name: why-do-i-get-a-undefined-reference-to-ti_sysbios_rts_gnu_reentsupport_checkifcorrectlibrary-error-when-compiling-my-application
-
-You may have encountered this error when building an application for ARM
-using makefile and not using CCS. You will need to link in the proper C
-runtime library from SYS/BIOS. Double check the makefile(s) and make
-sure that you are using libc, libgcc, libm, etc. from the SYS/BIOS
-package and not from your toolchain (GCC Linaro).
-
-For additional information, refer to: `What do I need to do to make the
-C runtime library re-entrant when building SYS/BIOS applications for
-Cortex-A GNU
-targets <http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#What_do_I_need_to_do_to_make_the_C_runtime_library_re-entrant_when_building_SYS.2FBIOS_applications_for_Cortex-A_GNU_targets.C2.A0.3F>`__
-
-.. rubric:: Where do I post questions on generic TI RTOS?
-   :name: where-do-i-post-questions-on-generic-ti-rtos
-
-We recommend that all TI RTOS users review the list of TI RTOS
-frequently asked questions on the `TI RTOS
-FAQ <http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs>`__ page
-prior to posting the questions on the E2E forum. If the question is not
-specific to the Processor SDK RTOS drivers, but relates to configuration
-of a specific module inside TI RTOS, then please post the questions on
-the `TI RTOS E2E Forum <https://e2e.ti.com/support/embedded/tirtos/>`__.
-
-.. rubric:: When load a RTOS example to DSP2, the code stuck at timer.c
-   before go main(), but the same worked on DSP1?
-   :name: when-load-a-rtos-example-to-dsp2-the-code-stuck-at-timer.c-before-go-main-but-the-same-worked-on-dsp1
-
-By default, BIOS uses GPtimer5 to source the clock ticks in the BIOS
-clock module. The GEL is created with the assumption that the DSP1
-developers will use GPtimer5 and DSP2 users will use GPtimer6 to source
-clock module. This means that DSP2 developers will need to add
-configuration script to change the clock source to GPtimer6. Try to add
-the following in your DSP2.cfg :
-
-::
-
-     var Clock = xdc.useModule('ti.sysbios.knl.Clock');
-     Clock.timerId = 5; /* Change BIOS clock to GPTimer6 */
-
-|
-
-Networking Support
-==================
-
-.. rubric:: Can I use NDK software stack on all devices supported in
-   Processor SDK RTOS?
-   :name: can-i-use-ndk-software-stack-on-all-devices-supported-in-processor-sdk-rtos
-
-The NDK software stack provided by TI typically requires a transport
-layer called Network Interface Management Unit (NIMU) layer to interface
-the underlying platform software elements and device drivers. Please
-check the :ref:`Processor SDK RTOS Release Notes <processor-sdk-rtos-release-notes>`
-for support of the NIMU transport driver to determine if NDK software
-can be utilized on your device.
-
-.. rubric:: Where do I find the documentation for the NDK stack?
-   :name: where-do-i-find-the-documentation-for-the-ndk-stack
-
-All the networking-related documentation for Processor SDK RTOS, along
-with the NDK software stack, is linked from the wiki `NDK Documentation
-and
-References <http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_NDK#Additional_Documentation_References>`__.
-
-|
-
-Inter-processor Communication (IPC)
-===================================
-
-.. rubric:: How do I build and run IPC examples?
-   :name: how-do-i-build-and-run-ipc-examples
-
-IPC and corresponding examples are designed to be built from the top
-level `Processor SDK RTOS IPC Make Target <Overview.html#additional-targets>`__.
-Please ensure the `Processor SDK RTOS build <Overview.html#additional-targets>`__
-environments have been set up before running the "make ipc_bios" or
-[make ipc_examples] option.
-
-The documentation to run the IPC examples is provided as part of
-ReadMe.txt in the IPC examples or on a device-specific wiki article like
-`How to Run AM57x IPC
-Examples <How_to_Guides.html#run-ipc-examples-on-am572x>`__.
-
-.. rubric:: Where can I locate IPC FAQ document?
-   :name: where-can-i-locate-ipc-faq-document
-
-For IPC-related questions, please refer to the `IPC FAQ wiki
-article <http://processors.wiki.ti.com/index.php/IPC_3.x_FAQ>`__ that
-consolidates the FAQ across all multi-core TI processors.
-
-.. rubric:: How can I run TI RTOS IPC examples on AM57xx devices?
-   :name: how-can-i-run-ti-rtos-ipc-examples-on-am57xx-devices
-
-The instructions to run the IPC examples on AM57xx are provided in the
-wiki article "`Running IPC Examples on
-AM57xx/DRA7xx <How_to_Guides.html#run-ipc-examples-on-am572x>`__"
-
-|
-
-DSP-Optimized Libraries
-=======================
-
-.. rubric:: Why did I encounter a build issue while rebuilding DSPLIB,
-   IMGLIB, or MATHLIB with C6000 CGT 8.x?
-   :name: why-did-i-encounter-a-build-issue-while-rebuilding-dsplib-imglib-or-mathlib-with-c6000-cgt-8.x
-
-This is a known issue. Please refer to the note provided on the
-`Software Libraries
-wiki <http://processors.wiki.ti.com/index.php/Software_libraries#Library_Object_File_Format>`__
-to fix the issue.
-
-.. rubric:: Why does the performance of the DSP Libraries not match with
-   the performance in the documentation?
-   :name: why-does-the-performance-of-the-dsp-libraries-not-match-with-the-performance-in-the-documentation
-
-The performance documented in the optimized DSP libraries that are part
-of the Processor SDK RTOS has been obtained using a C66x simulator
-interface which only works with a flat memory model. In order to obtain
-performance similar to the documentation, the user is expected to
-perform the SOC-specific optimization. This includes placing the data
-buffers in internal DSP memory, using optimized compiler settings in the
-application code, enabling cache if buffers are in DDR memory, enabling
-EDMA for moving data from external memory to L2, etc.
-
-The CSL libraries for the SOC and TI RTOS provide APIs for cache
-management of instruction memory as well as data memory. There are some
-useful documents that enable benchmarking on the DSP and ARM cores.
-
--  `Introduction to DSP
-   Optimization <http://www.ti.com/lit/pdf/sprabf2>`__
--  `TI portal for Core
-   Benchmarking <http://www.ti.com/lsds/ti/processors/technology/benchmarks/core-benchmarks.page>`__
--  `TI DSP Benchmarking Application
-   Report <http://www.ti.com/lit/pdf/sprac13>`__
-
-|
-
-EDMA Library
-============
-
-.. rubric:: How do I resolve EDMA instance usage conflict?
-   :name: how-do-i-resolve-edma-instance-usage-conflict
-
-There are several RTOS driver example projects using EDMA (e.g., PCIE,
-SPI, UART, and MMCSD). These projects typically can run on A15, DSP, or
-M4 cores. As a driver example, these projects use the first EDMA
-instance (EDMA #0), assuming that no others are using it at the system
-level.
-
-There may be an issue if the EDMA instance #0 is already being used in
-the system. For example, if the A15 core runs Linux and uses the EDMA #0
-already, and a user wants to run a Processor SDK RTOS example on C66x
-with default EDMA #0. To resolve such an issue, please choose an unused
-instance. For example, EDMA #1 in the example.
-
-.. rubric:: CCS 7.1 platform can't be verified warning
-   :name: ccs-7.1-platform-cant-be-verified-warning
-
-.. rubric:: When I use CCS 7.1 for Processor SDK RTOS 4.0 projects, I
-   saw a warning "Platform name 'ti.platforms.xxxxxx' could not be
-   verified. Your project may not build as expected."
-   :name: when-i-use-ccs-7.1-for-processor-sdk-rtos-4.0-projects-i-saw-a-warning-platform-name-ti.platforms.xxxxxx-could-not-be-verified.-your-project-may-not-build-as-expected.
-
-The warning shows in Properties---->General of a CCS project in CCS 7.1.
-The warning is due to a change made in CCS 7.1, whereby the User
-Interface tries to verify the project's target/platform name against a
-list of known names and if it cannot be verified then it shows the
-warning. The warning, in itself, does not necessarily mean that the
-target-name is incorrect. Especially in this case where we are looking
-at a known good project, it is likely showing up because the known
-target-names list it is checking against is incomplete. Hence you can
-treat the warning as harmless and ignore it. This causes some confusion
-we have decided to remove the warning in the next release of CCS.
-
-.. rubric:: Keystone I and II devices SGMII/MDIO/PHY
-   :name: keystone-i-and-ii-devices-sgmiimdiophy
-
-.. rubric:: How to setup SGMII interface to a PHY or to another SGMII
-   port without using a PHY?
-   :name: how-to-setup-sgmii-interface-to-a-phy-or-to-another-sgmii-port-without-using-a-phy
-
-There are 3 SGMII connectivity modes: • SGMII port with PHY attached and
-auto-negotiation enabled - for connecting to an external PHY • SGMII
-master to SGMII device with auto-negotiation enabled - this is for
-connecting two SGMII devices, one has to be set as master and the other
-as device • SGMII port to SGMII port with forced link configuration –
-generally this is used when one of the ports does not support
-auto-negotiation
-
-When a device having an SGMII MAC port is connected to a PHY device, the
-SGMII MAC is the device in this link and the PHY is the master. The link
-is established using auto-negotiation across the SGMII link that is
-initiated by the master with an expected response by the device. If the
-auto-negotiation is not initiated by the link master (PHY), the link
-will remain down. In TI Keystone EVMs, the Processor with an SGMII MAC
-port is connected to a PHY, which provides a copper interface to a
-Gigabit RJ-45 connector. The Processor’s SGMII MAC port is configured as
-a device with auto-negotiation enabled. This is done in the Init_SGMII().
-
-When a SGMII MAC port is connected to another SGMII MAC port and
-auto-negotiation is enabled, one must be configured to emulate a master
-while the other is a device. The master port uses the MR_ADV_ABILITY
-register to determine speed and duplex setting instead of the
-MR_LP_ADV_ABILITY register.
-
-Alternately, when an SGMII MAC port is connected to another SGMII MAC
-port and auto-negotiation is not enabled, or not available, a “forced
-link” can be established. Again, the MR_ADV_ABILITY register determines
-the speed and duplex setting. Please refer to the TI KeyStone
-Architecture Gigabit Ethernet (GbE) Switch Subsystem User Guide, section
-3.3, SGMII_CONTROL, MR_ADV_ABILITY and MR_LP_ADV_ABILITY registers for
-detail. The corresponding CSL code is implemented in
-packages\\ti\\csl\\src\\ip\\sgmii\\Vx\\csl_cpsgmiiAux.h.
-
-.. rubric:: In a TI SGMII to FPGA (PHY port) connection, data corruption
-   is observed on egress direction, what could be the cause?
-   :name: in-a-ti-sgmii-to-fpga-phy-port-connection-data-corruption-is-observed-on-egress-direction-what-could-be-the-cause
-
-First to check if the FPGA side is a PHY port or 1000BASE-X media port.
-There are many similarities but they are not identical. It is important
-to recognize that from an electrical point of view, the SGMII interface
-is very similar to the 1000BASE-X interface. Both use 8B/10B encoding, a
-serial interface and an embedded clock. Systems can operate with SGMII
-connected to a media port but they are not guaranteed to operate as they
-are not consistent with the Ethernet standard.
-
-Also, check Rx equalization. Some FPGA may have different choices of
-robust mode (dynamic feedback equalization, aka DFE) or more basic mode
-(linear equalizer). The DFE allows better compensation of transmission
-channel losses by providing a closer adjustment of filter parameters
-than when using a linear equalizer. However, a DFE cannot remove the
-pre-cursor of a transmitted bit; it only compensates for the post
-cursors. Try to use basic mode to see if it helps.
-
-.. rubric:: How do I program the PHY through MDIO interface? I find that
-   TI Init_MDIO() function is empty?
-   :name: how-do-i-program-the-phy-through-mdio-interface-i-find-that-ti-init_mdio-function-is-empty
-
-For some TI EVMs, Init_MDIO() is empty because that PHY is configured
-using pin strapping and no MDIO control is needed to enable it to
-operate through auto-negotiation in the optimum configuration. Sample
-CSL code to access PHY via MDIO can be found under
-packages\\ti\\csl\\src\\ip\\mdio\\Vx\\csl_mdioAux.h. The MDIO user access
-register is used to communicate with the physical transceiver connected
-to the MDIO bus, not to a register of the Keystone SOC MDIO itself. The
-code must be customized for what you want to get or set within the PHY.
-To do this you must set the correct PHY address and then identify PHY
-register that you want to access. Those registers are defined in the PHY
-datasheet, not TI Keystone documents.
-
-After PHY is programmed, the MDIO controller will continue polling the
-PHY periodically for status. The PHY Alive Status Register (ALIVE) and
-PHY Link Status Register (LINK) can be read to monitor this status of
-the PHY and link (please refer to the TI KeyStone Architecture Gigabit
-Ethernet (GbE) Switch Subsystem User Guide, section 3.4).
-
-C++ Build Verification
-=======================
-
-.. rubric:: How do I verify C++ build environment?
-   :name: how-do-i-verify-C++-build-environment
-
-Cpptest application verifies C++ Build environment on the Processor SDK package. It is
-located under the path $(PDK_INSTALL_PATH)/ti/osal/test
-This is a simple application with a print message. The application includes top level header
-files of all components in the PDK package and is built in C++ build environment.
-The header files are included dynamically for AM57xx and K2G platforms and statically
-included for AM335x and AM437x platforms.
-
-.. _platform_supported:
-
-Platforms Supported
---------------------
-
-+----------------+------------------+--------------------------------------------+
-|      SOC       |   BOARD NAMES    |                CORE                        |
-|                |                  +--------+--------+--------+--------+--------+
-|                |                  | a8host | a9host |  a15_0 |  c66x  | ipu1_0 |
-+================+==================+========+========+========+========+========+
-| AM335x         |    evmAM335x     |   X    |        |        |        |        |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    icev2AM335x   |   X    |        |        |        |        |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    iceAMIC110    |   X    |        |        |        |        |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    skAM335x      |   X    |        |        |        |        |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    bbbAM335x     |   X    |        |        |        |        |
-+----------------+------------------+--------+--------+--------+--------+--------+
-| AM437x         |    evmAM437x     |        |   X    |        |        |        |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    idkAM437x     |        |   X    |        |        |        |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    skAM437x      |        |   X    |        |        |        |
-+----------------+------------------+--------+--------+--------+--------+--------+
-| AM57xx         |    idkAM571x     |        |        |    X   |    X   |   X    |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    idkAM572x     |        |        |    X   |    X   |   X    |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    idkAM574x     |        |        |    X   |    X   |   X    |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    evmAM572x     |        |        |    X   |    X   |   X    |
-+----------------+------------------+--------+--------+--------+--------+--------+
-| K2G            |    evmK2G        |        |        |    X   |    X   |        |
-|                +------------------+--------+--------+--------+--------+--------+
-|                |    iceK2G        |        |        |    X   |    X   |        |
-+----------------+------------------+--------+--------+--------+--------+--------+
-
-where,
-
-X - supported
-
-Build Setup
------------
--  For Windows : Download and install `Strawberry Perl <http://strawberryperl.com/download/5.28.0.1/strawberry-perl-5.28.0.1-64bit.msi>`__.
--  For Linux : Execute the command "sudo apt-get -y install perl" at the linux
-   command prompt.
-
-.. note::
-
-   This is an one-time installation and need not be repeated for every build.
-
-Steps to Build
---------------
-The following are the steps to build and test the Cpptest Application.
-
-1. Build the PDK package
-
-.. note::
-
-   Building PDK package completely is neccessary before invoking a build on Cpptest
-   application.
-
-
--  For Windows:
-::
-
-     cd $(PDK_INSTALL_PATH)
-     pdksetupenv.bat
-     gmake all
-
-
--  For Linux:
-::
-
-     cd $(PDK_INSTALL_PATH)
-     source pdksetupenv.sh
-     make all
-
-
-2. Invoke the Cpptest application build, using the following commands.
-
--  For Windows:
-::
-
-     cd ti/osal/test/cpptest
-     gmake BOARD=<board_name>  CORE=<core> CPLUSPLUS_BUILD=yes
-     Example:
-     gmake BOARD=idkAM572x  CORE=a15_0 CPLUSPLUS_BUILD=yes
-
--  For Linux:
-::
-
-     cd ti/osal/test/cpptest
-     make BOARD=<board_name>  CORE=<core> CPLUSPLUS_BUILD=yes
-     Example:
-     make BOARD=idkAM572x  CORE=a15_0 CPLUSPLUS_BUILD=yes
-
-
-Refer section :ref:`platform_supported` for the BOARD and CORE names.
-
-3. Upon successful build, the application binaries are created under
-   $(PDK_INSTALL_PATH)/ti/binary/cpptest/bin/<board_name>
-
-Running the Application
------------------------
-1. Launch CCS and and switch to the Debug Perspective.
-2. Launch the Target configuration and connect to the target.
-3. Load the binaries to the selected core using Run->Load->Load Program.If you need help in CCS setup,
-   refer section `Setup CCS <index_how_to_guides.html#setup-ccs-for-evm-and-processor-sdk-rtos>`__
-   explaining this further.
-4. Launch the serial console utility with the following configurations:
-
-* Baud Rate: 115200
-
-* Data : 8 bits
-
-* Parity : None
-
-* Stop : 1 bit
-
-* Flow Control : None
-
-Verified utilities are Teraterm (Windows) and Minicom (Linux).
-
-5. Run the program in CCS and check for the below output on the serial console:
-
-::
-
-     C++ Build Successful!
-
-
diff --git a/source/rtos/index_how_to_guides.rst b/source/rtos/index_how_to_guides.rst
deleted file mode 100644
index b39390e18..000000000
--- a/source/rtos/index_how_to_guides.rst
+++ /dev/null
@@ -1,158 +0,0 @@
-*************
-Target
-*************
-
-Run IPC Examples on AM572x
-==============================================
-.. include:: How_to_Guides/Target/_Run_IPC_Examples_on_AM572x.rst
-
-Taking the C66x Out Of Reset with Linux Running on the ARM A15
-===============================================================
-.. include:: How_to_Guides/Target/_C66x_Reset_from_A15_Running_Linux.rst
-
-RTOS Customization: using an external input to trigger an interrupt on AM57x
-=======================================================================================================
-.. include:: How_to_Guides/Target/_External_Input_Trigger_Interrupt_AM57x.rst
-
-*************
-Host
-*************
-
-
-Setup
-======
-
-.. Setup CCS for EVM and Processor-SDK RTOS
-.. ------------------------------------------
-.. _Processor-SDK-RTOS-Setup-CCS-label:
-.. include:: How_to_Guides/Host/Setup/_Setup_CCS_for_EVM_and_PSDK_RTOS.rst
-
-
-.. Update environment when installing to a custom path
-.. -----------------------------------------------------
-.. _Processor-SDK-RTOS-Install-In-Custom-Path-label:
-.. include:: How_to_Guides/Host/Setup/_Update_ENV_for_a_Custom_Path.rst
-
-
-Prevent BeagleBone board reset on JTAG Connect
------------------------------------------------
-`<https://elinux.org/Beagleboard:BeagleBone#Board_Reset_on_JTAG_Connect.28A3.2CA4.2CA5.29>`__
-
-
-Rebuild drivers from PDK directory
-------------------------------------
-Refer `Rebuilding the PDK <Overview.html#rebuild-pdk>`__ for details on rebuilding the PDK components.
-
-TI RTOS Basics
-===============
-.. include:: How_to_Guides/Host/Setup/_TI_RTOS_Tips_and_Tricks.rst
-
-
-Flashing and Boot
-==================
-
-Flash bootable images (C66x, K2H/K2E/K2L only)
------------------------------------------------
-.. include:: How_to_Guides/Host/Flashing_and_Boot/_Flash_bootable_images.rst
-
-
-Porting
-==================
-
-Adding Custom Board_Library Target to Processor SDK RTOS makefiles
--------------------------------------------------------------------
-.. include:: How_to_Guides/Host/Porting/_Adding_Custom_Board_Library_Target_to_PSDK_RTOS_makefiles.rst
-
-
-Processor SDK RTOS Porting Guide for AM571x/AM570x Speed Grades
-----------------------------------------------------------------
-.. include:: How_to_Guides/Host/Porting/_PSDK_RTOS_Porting_Guide_for_AM57xx_Speed_Grades.rst
-
-
-System Integration
-===================
-
-Create DSP and IPU firmware using PDK drivers and IPC to load from ARM Linux on AM57xx devices
-------------------------------------------------------------------------------------------------
-.. include:: How_to_Guides/Host/System_Integration/_Create_DSP_and_IPU_FW_using_PDK_and_IPC_to_load_from_ARM_AM57xx.rst
-
-
-Customizing Memory map for creating Multicore Applications on AM57xx using IPC
--------------------------------------------------------------------------------
-`<http://www.ti.com/lit/an/sprac60/sprac60.pdf>`__
-
-IPC Debugging Tools and Techniques on AM57xx
---------------------------------------------
-.. include:: How_to_Guides/Host/System_Integration/_IPC_Debugging_Tools_and_Techniques_on_AM57xx.rst
-
-*******************
-EVM Hardware Setup
-*******************
-
-.. AM65x EVM
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_TMDX654_EVM_Hardware_Setup.rst
-
-.. AM572x GP EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_AM572x_GP_EVM_Hardware_Setup.rst
-
-.. TMDXIDK5728 Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_TMDXIDK5728_Hardware_Setup.rst
-
-.. 66AK2G02 GP EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_66AK2G02_GP_EVM_Hardware_Setup.rst
-
-.. 66AK2G02 ICE EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_66AK2G02_ICE_EVM_Hardware_setup.rst
-
-.. EVMK2E Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_EVMK2E_Hardware_Setup.rst
-
-.. EVMK2H Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_EVMK2H_Hardware_Setup.rst
-
-.. TMDSEVM6657L EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_TMDSEVM6657L_EVM_Hardware_Setup.rst
-
-.. TMDXEVM6670L EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_TMDXEVM6670L_EVM_Hardware_Setup.rst
-
-.. TMDXEVM6678L EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_TMDXEVM6678L_EVM_Hardware_Setup.rst
-
-.. OMAP-L138/C6748 LCDK Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_OMAPL138-C6748_LCDK_Hardware_Setup.rst
-
-.. OMAP-L137 EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_OMAPL137_EVM_Hardware_Setup.rst
-
-.. AM335x ICE EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_ICE_AM335x_Hardware_Setup.rst
-
-.. AMIC110 ICE EVM Hardware Setup
-.. ====================================================
-.. include:: ../common/EVM_Hardware_Setup/_ICE_AMIC110_EVM_Hardware_Setup.rst
-
-
-66AK2G Audio DC AddOn
-====================================================
-
-Please refer to `K2G Audio DC AddOn
-<index_examples_demos.html#k2g-audio-dc-addon>`__
-
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: ../../images/E2e.jpg   | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/rtos/index_overview.rst b/source/rtos/index_overview.rst
deleted file mode 100644
index 9e403b842..000000000
--- a/source/rtos/index_overview.rst
+++ /dev/null
@@ -1,69 +0,0 @@
-.. ************************************
-.. Getting Started Guide
-.. ************************************
-.. _Processor-SDK-RTOS-Getting-Started-Guide-label:
-.. _overview-getting-started-guide:
-.. include:: Overview/_Getting_Started_Guide.rst
-
-.. Create an SD card on Windows host
-.. ======================================
-.. _Tools-Create-SD-Card-Windows-label:
-.. include:: Development_Tools/_Create_SD_Card_Windows.rst
-
-
-.. Create an SD card on Linux host
-.. ======================================
-.. _Tools-Create-SD-Card-Linux-label:
-.. include:: Development_Tools/_Create_SD_Card_Linux.rst
-
-.. _overview-directory-structure:
-
-************************************
-Directory Structure
-************************************
-.. include:: Overview/_Directory_Structure.rst
-
-
-.. _overview-rtos-software-stack:
-
-************************************
-RTOS Software Stack
-************************************
-.. include:: Overview/_Software_Stack.rst
-
-
-.. _overview-building-the-sdk:
-
-*****************
-Building the SDK
-*****************
-.. include:: Release_Specific/_Build_the_SDK.rst
-
-
-.. _overview-related-software:
-
-************************************
-Related Software
-************************************
-.. include:: Overview/_Related_Software.rst
-
-
-.. _overview-technical-support:
-
-.. ************************************
-.. Technical Support
-.. ************************************
-.. _PRSDK-technical-support-label:
-.. include:: /common/Overview/_Processor_SDK_Technical_Support.rst
-
-
-************************************
-Training
-************************************
-- `Training <https://training.ti.com/processor-sdk-training-series>`__
-
-
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+
diff --git a/source/rtos/index_pru_icss_fw.rst b/source/rtos/index_pru_icss_fw.rst
deleted file mode 100644
index 9e887fd39..000000000
--- a/source/rtos/index_pru_icss_fw.rst
+++ /dev/null
@@ -1,35 +0,0 @@
-.. _pru-icss-fw-dual-emac-and-switch:
-
-*********************
-Dual EMAC and Switch
-*********************
-.. include:: PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-EMAC_FIRMWARES.rst
-
-
-*********************
-ICSS-G Dual EMAC
-*********************
-.. include:: PDK_Platform_Software/PRU_ICSS_Drivers/_ICSS-G-EMAC_FIRMWARES.rst
-
-.. _pru-icss-fw-pru-icss-sorte:
-
-*********************
-PRU-ICSS SORTE
-*********************
-.. include:: PDK_Platform_Software/PRU_ICSS_Drivers/_PRU_ICSS_SORTE.rst
-
-.. _pru-icss-fw-pru-icss-i2c:
-
-*************
-PRU-ICSS I2C
-*************
-.. _PRU-ICSS-I2C-FIRMWARE-label:
-.. include:: PDK_Platform_Software/PRU_ICSS_Drivers/_I2C_FIRMWARE.rst
-
-.. _pru-icss-fw-pru-icss-iolink:
-
-***************
-PRU-ICSS IOLINK
-***************
-.. _PRU-ICSS-IOLINK-FIRMWARE-label:
-.. include:: PDK_Platform_Software/PRU_ICSS_Drivers/_IOLINK_FIRMWARE.rst
diff --git a/source/rtos/index_release_specific.rst b/source/rtos/index_release_specific.rst
deleted file mode 100644
index 25cfc5b38..000000000
--- a/source/rtos/index_release_specific.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. ************************************
-.. Release Notes
-.. ************************************
-.. _processor-sdk-rtos-release-notes:
-.. include:: Release_Specific/_Release_Notes.rst
-
-
-.. ************************************
-.. Supported Platforms and Versions
-.. ************************************
-.. _RTOS-SDK-Supported-Platforms:
-.. include:: /common/Release_Specific/_Processor_SDK_Supported_Platforms_and_Versions.rst
-
-
-.. ****************
-.. Migration Guide
-.. ****************
-.. _RTOS-SDK-Migration-Guide-label:
-.. include:: Release_Specific/_Migration_Guide.rst
-
-+--------------------------------+--------------------------------------------------------------------------------------------------+
-| .. Image:: /images/E2e.jpg     | For technical support please post your questions at `http://e2e.ti.com <http://e2e.ti.com/>`__.  |
-+--------------------------------+--------------------------------------------------------------------------------------------------+