diff --git a/bin/check_files.py b/bin/check_files.py index 5884cf1d1..2b9f1c0ab 100755 --- a/bin/check_files.py +++ b/bin/check_files.py @@ -6,6 +6,7 @@ Copyright (C) 2025 Texas Instruments Incorporated - https://www.ti.com """ +import argparse import logging import re from pathlib import Path @@ -13,17 +14,18 @@ logger = logging.getLogger(__name__) SOURCE_PATH = Path("source/") -RST_SOURCE = set(SOURCE_PATH.glob("**/*.rst")) +RST_SOURCE = sorted(SOURCE_PATH.glob("**/*.rst")) IGNORED = re.compile(r"([^_].*\.rst)|(version\.txt)") -def get_names(base): - """Get a set of file names to check for, ignoring anything in that matches the IGNORED regex. +def get_paths(base): + """Get a list of paths to check for, ignoring anything with a name that matches the IGNORED + regex. :param base: Pathlib path to directory to search - :return: Set of string path names + :return: List of pathlib paths """ - files_to_check = set() + files_to_check = [] for file in base.glob("**/*"): if file.is_dir(): continue @@ -33,7 +35,7 @@ def get_names(base): logger.debug("Ignored: %s", name) continue - files_to_check.add(name) + files_to_check.append(file) return files_to_check @@ -67,15 +69,46 @@ def check_all(string): return False -def main(): - """Main CLI entrypoint""" - logging.basicConfig(level=logging.INFO) +def get_unused_files(files): + """Get a list of unused files from a subset of files given - files_to_check = get_names(SOURCE_PATH) - for filename in files_to_check: + :param files: List of pathlib paths + :return: List of unused pathlib paths + """ + names_to_check = {x.name for x in files} + unused_names = [] + for filename in names_to_check: if check_all(filename): continue - logging.info("File not used: %s", filename) + + logging.debug("Name not found: %s", filename) + unused_names.append(filename) + + return [x for x in files if x.name in unused_names] + + +def main(): + """Main CLI entrypoint""" + parser = argparse.ArgumentParser( + prog="check_files.py", + description="Tool to verify all files in the tree are in use", + ) + + parser.add_argument("-d", "--delete", action="store_true") + parser.add_argument("-v", "--verbose", action="store_true") + + args = parser.parse_args() + logging.basicConfig(level=logging.DEBUG if args.verbose else logging.INFO) + + files_to_check = get_paths(SOURCE_PATH) + files_unused = get_unused_files(files_to_check) + + for path in files_unused: + if args.delete: + logging.info("Deleting: %s", path) + path.unlink() + else: + logging.warning("File not used: %s", path) if __name__ == "__main__": diff --git a/source/common/EVM_Hardware_Setup/_OMAPL137_EVM_Hardware_Setup.rst b/source/common/EVM_Hardware_Setup/_OMAPL137_EVM_Hardware_Setup.rst deleted file mode 100644 index c64731c42..000000000 --- a/source/common/EVM_Hardware_Setup/_OMAPL137_EVM_Hardware_Setup.rst +++ /dev/null @@ -1,118 +0,0 @@ - -OMAP-L137/C6747 EVM Hardware Setup Guide -======================================== - -Setting up the Hardware ------------------------ - -Follow the steps below to setup the hardware and enable communication -with the EVM. - -.. Note:: The EVM is sensitive to static discharges. Use a grounding strap or other device to prevent damaging the board. Be sure to connect communication cables before applying power to any equipment. - -- Verify that the EVM board's SW2 (Boot) switch is correctly set. The - setting to boot from SPI0 Flash are: - -+----------------+-----+-----+-----+-----+-----+ -| **Pin #** | 7 | 2 | 1 | 0 | 3 | -+================+=====+=====+=====+=====+=====+ -| **Position** | 0 | 1 | 0 | 1 | X | -+----------------+-----+-----+-----+-----+-----+ - -.. Note:: All boot switch modes can be found in the EVM Technical Reference Manual at the link provided under the Additional Resources section. - -- If you want to use networking, connect the Ethernet cable to one of - the Ethernet ports on the EVM board and to an Ethernet network port. - -- Connect the USB cable provided in the kit to the on-board emulation - USB port on the board (EMBED USB). Connect the other end to a - computer with CCS installed. - -- If you plan to use UART port for a console window, connect the RS-232 - null modem cable to the EVM UART port and to the COM port of your - host workstation. - -- Connect the power cable to the EVM power jack on the board. To be ESD - safe, plug in the other end of the power cable only after you have - connected the power cord to the board. - -Connecting to a Console Window --------------------------------- - -You can open a console window that allows you to watch boot and serial -console messages by following these steps: - -1. Connect a serial cable between the serial port on the EVM and the - serial port (for example COM1) on a PC. -2. Run a terminal session (such as Minicom on Linux or TeraTerm on - Windows) on the workstation and configure it to connect to that - serial port with the following characteristics: - - - Bits per Second: 115200 - - Data Bits: 8 - - Parity: None - - Stop Bits: 1 - - Flow Control: None - - Transmit delay: 0 msec/char, 100 msec/line - -**For Linux** - -3. When you power on the EVM, you will see boot sequence messages (If - you have a boot loader in flash). You can press a key to interrupt the boot sequence and type - commands in the U-Boot command shell. - - -Connecting to CCS -------------------- - -.. Note:: CCS versions 9.0 and later are 64-bit applications. Due to this, the on-board Spectrum Digital XDS510USB emulator is not supported. The alternatives are to either stay with CCS 8.3 or earlier, or use an external emulator with CCS 9.0. For example, the low cost XDS110 emulator for $99 (http://www.ti.com/tool/TMDSEMU110-U). - -Target Configuration -^^^^^^^^^^^^^^^^^^^^^^ - -- Open CCS and select New->Target Configuration File. -- Specify a file name or use default. -- Select "Spectrum Digital XDS510USB Emulator" as Connection. **If using CCS 9.0 or later, you will need an external emulator as noted above.** - -.. Image:: /images/OMAPL137_targetConfig.png - - -- Check "OMAPL137" or "C6747" as Device and save. - -.. Tip:: If you don't see "OMAPL137", ensure that you have installed CCS and selected Single Core DSP devices in the installation. - -- Open Target Configuration view in CCS by selecting "Window -> Show - View -> Target Configurations" from menu. -- Select newly created configuration, right-click on it and set it as - default. -- Launch Target configuration file - - - -Connect Target and Load/Run Program -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -- Connecting Target - - - Select "View -> Debug" from menu to start a debug session. - - CCS will switch to Debug perspective with devices DSP and ARM. - - Select device to connect and then go to "Run -> Connect Target" - from menu. - -.. Note:: OMAPL137 is a DSP boot master device. Hence to connect to the ARM, you need to connect the DSP first (even if you do not load anything to DSP), then connect ARM (Reason: DSP’s GEL file enables and wakes up the ARM). - -- Loading Program - - - Choose desired device (DSP or ARM). - - Go to "Run -> Load -> Load Program" from menu. - - Click “Browse” to choose a prebuilt \*.out or click “Browse project..” to choose \*.out of the open projects. - - Choose desired \*.out and click OK. - - -- Running Program - - - Go to "Run -> Resume" - -Additional References -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -EVM Design and Support Files: http://support.spectrumdigital.com/boards/evmomapl137/revg/ diff --git a/source/common/EVM_Hardware_Setup/_TMDSEVM6657L_EVM_Hardware_Setup.rst b/source/common/EVM_Hardware_Setup/_TMDSEVM6657L_EVM_Hardware_Setup.rst deleted file mode 100644 index c19d1c17c..000000000 --- a/source/common/EVM_Hardware_Setup/_TMDSEVM6657L_EVM_Hardware_Setup.rst +++ /dev/null @@ -1,175 +0,0 @@ - -TMDSEVM6657L EVM Hardware Setup Guide -====================================== - - -This page will walk you through setting up your -`TMDSEVM6657L `__ -Evaluation Module (EVM). These guidelines also apply to the L and LE EVM -models. - -.. note:: Some of the steps in this section have been updated from those used in the EVM *Quick Start Guide*. - -Hardware Setup Overview ------------------------ - -The picture below shows the TMDXEVM6657L EVM and the locations of -relevant switches and connectors. - -.. image:: /images/TMDSEVM6657L-image.jpg - - -Hardware Setup Steps --------------------- - -.. note:: 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. - -| - -**1. Attach the Ethernet cable** -Using the Ethernet cable supplied, connect one end of the cable to the -Ethernet port on the EVM and the other end to your PC. - -**2. Connect the JTAG interface** -Use the USB to USB mini-B cable provided. Connect the USB mini-B -connector to the USB mini-B interface on the EVM and the USB connector -to your PC. This enables XDS-100 emulation and is directly useable by -CCS. If you are using a different JTAG, connect it now. - -**3. Verify Endian mode in the SW3 settings** -The Endian mode should be set to Little Endian. SW3 also contains the -boot device settings. - -.. image:: /images/TMD6657LSW3.png - :scale: 60% - -| - -**4. Verify boot mode in the SW3 and SW5 settings** -The boot mode settings below enable NOR boot by loading the boot loader -from EEPROM address 0x51. - -.. image:: /images/TMD6657LSW3-6.png - :scale: 60% - -**5. Set User Switch for the demo application** -The application needs an IP address. It can use either a static IP -address (pre-configured) or it can request one using DHCP. This is -controlled by setting dip switch 2 of SW9. - -| User Switch 2 ON : DHCP -| User Switch 2 OFF: Static IP - -.. image:: /images/TMD6678LSW9.png - :scale: 60% - -**6. Attach the serial port cable** -This EVM can use either a USB serial port or the standard DB-9 (use the -cable shipped with the platform). By default the shunts which control -this on the platforms are set to use the USB by default. We recommend -changing them to use the DB-9 as there are no known issues with this -approach. - -.. image:: /images/TMDXEVM6657L-shunts.jpg - :scale: 70% - -| - -.. image:: /images/TMDXEVM6657LCOMSEL.png - :scale: 70% - -COM\_SEL1: Select UART over 3-Pin Header - -.. note:: If the USB serial port output does not work, ensure that the cable is connected directly to a USB port on the PC/laptop rather than going through an extender or USB hub. - -**7. Connect the power cable** - -Connect the power cable to the EVM power jack on the board. To be ESD -safe, plug in the other end of the power cable only after you have -connected the power cord to the board. Then turn on the board. - -| - -Boot Mode Dip Switch Settings ------------------------------ - -The EVM supports booting image from various devices (EEPROM, NAND or -NOR) via IBL (at I2C address 0x51), I2C EEPROM (at I2C address 0x50), -and ROM Boot modes (such as Ethernet, SRIO, PCIe, SPI etc.) which -address the boot source directly from the ROM code. Below is the table -showing the boot mode dip switch settings for different boot mode that -the EVM supports: - -+--------------------------+--------------------------+--------------------------+ -| Boot Mode | DIP SW3 | DIP SW5 | -| | | | -| | (Pin1, 2, 3, 4, 5, 6, 7, | (Pin1, 2, 3, 4, 5, 6, 7, | -| | 8) | 8) | -+==========================+==========================+==========================+ -| IBL NOR boot on image 0 | (off, off, on, off, on, | (on, on, on, off, on, | -| (default) | on, on, | on, on, on)\ :sup:`4` | -| | on)\ :sup:`1,2,3` | | -+--------------------------+--------------------------+--------------------------+ -| IBL NAND boot on image 0 | (off, off, on, off, on, | (on, on, on, off, on, | -| | off, on, on) | on, on, on) | -+--------------------------+--------------------------+--------------------------+ -| IBL NAND boot on image 1 | (off, off, on, off, off, | (on, on, on, off, on, | -| | off, on, on) | on, on, on) | -+--------------------------+--------------------------+--------------------------+ -| IBL TFTP boot | (off, off, on, off, on, | (on, on, on, off, on, | -| | on, off, on) | on, on, on) | -+--------------------------+--------------------------+--------------------------+ -| I2C POST boot | (off, off, on, off, on, | (on, on, on, on, on, on, | -| | on, on, on) | on, on) | -+--------------------------+--------------------------+--------------------------+ -| ROM SPI Boot\ :sup:`8` | (off, on, off, off, on, | (on, on, off, on, on, | -| | on, on, on) | on, on, on) | -+--------------------------+--------------------------+--------------------------+ -| ROM SRIO Boot\ :sup:`5` | (off, off, on, on, on, | (off, on, on, off, off, | -| | on, off, on) | on, on, on) | -+--------------------------+--------------------------+--------------------------+ -| ROM Ethernet | (off, on, off, on, on, | (on, off, on, off, off, | -| Boot\ :sup:`6` | on, on, off) | on, on, on) | -+--------------------------+--------------------------+--------------------------+ -| ROM PCIE Boot\ :sup:`7` | (off, on, on, off, on, | (on, on, on, off, off, | -| | on, on, on) | on, on, on) | -+--------------------------+--------------------------+--------------------------+ -| No boot | (off, on, on, on, on, | (on, on, on, on, on, on, | -| | on, on, on) | on, on) | -+--------------------------+--------------------------+--------------------------+ - -| **Note:** C6657 currently does not support Image 1 for NOR boot. - -| -| - -**Footnotes:** - -| 1. Pin 1 of SW3 is the endian pin, by default, it is set to off (Little Endian) -| - -| 2. Pin 2-4 of SW3 are the boot mode pins, by default it is set to I2C boot mode (off, on, off) -| - -| 3. Pin 5-8 of SW3 and pin 1-2 of SW5 are the boot parameter index pins for I2C boot (paramter index 0/1 for NOR boot image 0/1, parameter index 2/3 for NAND boot image 0/1, parameter index 4 for TFTP boot). By default, image 0 is programmed to offset byte address 0x0 on NOR, and 0x20000 (block 1 start address) on NAND, image 1 is programmed to offset byte address 0x4000000 on NAND. -| - -| 4. Pin 4 of SW5 is the I2C address pin (off: 0x51, on: 0x50) for I2C boot mode -| - -| 5. This will set the board to boot from SRIO boot mode, with reference clock at 250 MHz, data rate at 3.125 GBs, and lane setup 4-1x ports and DSP System PLL at 100 MHz. -| - -| 6. This will set the board to boot from Ethernet boot mode, with SerDes clock multiplier x 4, core PLL clock at 100 MHz. -| - -| 7. This will set the board to boot form PCIE boot mode, with PCIE in end point mode and DSP System PLL at 100 MHz. -| - -| 8. This will set the board to boot from SPI NOR via the ROM code, with boot-table contents expected in the NOR. 24bit addressing has been set. -| - - -Please refer to *Technical\_Reference\_Manual* for the boot mode -switch settings on the board. - diff --git a/source/common/EVM_Hardware_Setup/_TMDXEVM6670L_EVM_Hardware_Setup.rst b/source/common/EVM_Hardware_Setup/_TMDXEVM6670L_EVM_Hardware_Setup.rst deleted file mode 100644 index 05f2e5fc4..000000000 --- a/source/common/EVM_Hardware_Setup/_TMDXEVM6670L_EVM_Hardware_Setup.rst +++ /dev/null @@ -1,151 +0,0 @@ - -TMDXEVM6670L EVM Hardware Setup -======================================= - -This page will walk you through setting up your -`TMDSEVM6670L `__ -Evaluation Module (EVM). These guidelines also apply to the LE and LXE -EVM models. - -.. note:: Some of the steps in this section have been updated from those used in the EVM *Quick Start Guide*. - -Hardware Setup Overview ------------------------ - -The picture below shows the TMDXEVM6670L EVM and the locations of -relevant switches and connectors. - -.. image:: /images/TMD6670L.jpg - - -Hardware Setup Steps --------------------- - -.. note:: 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. - -| -| **1. Attach the Ethernet cable** -| Using the Ethernet cable supplied, connect one end of the cable to the Ethernet port on the EVM and the other end to your PC. - -| -| **2. Connect the JTAG interface** -| Use the USB to USB mini-B cable provided. Connect the USB mini-B connector to the USB mini-B interface on the EVM and the USB connector to your PC. This enables XDS-100 emulation and is directly useable by CCS. If you are using a different JTAG, connect it now. - -| -| **3. Verify Endian mode in the SW3 settings** -| The Endian mode should be set to Little Endian. SW3 also contains the boot device settings. - -.. image:: /images/TMD6678LSW3.png - :scale: 40% - -| -| **4. Verify boot mode in the SW3 - SW6 settings** -| The boot mode settings below enable NOR boot by loading the boot loader from EEPROM address 0x51. - -.. image:: /images/TMD6678LSW3-6.png - :scale: 40% - -| -| **5. Set User Switch 2 for the demo application** -| The application needs an IP address. It can use either a static IP address (pre-configured) or it can request one using DHCP. This is controlled by setting User Switch 2 to ON for DHCP and OFF for Static. See SW9. - -.. image:: /images/TMD6670LSW9.png - -| -| **6. Attach the serial port cable** -| This EVM can use either a USB serial port or the standard DB-9 (use the cable shipped with the platform). By default the shunts which control this on the platforms are set to use the USB by default. We recommend changing them to use the DB-9 as there are no known issues with this approach. - -| To change the shunts refer to the picture below. - -.. image:: /images/TMD6670LShunts.jpg - -.. note:: If the USB serial port output does not work, ensure that the cable is connected directly to a USB port on the PC/laptop rather than going through an extender or USB hub. - -| -| **7. Connect the power cable** -| Connect the power cable to the EVM power jack on the board. To be ESD safe, plug in the other end of the power cable only after you have connected the power cord to the board. Then turn on the board. - -| - -Boot Mode Dip Switch Settings ------------------------------ - -The EVM supports booting image from various devices (EEPROM, NAND or -NOR) via IBL, it also supports ROM Boot modes, such as Ethernet, SRIO, -PCIe, etc. Below is the table showing the boot mode dip switch settings -for different boot mode that the EVM supports: - -+----------------+----------------+----------------+----------------+----------------+ -| Boot Mode | DIP SW3 | DIP SW4 | DIP SW5 | DIP SW6 | -| | | | | | -| | (Pin1, 2, 3, | (Pin1, 2, 3, | (Pin1, 2, 3, | (Pin1, 2, 3, | -| | 4) | 4) | 4) | 4) | -+================+================+================+================+================+ -| IBL NOR boot | (off, off, on, | (on, on, on, | (on, on, on, | (on, on, on, | -| on image 0 | off)\ :sup:`1, | on)\ :sup:`3` | off)\ :sup:`4` | on) | -| (default) | 2` | | | | -+----------------+----------------+----------------+----------------+----------------+ -| IBL NOR boot | (off, off, on, | (off, on, on, | (on, on, on, | (on, on, on, | -| on image 1 | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| IBL NAND boot | (off, off, on, | (on, off, on, | (on, on, on, | (on, on, on, | -| on image 0 | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| IBL NAND boot | (off, off, on, | (off, off, on, | (on, on, on, | (on, on, on, | -| on image 1 | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| IBL TFTP boot | (off, off, on, | (on, on, off, | (on, on, on, | (on, on, on, | -| | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| I2C POST boot | (off, off, on, | (on, on, on, | (on, on, on, | (on, on, on, | -| | off) | on) | on) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM SPI | (off, on, off, | (on, on, on, | (on, on, off, | (off, on, on, | -| Boot\ :sup:`8` | off) | on) | on) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM SRIO | (off, off, on, | (on, on, on, | (on, off, on, | (off, off, on, | -| Boot\ :sup:`5` | on) | off) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM Ethernet | (off, on, off, | (on, on, on, | (on, off, on, | (off, off, on, | -| Boot\ :sup:`6` | on) | off) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM PCIE | (off, on, on, | (on, on, on, | (on, on, on, | (off, on, on, | -| Boot\ :sup:`7` | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| No boot | (off, on, on, | (on, on, on, | (on, on, on, | (on, on, on, | -| | on) | on) | on) | on) | -+----------------+----------------+----------------+----------------+----------------+ - -| - -**Footnotes:** - -| 1. Pin 1 of SW3 is the endian pin, by default, it is set to off (Little Endian) -| - -| 2. Pin 2-4 of SW3 are the boot mode pins, by default it is set to I2C boot mode (off, on, off) -| - -| 3. Pin 1-4 of SW4 and pin 1-2 of SW5 are the boot parameter index pins for I2C boot (paramter index 0/1 for NOR boot image 0/1, parameter index 2/3 for NAND boot image 0/1, parameter index 4 for TFTP boot). By default, image 0 is programmed to offset byte address 0x0 on NOR, and 0x4000 (block 1 start address) on NAND, image 1 is programmed to offset byte address 0xA00000 on NOR, and 0x2000000 on NAND. -| - -| 4. Pin 4 of SW5 is the I2C address pin (off: 0x51, on: 0x50) for I2C boot mode -| - -| 5. This will set the board to boot from SRIO boot mode, with reference clock at 250 MHz, data rate at 3.125 GBs, and lane setup 4-1x ports and DSP System PLL at 122.88 MHz. -| - -| 6. This will set the board to boot from Ethernet boot mode, with SerDes clock multiplier x 5, DSP System PLL clock at 122.88 MHz. -| - -| 7. This will set the board to boot form PCIE boot mode, with PCIE in end point mode and DSP System PLL at 100 MHz. -| - -| 8. This will set the board to boot from SPI NOR via the ROM code, with boot-table contents expected in the NOR. 24bit addressing has been set. -| -| - -Please refer to -`Technical\_Reference\_Manual `__ -for the boot mode switch settings on the board. - diff --git a/source/common/EVM_Hardware_Setup/_TMDXEVM6678L_EVM_Hardware_Setup.rst b/source/common/EVM_Hardware_Setup/_TMDXEVM6678L_EVM_Hardware_Setup.rst deleted file mode 100644 index 39f49342f..000000000 --- a/source/common/EVM_Hardware_Setup/_TMDXEVM6678L_EVM_Hardware_Setup.rst +++ /dev/null @@ -1,196 +0,0 @@ - -TMDXEVM6678L EVM Hardware Setup Guide -======================================== - -| - -This page will walk you through setting up your `TMDXEVM6678L `__ -Evaluation Module (EVM). These guidelines also apply to the LE and LXE EVM models. - -.. note:: Some of the steps in this section have been updated from those used in the EVM *Quick Start Guide*. - -Hardware Setup Overview ------------------------ - -The picture below shows the TMDXEVM6678L EVM and the locations of -relevant switches and connectors. - -.. image:: /images/TMDXEVM6678L-image.jpg - :scale: 60 % - -| - -.. note:: Please refer to the following picture for the alpha/beta Lite EVM boards. -.. image:: /images/TMD6678L.jpg - - -Hardware Setup Steps --------------------- - -**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. - -| -| **1. Attach the Ethernet cable** - -Using the Ethernet cable supplied, connect one end of the cable to the -Ethernet port on the EVM and the other end to your PC. - -| -| **2. Connect the JTAG interface** - -Use the USB to USB mini-B cable provided. Connect the USB mini-B -connector to the USB mini-B interface on the EVM and the USB connector -to your PC. This enables XDS-100 emulation and is directly useable by -CCS. If you are using a different JTAG, connect it now. - -| -| **3. Verify Endian mode in the SW3 settings** - -The Endian mode should be set to Little Endian. SW3 also contains the -boot device settings. - -| - -.. image:: /images/TMD6678LSW3.png - :scale: 40 % - - -| -| **4. Verify boot mode in the SW3 - SW6 settings** - -The boot mode settings below enable NOR boot by loading the boot loader -from EEPROM address 0x51. - -.. image:: /images/TMD6678LSW3-6.png - :scale: 40 % - -| -| **5. Set User Switch for the demo application** - -The application needs an IP address. It can use either a static IP -address (pre-configured) or it can request one using DHCP. This is -controlled by setting dip switch 2 of SW9. - -| User Switch 2 ON : DHCP -| User Switch 2 OFF: Static IP - -.. image:: /images/TMD6678LSW9.png - :scale: 50 % - -| -| **6. Attach the serial port cable** - -This EVM can use either a USB serial port or the standard DB-9 (use the -cable shipped with the platform). By default the shunts which control -this on the platforms are set to use the USB by default. We recommend -changing them to use the DB-9 as there are no known issues with this -approach. - -.. image:: /images/TMDXEVM6678L-shunts.jpg - -.. note:: If the USB serial port output does not work, ensure that the cable is connected directly to a USB port on the PC/laptop rather than going through an extender or USB hub. - -.. note:: For the shunts on the alpha/beta Lite EVM, please refer to the picture below for the setting -.. image:: /images/TMD6678LShunts.jpg - -| -| **7. Connect the power cable** - -Connect the power cable to the EVM power jack on the board. To be ESD -safe, plug in the other end of the power cable only after you have -connected the power cord to the board. Then turn on the board. - -| - -Boot Mode Dip Switch Settings ------------------------------ - -The EVM supports booting image from various devices (EEPROM, NAND or -NOR) via IBL (at I2C address 0x51), I2C EEPROM (at I2C address 0x50), -and ROM Boot modes (such as Ethernet, SRIO, PCIe, SPI etc.) which -address the boot source directly from the ROM code. Below is the table -showing the boot mode dip switch settings for different boot mode that -the EVM supports: - -+----------------+----------------+----------------+----------------+----------------+ -| Boot Mode | DIP SW3 | DIP SW4 | DIP SW5 | DIP SW6 | -| | | | | | -| | (Pin1, 2, 3, | (Pin1, 2, 3, | (Pin1, 2, 3, | (Pin1, 2, 3, | -| | 4) | 4) | 4) | 4) | -+================+================+================+================+================+ -| IBL NOR boot | (off, off, on, | (on, on, on, | (on, on, on, | (on, on, on, | -| on image 0 | off)\ :sup:`1, | on)\ :sup:`3` | off)\ :sup:`4` | on) | -| (default) | 2` | | | | -+----------------+----------------+----------------+----------------+----------------+ -| IBL NOR boot | (off, off, on, | (off, on, on, | (on, on, on, | (on, on, on, | -| on image 1 | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| IBL NAND boot | (off, off, on, | (on, off, on, | (on, on, on, | (on, on, on, | -| on image 0 | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| IBL NAND boot | (off, off, on, | (off, off, on, | (on, on, on, | (on, on, on, | -| on image 1 | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| IBL TFTP boot | (off, off, on, | (on, on, off, | (on, on, on, | (on, on, on, | -| | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| I2C POST boot | (off, off, on, | (on, on, on, | (on, on, on, | (on, on, on, | -| | off) | on) | on) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM SPI | (off, on, off, | (on, on, on, | (on, on, off, | (on, on, on, | -| Boot\ :sup:`8` | off) | on) | on) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM SRIO | (off, off, on, | (on, on, on, | (on, off, on, | (off, on, on, | -| Boot\ :sup:`5` | on) | off) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM Ethernet | (off, on, off, | (on, on, on, | (on, on, off, | (off, on, on, | -| Boot\ :sup:`6` | on) | off) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| ROM PCIE | (off, on, on, | (on, on, on, | (on, on, on, | (off, on, on, | -| Boot\ :sup:`7` | off) | on) | off) | on) | -+----------------+----------------+----------------+----------------+----------------+ -| No boot | (off, on, on, | (on, on, on, | (on, on, on, | (on, on, on, | -| | on) | on) | on) | on) | -+----------------+----------------+----------------+----------------+----------------+ - -| - -| **Footnotes:** - -1. Pin 1 of SW3 is the endian pin, by default, it is set to off (Little -Endian) - -2. Pin 2-4 of SW3 are the boot mode pins, by default it is set to I2C -boot mode (off, on, off) - -3. Pin 1-4 of SW4 and pin 1-2 of SW5 are the boot parameter index pins -for I2C boot (paramter index 0/1 for NOR boot image 0/1, parameter index -2/3 for NAND boot image 0/1, parameter index 4 for TFTP boot). By -default, image 0 is programmed to offset byte address 0x0 on NOR, and -0x4000 (block 1 start address) on NAND, image 1 is programmed to offset -byte address 0xA00000 on NOR, and 0x2000000 on NAND. - -4. Pin 4 of SW5 is the I2C address pin (off: 0x51, on: 0x50) for I2C -boot mode - -5. This will set the board to boot from SRIO boot mode, with reference -clock at 312.5 MHz, data rate at 3.125 GBs, and lane setup 4-1x ports -and DSP System PLL at 100 MHz. - -6. This will set the board to boot from Ethernet boot mode, with SerDes -clock multiplier x 4, core PLL clock at 100 MHz. - -7. This will set the board to boot form PCIE boot mode, with PCIE in end -point mode and DSP System PLL at 100 MHz. - -8. This will set the board to boot from SPI NOR via the ROM code, with -boot-table contents expected in the NOR. 24bit addressing has been set. - -| - -Please refer to `Technical Reference Manual `__ -for the boot mode switch settings on the board. - diff --git a/source/common/IPC/_IPC_Training.rst b/source/common/IPC/_IPC_Training.rst deleted file mode 100644 index eb76ea7a7..000000000 --- a/source/common/IPC/_IPC_Training.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. http://processors.wiki.ti.com/index.php/IPC_3.x - -`Introduction to Inter-Processor Communication (IPC) for KeyStone and Sitara™ Devices `__ - The IPC software package is designed to hide the lower-layer hardware complexity of multi-core devices and help users to quickly develop applications for data transfer between cores or devices. -IPC also maximizes application software reuse by providing a common API interface across all supported platforms, including AM65x, AM57x, 66AK2Gx, 66AK2Ex, 66AK2Hx, TCI663x, TDA3XX, OMAP-L138, OMAP54XX, DRA7XX, and more. -This training video introduces the IPC features and modules, shows how to build the IPC libraries for your platform, examines the RPMsg framework, and provides a look at the included examples and benchmarks. - -| - -`Building and Running Inter-Processor Communication (IPC) Examples on the AM572x GP EVM `__ - For TI embedded processors with heterogeneous multi-core architectures – like the AM57x family of devices, which have integrated ARM, DSP, and M4 cores – the TI Processor Software Development Kit (SDK) provides a software component called Inter-processor Communication (IPC). -This video demonstrates how to build and run IPC examples on the AM572x General Purpose Evaluation Module (GP EVM) using Processor SDK for Linux. - -| - -IPC Training v2.21 - IPC 3.x Full Training Material :download:`(PowerPoint) ` :download:`(PowerPointShow) ` :download:`(PDF) ` - -| - -IPC Lab 1 - Hello :download:`(PowerPoint) ` :download:`(PowerPointShow) ` :download:`(PDF) ` - -IPC Lab 2 - MessageQ :download:`(PowerPoint) ` :download:`(PowerPointShow) ` :download:`(PDF) ` - -IPC Lab 3 - Scalability :download:`(PowerPoint) ` :download:`(PowerPointShow) ` :download:`(PDF) ` diff --git a/source/common/IPC/_IPC_Transports.rst b/source/common/IPC/_IPC_Transports.rst deleted file mode 100644 index be73b00d1..000000000 --- a/source/common/IPC/_IPC_Transports.rst +++ /dev/null @@ -1,726 +0,0 @@ -.. http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_IPC_Transports - -Introduction ------------------ - -IPC transports are the underlying configurable data paths over shared -memory and hardware resources, which implement the IPC MessageQ APIs. -MessageQ provides a common IPC interface between processors within a -system containing a single or multiple KeyStone devices. Communication -between the processors is enabled through the use of IPC transports. The -transports supplied with the IPC component are shared memory based, -capable of intra-device communication. Additional transports, utilizing -the QMSS and SRIO LLDs, are supplied via Yocto/bitbake for ARMv7 Linux -IPC and PROCSDK PDK for SYS/BIOS DSP IPC, enabling intra-SoC and -inter-SoC communication, respectively. - -The below table gives an overview of the transport offerings, their -location, and the communication path they enable. - -+---------------+--------------+--------------+----------------+-----------------+------------------+ -| **Transport** | **MessageQ | **Location** | **Communication| **Enabled | **Special | -| | Interface | | Route** | Communication | Considerations** | -| | Type** | | | Path** | | -+---------------+--------------+--------------+----------------+-----------------+------------------+ -| Transport | MessageQ | IPC | Shared | SYS/BIOS | There are | -| Shm... | (priority | component | memory | DSP to | multiple | -| | based) | - | | DSP | implementations | -| | | SYS/BIOS | | | of Transport Shm | -| | | subdirect | | | delivered within | -| | | ories | | | the IPC component| -| | | | | | Please see the | -| | | | | | IPC documentation| -| | | | | | provided with the| -| | | | | | component for | -| | | | | | more information | -| | | | | | on these shared | -| | | | | | memory transport | -| | | | | | implementions | -+---------------+--------------+--------------+----------------+-----------------+------------------+ -| Transport | MessageQ | - IPC | Shared | - ARMv7 | MessageQ messages| -| Rpmsg | (priority | component -| memory | Linux to/from | sent over | -| | based) | ARMv7 Linux| | SYS/BIOS DSP | Transport Rpmsg | -| | | subdirect | | | traveling | -| | | ories | | | from/to ARMv7 | -| | | - IPC | | | user space | -| | | component -| | | go through | -| | | SYS/BIOS | | | the Linux kernel | -| | | subdirect | | | before reaching | -| | | ories | | | the DSP. | -| | | - Yocto/ | | | This provides | -| | | bitbake | | | *clean* | -| | | ti-ipc | | | partitioning | -| | | recipe | | | between user | -| | | | | | memory and DSP | -| | | | | | memory. However, | -| | | | | | Transport Rpmsg | -| | | | | | is considered | -| | | | | | a *slow path* | -| | | | | | since the user | -| | | | | | space MessageQ | -| | | | | | messages must be | -| | | | | | copied from/to | -| | | | | | DSP memory by | -| | | | | | kernel and DSP. | -+---------------+--------------+--------------+----------------+-----------------+------------------+ -| SYS/BIOS | Network | PROCSDK | SRIO LLD | - SYS/BIOS | TransportSrio | -| DSP | | RTOS PDK | | DSP to/from | can send MessageQ| -| Transport | | | | SYS/BIOS DSP | messages to ARMv7| -| Srio | | | | (intra and | and DSP | -| | | | | inter-device) | processors on | -| | | | | - SYS/BIOS | remote devices | -| | | | | DSP to/from | in a multiple | -| | | | | ARMv7 Linux | device system. | -| | | | | (intra- and | IPC MultiProc | -| | | | | inter- device)| must be | -| | | | | | configured to be | -| | | | | | aware of all | -| | | | | | processors | -| | | | | | existing on all | -| | | | | | devices and all | -| | | | | | devices must be | -| | | | | | connected over a | -| | | | | | SRIO | -| | | | | | interconnect. | -| | | | | | | -| | | | | | The main | -| | | | | | purpose of | -| | | | | | TransportSrio | -| | | | | | is for | -| | | | | | multi-device | -| | | | | | communication | -| | | | | | over MessageQ. | -| | | | | | The transmission | -| | | | | | latency is | -| | | | | | greater for | -| | | | | | this transport | -| | | | | | due to the | -| | | | | | latter capability| -| | | | | | Therefore it is | -| | | | | | recommended a | -| | | | | | shared memory or | -| | | | | | other LLD-based | -| | | | | | transport | -| | | | | | is used for | -| | | | | | intra-device | -| | | | | | communication | -| | | | | | due to their | -| | | | | | lower latency | -| | | | | | costs. | -+---------------+--------------+--------------+----------------+-----------------+------------------+ -| ARMv7 | Network | Yocto/bit | SRIO LLD | - ARMv7 | TransportSrio | -| Linux | | bake | | Linux to/from | can send | -| Transport | | ti-transp | | ARMv7 Linux | MessageQ messages| -| Srio | | ort-srio | | (intra- and | to ARMv7 and DSP | -| | | recipe | | inter-device) | processors on | -| | | | | - SYS/BIOS | remote devices | -| | | | | DSP to/from | in a multiple | -| | | | | ARMv7 Linux | device system. | -| | | | | (intra- and | IPC MultiProc | -| | | | | inter-device) | must be | -| | | | | | configured to be | -| | | | | | aware of all | -| | | | | | processors | -| | | | | | existing on all | -| | | | | | devices and all | -| | | | | | devices must be | -| | | | | | connected | -| | | | | | over a SRIO | -| | | | | | interconnect. | -| | | | | | | -| | | | | | The main | -| | | | | | purpose of | -| | | | | | TransportSrio | -| | | | | | is for | -| | | | | | multi-device | -| | | | | | communication | -| | | | | | over MessageQ. | -| | | | | | The transmission | -| | | | | | latency is | -| | | | | | greater for | -| | | | | | this transport | -| | | | | | due to the latter| -| | | | | | capability. | -| | | | | | Therefore, it is | -| | | | | | recommended | -| | | | | | a shared memory | -| | | | | | or other | -| | | | | | LLD-based | -| | | | | | transport | -| | | | | | is used for | -| | | | | | intra-device | -| | | | | | communication | -| | | | | | due to their | -| | | | | | lower latency | -| | | | | | costs. | -+---------------+--------------+--------------+----------------+-----------------+------------------+ -| SYS/BIOS | Network | | QMSS LLD | - SYS/BIOS | | -| DSP | | | | DSP to/from | | -| Transport | | | | SYS/BIOS DSP | | -| Qmss | | | | - SYS/BIOS | | -| | | | | DSP to/from | | -| | | | | ARMv7 Linux | | -+---------------+--------------+--------------+----------------+-----------------+------------------+ -| | | | | - ARMv7 Linux | | -| | | | | process | | -| | | | | to process. | | -| | | | | - ARMv7 | | -| | | | | Linux to/from | | -| | | | | SYS/BIOS DSP | | -+---------------+--------------+--------------+----------------+-----------------+------------------+ - -The IPC component (ARMv7 and SYS/BIOS) is available in PROCSDK RTOS and -Linux installations. It will be installed in /ipc_#_##_##_##. Additionally, the IPC component's -ARMv7 source is packaged in a Yocto/bitbake recipe. A user can develop -ARMv7 Linux user-space applications with IPC on Keystone I and KeyStone -II devices by building the ti-ipc package in Yocto. - -Modes of Operation --------------------- - -SYS/BIOS DSP TransportSrio -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following SRIO socket types are supported: - -**TransportSrio_srioSockType_TYPE_9**: In this mode, the SRIO IPC -transport will use Type 9 sockets to communicate with other SRIO IPC -transport endpoints. - -**TransportSrio_srioSockType_TYPE_11**: In this mode, the SRIO IPC -transport will use Type 11 sockets to communicate with other SRIO IPC -transport endpoints. - -ARM Linux TransportSrio -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following SRIO socket types are supported: - -**sock_TYPE_9**: In this mode, the ARM Linux SRIO IPC transport will use -Type 9 sockets to communicate with other SRIO IPC transport endpoints. - -**sock_TYPE_11**: In this mode, the ARM Linux SRIO IPC transport will -use Type 11 sockets to communicate with other SRIO IPC transport -endpoints. - -SYS/BIOS DSP TransportQmss -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following QMSS receive queue types are supported: - -**TransportQmss_queueRcvType_ACCUMULATOR**: In this mode, the QMSS -accumulator logic is used as the reception mechanism for the QMSS -Transport. - -**TransportQmss_queueRcvType_QPEND**: In this mode, a QMSS QPEND (direct -interrupt) queue is used as the reception mechanism for the QMSS -Transport. - -ARM Linux TransportQmss -^^^^^^^^^^^^^^^^^^^^^^^^^ - -A QMSS QPEND queue will always be used as the reception mechanism for -the ARM Linux QMSS Transport. - -Transport Configuration ------------------------- - -SYS/BIOS DSP TransportSrio -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -SRIO SERDES and Lane Configuration -"""""""""""""""""""""""""""""""""""" - -Configuration of the SRIO SERDES and lanes are required before calling -any driver APIs. Examples of the initialization sequences for supported -EVMs are provided in the TransportSrio example folder. The examples call -the SrioDevice_init() API prior to configuring the transport. -SrioDevice_init() reference: - -:: - - ti/transport/ipc/c66/srio/example/src/device_srio.c - -Developers can modify the configurations made in the stock device_srio.c -to change SRIO endpoint IDs, routing information, lane rates, loopback -modes, etc. - -APIs -"""""" - -API reference for application: - -:: - - #include - -ARM Linux TransportSrio -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -SRIO SERDES and Lane Configuration -"""""""""""""""""""""""""""""""""""" - -Configuration of the SRIO SERDES and lanes are required before calling -any driver APIs. Examples of the initialization sequences for supported -EVMs are provided in the TransportSrio test folder. The examples call -the SrioDevice_init() API prior to configuring the transport. -SrioDevice_init() reference from keystone-linux/ipc-transport git -repository: - -:: - - linux/srio/test/[consumer or producer]_device_srio.c - -Developers can modify the configurations made in the stock device_srio.c -to change SRIO endpoint IDs, routing information, lane rates, loopback -modes, etc. - -MPM Transport SRIO Configuration -""""""""""""""""""""""""""""""""" - -TransportSrio leverages MPM Transport in order to manage configuration -of the QMSS, CPPI, and SRIO LLDs. As a result, the transport's -descriptor and descriptor buffer management is pushed to MPM Transport -in the ARM Linux version of TransportSrio. The MPM Transport JSON -configuration file can be modified to change QMSS descriptor and buffer -related parameters. - -The MPM Transport JSON configuration file is located in the Linux file -system at /etc/mpm/mpm_config.json - -APIs -""""" - -API reference for application from keystone-linux/ipc-transport git -repository: - -:: - - #include - -SYS/BIOS DSP TransportQmss -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -APIs -"""""" - -API reference for application: - -:: - - #include - -ARM Linux TransportQmss -^^^^^^^^^^^^^^^^^^^^^^^^^ - -MPM Transport QMSS Configuration -""""""""""""""""""""""""""""""""" - -TransportQmss leverages MPM Transport in order to manage configuration -of the QMSS and CPPI LLDs. As a result, the transport's descriptor and -descriptor buffer management is pushed to MPM Transport in the ARM Linux -version of TransportQmss. The MPM Transport JSON configuration file can -be modified to change QMSS descriptor and buffer related parameters. - -The MPM Transport JSON configuration file is located in the Linux file -system at /etc/mpm/mpm_config.json - -APIs -"""""" - -API reference for application from keystone-linux/ipc-transport git -repository: - -:: - - #include - -Source Delivery and Recompilation ------------------------------------ - -SYS/BIOS DSP TransportSrio -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The SYS/BIOS DSP TransportSrio source code and examples are delivered -within the PROCSDK RTOS PDK component. DSP TransportSrio can be rebuilt -using the environment setup scripts provided with the PDK package. DSP -TransportSrio example applications are created as part of the -pdkProjectCreate scripts. They can be imported and built the same as PDK -LLD example and test CCS projects. - -Recompiling on Windows -""""""""""""""""""""""" - -#. Open a Windows command terminal and navigate to - /packages. -#. Run pdksetupenv.bat - >pdksetupenv.bat -#. Navigate to /packages/ti/transport/ipc/c66/srio/ -#. Build the IPC SRIO Transport library - >gmake - -Issue the following commands if the SRIO transport ever needs to be -rebuilt: - ->gmake clean ->gmake - -Recompiling on Linux -""""""""""""""""""""""" - -#. Open a Linux bash terminal and navigate to - /packages. -#. Run pdksetupenv.sh - $ source pdksetupenv.sh -#. Navigate to /packages/ti/transport/ipc/c66/srio/ -#. Build the IPC SRIO Transport library - $ make - -Issue the following commands if the SRIO transport ever needs to be -rebuilt: - -$ make clean -$ make - -ARM Linux TransportSrio Source Delivery and Recompilation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ARM Linux TransportSrio source code can be downloaded and built two -ways. The transport source code is delivered and built as part of -Yocto/bitbake. The source code can also be downloaded and built directly -from the GIT repository. - -Recompiling Through Yocto/bitbake -"""""""""""""""""""""""""""""""""""" - -#. Follow the instructions in the Exploring section of the user guide to - configure the `Yocto build - environment `__. - The tisdk-server-rootfs-image does not need to be built. Instead look - at the section for `building other - components `__ -#. Build the TransportSrio libraries, ipc-transport-srio recipe, and - user-space tests, ipc-transport-srio-test recipe: - $ MACHINE=k2hk-evm TOOLCHAIN_BRAND=linaro ARAGO_BRAND=mcsdk bitbake - ipc-transport-srio - $ MACHINE=k2hk-evm TOOLCHAIN_BRAND=linaro ARAGO_BRAND=mcsdk bitbake - ipc-transport-srio-test - - .. note:: - The initial build may take quite some time since the kernel is built as a dependency - - .. note:: - Building with just the ipc-transport-srio-test recipe will also build the - ipc-transport-srio recipe since the test recipe depends on the library recipe. - -#. The built TransportSrio static library will be located in - /oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-3.8-oe-linux-gnueabi/ipc-transport-srio//packages-split/ipc-transport-srio-staticdev/usr/lib/libTransportSrio.a - The built TransportSrio shared library will be located in - /oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-3.8-oe-linux-gnueabi/ipc-transport-srio//packages-split/ipc-transport-srio/usr/lib/libTransportSrio.so.1.0.0 -#. The ipc-transport-srio-test recipe will build test static and shared - library executables for all supported devices. The executables will - be located in - base_path>/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-3.8-oe-linux-gnueabi/ipc-transport-srio-test//packages-split/ipc-transport-srio-test/usr/bin/ - -Recompiling Through GIT Repository -""""""""""""""""""""""""""""""""""""" - -Recompiling through the ARM Linux TransportSrio GIT repository requires -that the latest PROCSDK Linux installation. The PROCSDK Linux PDK -component and the Linux devkit must be installed. The Linux devkit -installation script can be found in /procsdk_linux_3_XX_YY_ZZ/linux-devkit/ - -#. Clone the keystone-linux/ipc-transport repository from git.ti.com - $ git clone git://git.ti.com/keystone-linux/ipc-transport.git -#. Navigate to the PROCSDK Linux installation of pdk_3_XX_YY_ZZ/packages - and source armv7setupenv.sh. - - .. note:: - The armv7setupenv.sh script must be modified to - point to the linaro toolchain and installed devkit path - - $ source armv7setupenv.sh - -#. Navigate back to the SRIO transport directory in the ipc-transport - GIT repository - $ cd /ipc-transport/linus/srio -#. Build the TransportSrio library and user-space test executables: - $ make lib - $ make tests -#. The TransportSrio static and shared libraries will be copied directly - into the Linux devkit's /usr/lib folder as long as the devkit install - path was setup correctly prior to running the armv7setupenv.sh script -#. The test executables will be generated in the - /ipc-transport/bin//test/ folder. Only the - device specified in the armv7setupenv.sh will be built. - -.. note:: - Setting the USEDYNAMIC_LIB environment variable to - "yes" will generate the shared library test executables - - $ export USEDYNAMIC_LIB=yes - -SYS/BIOS DSP TransportQmss Source Delivery and Recompilation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The SYS/BIOS DSP TransportQmss source code and examples are delivered -within the PROCSDK RTOS PDK component. DSP TransportQmss can be rebuilt -using the environment setup scripts provided with the PDK package. DSP -TransportQmss example applications are created as part of the -pdkProjectCreate scripts. They can be imported and built the same as PDK -LLD example and test CCS projects. - -Recompiling on Windows -""""""""""""""""""""""" - -#. Open a Windows command terminal and navigate to - /packages. -#. Run pdksetupenv.bat - >pdksetupenv.bat -#. Navigate to /packages/ti/transport/ipc/c66/qmss/ -#. Build the IPC QMSS Transport library - >gmake - -Issue the following commands if the QMSS transport ever needs to be -rebuilt: - ->gmake clean ->gmake - -Recompiling on Linux -"""""""""""""""""""""" - -#. Open a Linux bash terminal and navigate to - /packages. -#. Run pdksetupenv.sh - $ source pdksetupenv.sh -#. Navigate to /packages/ti/transport/ipc/c66/qmss/ -#. Build the IPC QMSS Transport library - $ make - -Issue the following commands if the QMSS transport ever needs to be -rebuilt: - -$ make clean -$ make - -ARM Linux TransportQmss Source Delivery and Recompilation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ARM Linux TransportQmss source code can be downloaded and built two -ways. The transport source code is delivered and built as part of -Yocto/bitbake. The source code can also be downloaded and built directly -from the GIT repository. - -Recompiling Through Yocto/bitbake -"""""""""""""""""""""""""""""""""" - -#. Follow the instructions in the Exploring section of the user guide to - configure the `Yocto build - environment `__. - The tisdk-server-rootfs-image does not need to be built. Instead look - at the section for `building other - components `__ -#. Build the TransportQmss libraries, ipc-transport-qmss recipe, and - user-space tests, ipc-transport-qmss-test recipe: - $ MACHINE=k2hk-evm TOOLCHAIN_BRAND=linaro ARAGO_BRAND=mcsdk bitbake - ipc-transport-qmss - $ MACHINE=k2hk-evm TOOLCHAIN_BRAND=linaro ARAGO_BRAND=mcsdk bitbake - ipc-transport-qmss-test - - .. note:: - The initial build may take quite some time since - the kernel is built as a dependency - - .. note:: - Building with just the ipc-transport-qmss-test - recipe will also build the ipc-transport-qmss recipe since the test - recipe depends on the library recipe. - -#. The built TransportQmss static library will be located in - /oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-3.8-oe-linux-gnueabi/ipc-transport-qmss//packages-split/ipc-transport-qmss-staticdev/usr/lib/libTransportQmss.a - The built TransportQmss shared library will be located in - /oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-3.8-oe-linux-gnueabi/ipc-transport-qmss//packages-split/ipc-transport-qmss/usr/lib/libTransportQmss.so.1.0.0 -#. The ipc-transport-qmss-test recipe will build test static and shared - library executables for all supported devices. The executables will - be located in - base_path>/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-3.8-oe-linux-gnueabi/ipc-transport-qmss-test//packages-split/ipc-transport-qmss-test/usr/bin/ - -Recompiling Through GIT Repository -""""""""""""""""""""""""""""""""""" - -Recompiling through the ARMv7 Linux TransportQmss GIT repository -requires that the latest PROCSDK Linux installation. The PROCSDK Linux -PDK component and the Linux devkit must be installed. The Linux devkit -installation script can be found in /processor_sdk_linux_3_XX_YY_ZZ/linux-devkit/ - -#. Clone the keystone-linux/ipc-transport repository from git.ti.com - $ git clone git://git.ti.com/keystone-linux/ipc-transport.git -#. Navigate to the PROCSDK Linux installation of pdk_3_XX_YY_ZZ/packages - and source armv7setupenv.sh. - - .. note:: - The armv7setupenv.sh script must be modified build - for the correct K2 device, and to point to the linaro toolchain and - installed devkit path - - $ source armv7setupenv.sh - -#. Navigate back to the QMSS transport directory in the ipc-transport - GIT repository - $ cd /ipc-transport/linus/qmss -#. Build the TransportQmss library and user-space test executables: - $ make lib - $ make tests -#. The TransportQmss static and shared libraries will be copied directly - into the Linux devkit's /usr/lib folder as long as the devkit install - path was setup correctly prior to running the armv7setupenv.sh script -#. The test executables will be generated in the - /ipc-transport/bin//test/ folder. Only the - device specified in the armv7setupenv.sh will be built. - -.. note:: - Setting the USEDYNAMIC_LIB environment variable to - "yes" will generate the shared library test executables - - $ export USEDYNAMIC_LIB=yes - -Tests & Examples --------------------- - -SYS/BIOS DSP TransportSrio -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -+-----------------------+-----------------------+-----------------------+ -| Name | Description | Expected Results | -+=======================+=======================+=======================+ -| SYS/BIOS DSP | | Example | | Successful | -| TransportSrio | demonstrating | completion on two | -| Benchmark Example | intra-SoC, DSP to | DSP cores for all | -| | DSP, transport over | example iterations. | -| | SRIO use while also | | -| | measuring latency | | -| | and throughput | | -| | performance. The | | -| | example consists of | | -| | multiple iterations | | -| | where each | | -| | iteration runs SRIO | | -| | with different lane | | -| | configurations. | | -| | Reference example | | -| | for developers | | -+-----------------------+-----------------------+-----------------------+ -| SYS/BIOS DSP | | Example | Successful completion | -| TransportSrio | demonstrates | for all example | -| Producer/Consumer | inter-SoC, DSP to | iterations on two DSP | -| Example | DSP, transport over | cores per producer | -| | SRIO. The example | and consumer devices. | -| | consists of | | -| | multiple iterations | | -| | where each | | -| | iteration runs SRIO | | -| | with different lane | | -| | configurations. | | -+-----------------------+-----------------------+-----------------------+ - -ARM Linux TransportSrio -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -+-----------------------+-----------------------+-----------------------+ -| Name | Description | Expected Results | -+=======================+=======================+=======================+ -| ARM Linux | | Example | Successful completion | -| TransportSrio | demonstrates | for all example | -| Producer/Consumer | inter-SoC, ARM | iterations on two | -| Example | Linux to ARM Linux, | Linux processes per | -| | transport over | producer and consumer | -| | SRIO. The example | devices. | -| | consists of | | -| | multiple iterations | | -| | where each | | -| | iteration runs SRIO | | -| | with different lane | | -| | configurations. | | -+-----------------------+-----------------------+-----------------------+ - -SYS/BIOS DSP TransportQmss -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -+-----------------------+-----------------------+-----------------------+ -| Name | Description | Expected Results | -+=======================+=======================+=======================+ -| SYS/BIOS DSP | | Example | | Successful | -| TransportQmss | demonstrating | completion on two | -| Benchmark Example | intra-SoC, DSP to | DSP cores for all | -| | DSP, transport over | example iterations. | -| | QMSS use while also | | -| | measuring latency | | -| | and throughput | | -| | performance. The | | -| | example consists of | | -| | multiple iterations | | -| | where each | | -| | iteration runs QMSS | | -| | with different | | -| | reception | | -| | mechanisms | | -| | (accumulator or | | -| | QPEND queue). | | -| | Reference example | | -| | for developers | | -+-----------------------+-----------------------+-----------------------+ -| SYS/BIOS DSP | | Tests inter-SoC, | Successful completion | -| TransportQmss | ARM Linux to DSP, | on two DSP cores and | -| DSP-Side of | transport over | two Linux processes. | -| Heterogeneous | QMSS. Reference | | -| Processor Test | test for developers | | -+-----------------------+-----------------------+-----------------------+ - -ARM Linux TransportQmss -^^^^^^^^^^^^^^^^^^^^^^^^^ - -+-----------------------+-----------------------+-----------------------+ -| Name | Description | Expected Results | -+=======================+=======================+=======================+ -| ARM Linux | | Tests Linux | | Successful | -| TransportQmss | inter-process | completion on four | -| Multi-Process Test | communication via | Linux processes. | -| | IPC transport over | | -| | QMSS. Reference | | -| | test for developers | | -+-----------------------+-----------------------+-----------------------+ -| ARM Linux | | Tests inter-SoC, | Successful completion | -| TransportQmss | ARM Linux to DSP, | on two DSP cores and | -| Linux-Side of | transport over | two Linux processes. | -| Heterogeneous | QMSS. Reference | | -| Processor Test | test for developers | | -+-----------------------+-----------------------+-----------------------+ - -Additional References ------------------------ - -+-----------------------------------+-----------------------------------+ -| **Document** | **Location** | -+-----------------------------------+-----------------------------------+ -| TransportQmss API Reference | $(TI_PDK_INSTALL_DIR)/packages/ti | -| Manual | /transport/ipc/c66/qmss/docs/doxy | -| | gen/html/index.html | -+-----------------------------------+-----------------------------------+ -| TransportQmss Release Notes | $(TI_PDK_INSTALL_DIR)/packages/ti | -| | /transport/ipc/c66/qmss/docs/Rele | -| | aseNotes_TransportQmss.pdf | -+-----------------------------------+-----------------------------------+ -| TransportSrio API Reference | $(TI_PDK_INSTALL_DIR)/packages/ti | -| Manual | /transport/ipc/c66/srio/docs/doxy | -| | gen/html/index.html | -+-----------------------------------+-----------------------------------+ -| TransportSrio Release Notes | $(TI_PDK_INSTALL_DIR)/packages/ti | -| | /transport/ipc/c66/srio/docs/Rele | -| | aseNotes_TransportSrio.pdf | -+-----------------------------------+-----------------------------------+ - - diff --git a/source/common/Release_Specific/_MCSDK_to_Processor_SDK_Migration.rst b/source/common/Release_Specific/_MCSDK_to_Processor_SDK_Migration.rst deleted file mode 100644 index c10259118..000000000 --- a/source/common/Release_Specific/_MCSDK_to_Processor_SDK_Migration.rst +++ /dev/null @@ -1,469 +0,0 @@ -.. http://processors.wiki.ti.com/index.php/MCSDK_to_Processor_SDK_Migration - -MCSDK to Processor SDK Migration Guide -======================================= - -.. rubric:: Introduction - -For many years, the MCSDK has been a great way to get started with -Embedded Software development on TI's KeyStone architecture processors -(C66x, K2x). If you go by "what's in a name?", you can easily see the -connection. The "MC" of MCSDK stands for Multi-Core and The "SDK" refers -to Software Development Kit. The MCSDK encapsulated a collection of -software elements and tools and was designed to provide a great starting -point for developing embedded applications on ARM running Linux and C66x -cores running TI-RTOS, on KeyStone processors. One of the goals of the -MCSDK was to enable a developer to quickly explore and evaluate the -possibilities as well as start development on a customized Linux/TI-RTOS -software platform. - -Like the Linux kernel itself, which evolves every 77 days or so with a -new release, it's time for the MCSDK to evolve, without departing from -it's heritage. TI has a rich offering of microprocessors from multicore -ARMs to tiny, power-efficient DSPs, and different combinations of ARM, -DSP, and specialized cores to provide the broad market a variety of -solutions. Since many developers will touch several of these devices -from project to project, it is beneficial to standardize the experience -to maximize the benefit of learning. The limited time developers have in -today's time-to-market driven environment is very important and -shouldn't be wasted. - -To this end, the KeyStone devices will be actively supported in the -Processor SDK, the unified SDK for TI processors. This allows suport for -both C66x and K2x in the same SDK, as well as the other AMx processor. -Each developer that uses the Processor SDK from project to project can -leverage that experience and know with confidence what they can expect. -The Processor SDK is more than a collection of components, the aim is -that applications can switch processors with minimal modifications. - -Further, we are seeing different use cases for Linux and RTOS: - -- A fully RTOS based solution with RTOS on Cortex-A cores in addition - to the C66/M4 cores and -- Linux based solutions that need acceleration, but doesn't really need - to get into the programming details of the non Cortex-A cores, and - would just need open programming paradigms such as OpenCL, OpenGL, - GStreamer to accelerate the Linux applications, leveraging TI's - optimized libraries or codecs -- A heterogenous solution of Coretex-A cores running Linux and C66/M4 - cores running RTOS - -To this end, the Processor SDK is split into Processor SDK for RTOS and -Processor SDK for Linux. - -To further customize the experience for developers who typically work on -one device we split the SDK to be a separate installer per device, per -OS. In summary, the contents of MCSDK is now split into Processor SDK -(Linux, RTOS) for K2H/K2K, K2E, and K2L. The devices without ARM -processors, C665x and C667x, only support RTOS. With this background in -place, let's dig into more specifics. - -Processor-SDK 2.0.1 adds support for KeyStone devices from previous SDKs -that are no longer being maintained: - -- **MCSDK**: K2H, K2K, K2E, K2L *(last release: MCSDK 3.1.4)* -- **BIOS-MCSDK**: C665x, C667x *(last release: BIOS-MCSDK 2.1.2)* - -If you are migrating from these SDKs, the notes below will highlight any -changes that are required. - -| - -.. rubric:: Installation - :name: installation - -As with MCSDK, Processor SDK is also available as an installer on ti.com -for download. - -.. rubric:: Target Machine - :name: target-machine-mcsdk-to-procsdk - -The Processor SDK Linux installer is available only for host machines -running Linux, where as the Processor SDK RTOS installer is available -for both Windows and Linux host machines. Please note that the Processor -SDK Linux Installer can be installed only on 64-bit host machines and -the support for 32-bit machines is dropped, primarily due to the Linaro -toolchain not supporting 32-bit anymore. - -.. rubric:: Install Packages - :name: install-packages - -As noted earlier, the installer is now available per device, per OS. If -you work on multiple devices or work on both RTOS and Linux, you'd have -to download multiple installers. - -.. rubric:: Command Line Installation - :name: command-line-installation - -The tool to create the installer was changed from *InstallJammer*, which -was an unsupported open source project, to *InstallBuilder*. If -installing on the command line without any user interaction, the command -option changed from - -:: - - --prefix [INSTALL_PATH] --mode unattended - -to - -:: - - --prefix [INSTALL_PATH] --mode silent - -.. rubric:: Processor SDK Linux - -This chapter describes what's changed from a Linux point of view, when -migrating from MCSDK to Processor SDK - -.. rubric:: Directory Structure - :name: directory-structure-mcsdk-to-procsdk - -In addition to the pre-built images and the filesystem, the installer -now contains a copy of the Linux Kernel and U-Boot GIT repositories, and -the sources for Kernel Modules, which'll be quite handy for reference or -further development. There are additional helper/setup scripts to help -with getting started with the EVMs. For an overview of the directory -structure and a brief description of the contents of the folders, refer -to -`Processor\_SDK\_Linux\_Directory\_Structure -`__. - -.. rubric:: Getting Started - :name: getting-started - -The Getting Started Guide for Processor SDK Linux is -`here `__ -Processor SDK Linux includes a set up script that scripts the necessary -steps to setup the development environment on the host machine. The -setup script verifies that the Linux host is the recommended Ubuntu LTS -version, installs any required host packages, sets up the target -FileSystem installation, NFS setup, TFTP setup, Minicom setup, uboot -setup, Load uboot script and boots the EVM to Linux Prompt. After -installation of the SDK on the Linux host, the setup script should be -run to prepare the host for software development. Some of the tasks -require administrator privileges. The script will prompt you when these -administrator privileges are required. For more details, see -`Processor\_SDK\_Linux\_Setup\_Script -`__. - -The procedure to flash the U-Boot, Kernel and filesystem into the flash -memory on EVM, also known-as program\_evm, is still available, and -documented -`here `__. - -.. rubric:: U-Boot - :name: u-boot-mcsdk-to-procsdk - -U-Boot is upgraded to be based on 2015.07. Listed below are a few major -differences from MCSDK. - -- To Flash u-boot image onto NOR flash, u-boot upgrade command is - changed from burn\_uboot to burn\_uboot\_spi (for SPI NOR boot) and - burn\_uboot\_nand (for NAND boot) -- U-Boot starting address is now at 0x0c00 0000 instead of 0x0c00 1000 - in MCSDK -- bootz is enabled in u-boot. So use zImage instead of uImage -- Following default env variable have been updated. - - - **name\_mon** from skern--evm.bin to skern-.bin - - **name\_fdt** from uImage--evm.dtb to -evm.dtb - - **name\_kern** from keystone-evm.bin to zImage - - **debug\_options** to **ks2\_debug**. This is set to 1 as before - to allow CCS to be connected to DSP core. When the device boots to - Linux, the DSP needs to be loaded with the image and run using - mpmcl command first before the CCS can be connected to DSP cores. - The ks2\_debug is not needed in this case. - -- Following new env variables are introduced to allow use of a firmware - initramfs image so that Linux drivers that requires firmware can get - it from this before rootfs is mounted during the boot up. This is - needed to support NFS for example. - - - **name\_fw\_rd** is set to k2-fw-initrd.cpio.gz - This image is - supplied in the release package and contains K2 SerDes and QMSS - Accumulator firmwares that are required by NetCP and PCIe drivers - - init scripts are modified to include this firmware during boot and - pass it to kernel using 2nd argument of bootz command. - -- A copy of Kernel GIT repo is included in the "board-support" folder - of the Processor SDK Installation -- For more details, refer to the :ref:`Processor SDK Linux U-Boot Release Notes - ` - -.. rubric:: Linux Kernel - :name: linux-kernel-mcsdk-to-procsdk - -The Linux Kernel is upgraded to 4.1 (2015 LTS). Listed below are a few -major differences from MCSDK (3.10 Kernel). - -- Firmware is now not built into the Kernel. Instead they are available - in the k2-fw-initrd.cpio.gz initramfs which are passed from u-boot to - kernel as part of the bootz command for drivers that requires them - very early in the boot up before the final rootfs is available. -- Other firmwares that are used by dynamic modules are available in - lib/firmware folder of the supplied file system images (for ubifs, - initramfs etc) so that they are loaded and used by the driver from - the user space. -- A copy of Kernel GIT repo is included in the "board-support" folder - of the Processor SDK Installation -- For more details, refer to the - `Processor\_SDK\_Linux\_Kernel\_Release\_Notes `__ - and - `Processor\_SDK\_Linux\_Kernel\_Performance\_Guide `__ - -.. rubric:: Roadmap - :name: roadmap - -Following features supported in MCSDK are not supported in Processor SDK -02.00.02 Release, and will get added in future Processor SDK releases - -- Drivers: UDMA, 10G-KR firmware, IPSec inflow, kexec, network bonding - -| - -.. rubric:: Kernel Drivers - :name: kernel-drivers - -Listed below are a few major differences from MCSDK (3.10 Kernel). - -.. rubric:: NetCP Drivers - :name: netcp-drivers - -- Netcp qmss and pkt dma drivers at drivers/soc/ti -- In older kernel, firmwares used to be built into the kernel as an - ihex file which is not right thing to do due to licensing issues. Per - community accepted practice, the right thing to do is to have the - firmware images in a file system and use request\_firmware() API in - kernel to load it from the file system and use. So with this kernel - release, this is how firmware files are used in kernel drivers. -- The Accumulator channels requires the QMSS Accumulator firmware - (ks2\_qmss\_pdsp\_acc48.bin) that is located in the - k2-fw-initrd.cpio.gz. -- Netcp net driver at the same location as before at - drivers/net/ethernet/ti/, but files are renamed with netcp\_ prefix -- DT documentation for the above drivers is under - Documentation/devicetree/bindings/ folder. -- PA firmwares are now part of the k2-fw-initrd.cpio.g image that is - used for early boot. PA firmwares in Linux includes a header + - Firmware bloab from the PA LLD package. See kernel source directory - Documentation/arm/keystone/netcp-pa.txt for details of the header - format. -- Sysfs command file name paths have changed in this release. Please - refer the NetCP User Guide for details. -- QoS firmware is part of k2-fw-initrd.cpio.gz. -- QoS qmss driver is implemented in drivers/soc/ti/knav\_qmss\_qos.c. -- Cpts driver for Keystone is implemented in - drivers/net/ethernet/ti/netcp\_cpts.c, which corresponds to the - cpts.c in MCSDK release. -- Keystone sideband crypto driver uses the firmware file: sa\_mci.fw - which is different from that on older kernels. In older kernel, there - is an array named sa\_eng\_aes\_enc\_mci\_tbl, which contains a set - of micro instructions per algorithm for the SA hardware. This is now - captured in a firmware file called sa\_mci.fw and used in the driver. -- Multicast filters for special handling of multicast packets to avoid - duplication are now not enabled through DT as in MCSDK. Instead a - sysfs entry is provided for the same. See - Documentation/networking/keystone-netcp.txt for details. - -.. rubric:: K2 SerDes drivers - :name: k2-serdes-drivers - -- K2 SerDes driver is located at drivers/phy/phy-keystone-serdes.c. It - supports 3 serdes modes. PCIe, 1G and 10G. -- The following firmwares are required for proper functioning of the - driver: - - - ks2\_gbe\_serdes.bin - for 1G - - ks2\_xgbe\_serdes.bin - for 10G - - ks2\_pcie\_serdes.bin - for PCIe - -- These firmwares have configuration values which otherwise were - embedded in the driver code in v3.10.x based kernel releases -- These firmwares are available in the file systems and - k2-fw-initrd.cpio.gz file supplied in the release package and - referred in the u-boot section of this document - -| - -.. rubric:: PCIe driver - :name: pcie-driver - -- PCIe RC mode was set in Kernel in MCSDK but moved to U-boot in - ProcSDK for upstreaming reason. U-boot needs to be the same release - version as Kernel. If not, PCIe mode initialization needs to be added - in the older version of u-boot. - - -.. rubric:: Building the Linux SDK - :name: building-the-linux-sdk-mcsdk-to-procsdk - -As with MCSDK, the Processor SDK Linux can be fully assembled from -sources, via Yocto. This gives the ability for customers to easily add -or remove components from the default filesystem(s) provided in the -Processor SDK Linux Installer. The instructions on how to build the -Processor SDK Linux are available -`here `__ - -| - -.. rubric:: Processor SDK RTOS - -.. rubric:: Directory Structure - :name: directory-structure-1 - -Information on the Processor-SDK RTOS directory structre is -`here `__. -Some modifications were made to be consistent across all devices: - -C66x - -- **SDK folder** is per device. So, there is one for C665x and one for - C667x. -- **IBL**, **POST**, and **boot utilities** moved from SDK folder - ``tools`` to PDK folder ``packages/ti/boot`` -- **NDK examples** moved from SDK folder ``examples/ndk`` to PDK folder - ``packages/ti/transport/ndk/nimu/example`` -- **program\_evm** flash utility moved from SDK folder - ``tools/program_evm`` to SDK folder ``bin`` - -K2x - -- **SDK and PDK folders** are per device. So, there are separate ones - for K2E, K2H/K2K, and K2L. -- **NDK examples** moved from SDK folder ``examples/ndk`` to PDK folder - ``packages/ti/transport/ndk/nimu/example`` - -.. rubric:: Getting Started - :name: getting-started-1 - -The Processor-SDK RTOS Getting Started Guide is located -`here `__. -As in MCSDK, this is the page to quickly find links for software and -information on setting up hardware. Further information can be found in -the `Developer -Guide `__. -This will look different from the MCSDK documentation since we are now -focusing on how to use the SDK software to quickly create an embedded -application rather than the design of the software. - -.. rubric:: Migration from MCSDK (K2x) - :name: migration-from-mcsdk-k2x - -.. rubric:: CSL - :name: csl - -- Renamed “ti/csl/device” folder to “ti/csl/soc” – hence any include - header files as “ti/csl/device/k2?/src/xxxx.h” needs to be changed to - “ti/csl/soc/k2?/src/xxxx.h” -- One top level include header files per IP replaces multiple CSL files - per IP for the following : - - - , , , - , and - - -- Deprecated top level cslr\_cpsw\_5gf.h files - applications including - csl 5gf header files would need to migrate to include - file. - -.. rubric:: Migration from BIOS-MCSDK (C66x) - :name: migration-from-bios-mcsdk-c66x - -.. rubric:: CSL - :name: csl-1 - -- Following SoC defines are added to support C6657 and C6678 in the - CSL. - - - SOC\_C6657 SOC\_C6678 - -- following files are not supported from the top level CSL folder - (ti/csl) - - - csl\_mpuAux.h, csl\_memprot.h, csl\_memprotAux.h, csl\_pllcAux.h, - csl\_cp\_tracer.h - -- include file changes - - - Instead of , - should be included - - Instead of , - should be included - - Instead of needs to be changed to include - cslr\_pcie.h - - Instead of , include - and respectively. - - Instead of include - - -.. raw:: html - -
- -**NOTE** -Please define appropriate SOC define in the applicatoin when using the -CSL. E.g., SOC\_C6678 or SOC\_C6657 for c6678 and c6657 devices. - -.. raw:: html - -
- -.. rubric:: CPPI - :name: cppi - -- Interface with Resource Management (RM) LLD ( Optional ) -- Cppi\_GlobalConfigParams configuration structure is changed, however - there is no change for the applications that include - /cppi\_device.c> file. Applications does not - include this directly, need to align the configuration as - demonstrated in the cppi\_device.c file: - -.. rubric:: QMSS - :name: qmss - -- Optional RM LLD interface is supported to enable customers to use - Resource manangement. -- Qmss\_GlobalConfigParams configuration structure is changed, however - there is no change for the applications that include - /qmss\_device.c> file. For applications that - does not include this directly, it needs to align the configuration - as demonstrated in the qmss\_device.c file: - -.. rubric:: PA/SA - :name: pasa - -- Support for Resource management (RM LLD) is supported for PA LLD - - Note that this is an optional feature, applications that do not - enable RM would not need to bring in RM LLD. - -.. rubric:: HUA Demonstration - :name: hua-demonstration - -The HUA Demo for C66x in BIOS-MCSDK is no longer supported in -Processor-SDK. Rather, the Image Processing Demo is the common RTOS -demonstration that is supported across all supported devices in the -Processor-SDK for RTOS. This demo will continue to be enhanced with more -capabilities. - -.. rubric:: Common Migration for Both MCSDK and BIOS-MCSDK - :name: common-migration-for-both-mcsdk-and-bios-mcsdk - -.. rubric:: Platform Library - :name: platform-library - -The Platform Library is deprecated and functionality is provided by the -Board Library. For backwards compatibility, Platform Library is provided -in this initial release. But it is planned to be dropped in a future -release. The Board Library is a common API across all devices in the -Processor-SDK. - - -| - -.. rubric:: MCSDK1.1 to Processor SDK Migration for OMAPL13x devices - :name: mcsdk1.1-to-processor-sdk-migration-for-omapl13x-devices - -For OMAPL13x devices, you can refer to the `MCSDK1.1 to Processor SDK -Migration `__ -link diff --git a/source/devices/AM62PX/linux/_Release_Specific_PLL.rst b/source/devices/AM62PX/linux/_Release_Specific_PLL.rst deleted file mode 100644 index e3e06c360..000000000 --- a/source/devices/AM62PX/linux/_Release_Specific_PLL.rst +++ /dev/null @@ -1,40 +0,0 @@ - -PLL Programing Sequence Update To Avoid PLL Instability -======================================================= - -In 10.00 SDK release, PLL programing sequence has been updated to follow the -correct programing sequence to avoid PLL instability. The PLL programing -sequence has been updated in following components of the SDK. - - #. TIFS firmware (ti-linux firmware repo) - #. DM R5 firmware (ti-linux-firmware repo) - #. R5 SPL (u-boot repo) - -SDK 10.0 has all the updated components by default. - -Below section provides information on how to pick up these updates for last -major SDK releases - SDK 09.02. - -SDK 09.02.01.10 ---------------- - -Linux SDK 09.02 was the last SDK release with LTS Kernel version 6.1 and -u-boot version 2024.x. To pick up the PLL updates on top of this SDK, pick the -components listed below when building the u-boot binaries. - - - #. TIFS and DM Firmware - - - Pick up the SDK 10.0 TIFS and DM firmware from tag `10.00.07` of ti-linux-firmware repo - - - https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tag/?h=10.00.07 - - #. U-boot patches for SPL - - - Apply the below patches to u-boot project for getting the PLL driver updates in R5 SPL - - - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2024.04&id=a99fde602fae9efafeaafd57a7f684557f9cd666 - - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2024.04&id=fda88f8bcea30590528930ff9441c6e958da86f5 - -Refer to `SDK 09.02 u-boot build instructions `__ -for more information on building u-boot binaries. diff --git a/source/devices/AM62X/linux/_Release_Specific_PLL.rst b/source/devices/AM62X/linux/_Release_Specific_PLL.rst deleted file mode 100644 index d0560827b..000000000 --- a/source/devices/AM62X/linux/_Release_Specific_PLL.rst +++ /dev/null @@ -1,66 +0,0 @@ - -PLL Programing Sequence Update To Avoid PLL Instability -======================================================= - -In 10.00 SDK release, PLL programing sequence has been updated to follow the -correct programing sequence to avoid PLL instability. The PLL programing -sequence has been updated in following components of the SDK. - - #. TIFS firmware (ti-linux firmware repo) - #. DM R5 firmware (ti-linux-firmware repo) - #. R5 SPL (u-boot repo) - -SDK 10.0 has all the updated components by default. - -Below section provides information on how to pick up these updates for last two -major SDK releases - SDK 08.06 and SDK 09.02. - -SDK 08.06.00.42 ---------------- - -Linux SDK 08.06 was the last SDK release with LTS Kernel version 5.10 and -u-boot version 2021.x. To pick up the PLL updates on top of this SDK, pick the -components listed below when building the u-boot binaries. - - - #. TIFS and DM Firmware - - - Pick up the SDK 10.0 TIFS and DM firmware from tag ``10.00.07`` of ti-linux-firmware repo - - - https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tag/?h=10.00.07 - - #. U-boot patches for SPL - - - Apply the below patches to u-boot project for getting the PLL driver updates in R5 SPL - - - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2021.01&id=bfe8f8b84b1efd6630d9b228325b80631fd9d3c9 - - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2021.01&id=e0a75c313b3d381fce10665e4b09a1318948709a - - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2021.01&id=9afcd2f805c264cead6638bf55db9bab7ab4475b - -Refer to `SDK 08.06 u-boot build instructions `__ -for more information on building u-boot binaries. - - -SDK 09.02.01.10 ---------------- - -Linux SDK 09.02 was the last SDK release with LTS Kernel version 6.1 and -u-boot version 2024.x. To pick up the PLL updates on top of this SDK, pick the -components listed below when building the u-boot binaries. - - - #. TIFS and DM Firmware - - - Pick up the SDK 10.0 TIFS and DM firmware from tag ``10.00.07`` of ti-linux-firmware repo - - - https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tag/?h=10.00.07 - - #. U-boot patches for SPL - - - Apply the below patches to u-boot project for getting the PLL driver updates in R5 SPL - - - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2024.04&id=a99fde602fae9efafeaafd57a7f684557f9cd666 - - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2024.04&id=fda88f8bcea30590528930ff9441c6e958da86f5 - -Refer to `SDK 09.02 u-boot build instructions `__ -for more information on building u-boot binaries. diff --git a/source/devices/AM64X/linux/_Release_Specific_PLL.rst b/source/devices/AM64X/linux/_Release_Specific_PLL.rst deleted file mode 100644 index facdcfa80..000000000 --- a/source/devices/AM64X/linux/_Release_Specific_PLL.rst +++ /dev/null @@ -1,51 +0,0 @@ - -PLL Programing Sequence Update To Avoid PLL Instability -======================================================= - -In 10.00 SDK release, PLL programing sequence has been updated to follow the -correct programing sequence to avoid PLL instability. The PLL programing -sequence has been updated in following components of the SDK. - - #. DMSC firmware (ti-linux firmware repo) - -SDK 10.0 has all the updated components by default. - -Below section provides information on how to pick up these updates for last two -major SDK releases - SDK 08.06 and SDK 09.02. - -SDK 08.06.00.42 ---------------- - -Linux SDK 08.06 was the last SDK release with LTS Kernel version 5.10 and -u-boot version 2021.x. To pick up the PLL updates on top of this SDK, pick the -components listed below when building the u-boot binaries. - - - #. DMSC Firmware - - - Pick up the SDK 10.0 DMSC firmware from tag ``10.00.07`` of ti-linux-firmware repo - - - https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tag/?h=10.00.07 - - -Refer to `SDK 08.06 u-boot build instructions `__ -for more information on building u-boot binaries. - - -SDK 09.02.01.10 ---------------- - -Linux SDK 09.02 was the last SDK release with LTS Kernel version 6.1 and -u-boot version 2024.x. To pick up the PLL updates on top of this SDK, pick the -components listed below when building the u-boot binaries. - - - #. DMSC Firmware - - - Pick up the SDK 10.0 DMSC firmware from tag ``10.00.07`` of ti-linux-firmware repo - - - https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tag/?h=10.00.07 - - -Refer to `SDK 09.02 u-boot build instructions `__ -for more information on building u-boot binaries. diff --git a/source/files/IPC_Lab_1_Hello.pdf b/source/files/IPC_Lab_1_Hello.pdf deleted file mode 100644 index fe88cc0fc..000000000 Binary files a/source/files/IPC_Lab_1_Hello.pdf and /dev/null differ diff --git a/source/files/IPC_Lab_1_Hello.ppsx b/source/files/IPC_Lab_1_Hello.ppsx deleted file mode 100644 index 3e7e68396..000000000 Binary files a/source/files/IPC_Lab_1_Hello.ppsx and /dev/null differ diff --git a/source/files/IPC_Lab_1_Hello.pptx b/source/files/IPC_Lab_1_Hello.pptx deleted file mode 100644 index 799153a22..000000000 Binary files a/source/files/IPC_Lab_1_Hello.pptx and /dev/null differ diff --git a/source/files/IPC_Lab_2_MessageQ.pdf b/source/files/IPC_Lab_2_MessageQ.pdf deleted file mode 100644 index 448cfecbf..000000000 Binary files a/source/files/IPC_Lab_2_MessageQ.pdf and /dev/null differ diff --git a/source/files/IPC_Lab_2_MessageQ.ppsx b/source/files/IPC_Lab_2_MessageQ.ppsx deleted file mode 100644 index 5042ad266..000000000 Binary files a/source/files/IPC_Lab_2_MessageQ.ppsx and /dev/null differ diff --git a/source/files/IPC_Lab_2_MessageQ.pptx b/source/files/IPC_Lab_2_MessageQ.pptx deleted file mode 100644 index df6e53f19..000000000 Binary files a/source/files/IPC_Lab_2_MessageQ.pptx and /dev/null differ diff --git a/source/files/IPC_Lab_3_Scalability.pdf b/source/files/IPC_Lab_3_Scalability.pdf deleted file mode 100644 index 6ee6302b8..000000000 Binary files a/source/files/IPC_Lab_3_Scalability.pdf and /dev/null differ diff --git a/source/files/IPC_Lab_3_Scalability.ppsx b/source/files/IPC_Lab_3_Scalability.ppsx deleted file mode 100644 index 1f4c63eec..000000000 Binary files a/source/files/IPC_Lab_3_Scalability.ppsx and /dev/null differ diff --git a/source/files/IPC_Lab_3_Scalability.pptx b/source/files/IPC_Lab_3_Scalability.pptx deleted file mode 100644 index eb3f30c84..000000000 Binary files a/source/files/IPC_Lab_3_Scalability.pptx and /dev/null differ diff --git a/source/files/IPC_Training_2_21.pdf b/source/files/IPC_Training_2_21.pdf deleted file mode 100644 index 28461ac5c..000000000 Binary files a/source/files/IPC_Training_2_21.pdf and /dev/null differ diff --git a/source/files/IPC_Training_2_21.ppsx b/source/files/IPC_Training_2_21.ppsx deleted file mode 100644 index dbbc609b5..000000000 Binary files a/source/files/IPC_Training_2_21.ppsx and /dev/null differ diff --git a/source/files/IPC_Training_2_21.pptx b/source/files/IPC_Training_2_21.pptx deleted file mode 100644 index 0f9b8755e..000000000 Binary files a/source/files/IPC_Training_2_21.pptx and /dev/null differ diff --git a/source/images/Jailhouse.png b/source/images/Jailhouse.png deleted file mode 100644 index ed2b2c446..000000000 Binary files a/source/images/Jailhouse.png and /dev/null differ diff --git a/source/images/OMAPL137_targetConfig.png b/source/images/OMAPL137_targetConfig.png deleted file mode 100644 index 5e9ac7c25..000000000 Binary files a/source/images/OMAPL137_targetConfig.png and /dev/null differ diff --git a/source/images/TMD6657LSW3-6.png b/source/images/TMD6657LSW3-6.png deleted file mode 100644 index 07ddb4f3a..000000000 Binary files a/source/images/TMD6657LSW3-6.png and /dev/null differ diff --git a/source/images/TMD6657LSW3.png b/source/images/TMD6657LSW3.png deleted file mode 100644 index 358375d98..000000000 Binary files a/source/images/TMD6657LSW3.png and /dev/null differ diff --git a/source/images/TMD6670L.jpg b/source/images/TMD6670L.jpg deleted file mode 100644 index 6d0215ef3..000000000 Binary files a/source/images/TMD6670L.jpg and /dev/null differ diff --git a/source/images/TMD6670LSW9.png b/source/images/TMD6670LSW9.png deleted file mode 100644 index 62bfb142a..000000000 Binary files a/source/images/TMD6670LSW9.png and /dev/null differ diff --git a/source/images/TMD6670LShunts.jpg b/source/images/TMD6670LShunts.jpg deleted file mode 100644 index 96220734a..000000000 Binary files a/source/images/TMD6670LShunts.jpg and /dev/null differ diff --git a/source/images/TMD6678L.jpg b/source/images/TMD6678L.jpg deleted file mode 100644 index e3893f630..000000000 Binary files a/source/images/TMD6678L.jpg and /dev/null differ diff --git a/source/images/TMD6678LSW3-6.png b/source/images/TMD6678LSW3-6.png deleted file mode 100644 index 0f5717ab7..000000000 Binary files a/source/images/TMD6678LSW3-6.png and /dev/null differ diff --git a/source/images/TMD6678LSW3.png b/source/images/TMD6678LSW3.png deleted file mode 100644 index 7181b43b8..000000000 Binary files a/source/images/TMD6678LSW3.png and /dev/null differ diff --git a/source/images/TMD6678LSW9.png b/source/images/TMD6678LSW9.png deleted file mode 100644 index baf7c4c10..000000000 Binary files a/source/images/TMD6678LSW9.png and /dev/null differ diff --git a/source/images/TMD6678LShunts.jpg b/source/images/TMD6678LShunts.jpg deleted file mode 100644 index 6d545acf6..000000000 Binary files a/source/images/TMD6678LShunts.jpg and /dev/null differ diff --git a/source/images/TMDSEVM6657L-image.jpg b/source/images/TMDSEVM6657L-image.jpg deleted file mode 100644 index 129409c0c..000000000 Binary files a/source/images/TMDSEVM6657L-image.jpg and /dev/null differ diff --git a/source/images/TMDXEVM6657L-shunts.jpg b/source/images/TMDXEVM6657L-shunts.jpg deleted file mode 100644 index bc08fad34..000000000 Binary files a/source/images/TMDXEVM6657L-shunts.jpg and /dev/null differ diff --git a/source/images/TMDXEVM6657LCOMSEL.png b/source/images/TMDXEVM6657LCOMSEL.png deleted file mode 100644 index c839a9ad3..000000000 Binary files a/source/images/TMDXEVM6657LCOMSEL.png and /dev/null differ diff --git a/source/images/TMDXEVM6678L-image.jpg b/source/images/TMDXEVM6678L-image.jpg deleted file mode 100644 index 296d1555b..000000000 Binary files a/source/images/TMDXEVM6678L-image.jpg and /dev/null differ diff --git a/source/images/TMDXEVM6678L-shunts.jpg b/source/images/TMDXEVM6678L-shunts.jpg deleted file mode 100644 index e78a710ed..000000000 Binary files a/source/images/TMDXEVM6678L-shunts.jpg and /dev/null differ