2.4. Migration Guide¶

2.4.1. Processor SDK 05.xx Releases¶

am335x-ice-v2.dts: Both ports are CPSW controlled (Board jumpers J18 and J19 at RMII).
am335x-ice-v2-prueth.dts: Both ports are PRUSS controlled (Board jumpers J18 and J19 at MII).

Also note that there is an update to the u-boot env script to select DTB file
name based on jumper settings. So user needs to do following when upgrading
to the latest u-boot from this release:

>env default -a
>saveenv
>reset

2.4.2. Processor SDK 04.xx Releases¶

2.4.3. Processor SDK 03.xx Releases¶

setenv addr_mon 0xc08000
setenv addr_mon_mkimg 0xc07ffc0
setenv mon_size 0x1210
setenv sec_bm_install 'go ${addr_mon}4 0xc084000 ${mon_size}; mon_install ${addr_mon_mkimg}'
run sec_bm_install

2.4.4. Processor SDK 02.xx Releases¶

2.4.5. MCSDK to Processor SDK Migration Guide¶

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.

Installation

As with MCSDK, Processor SDK is also available as an installer on ti.com for download.

Target Machine

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.

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.

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

Processor SDK Linux

This chapter describes what’s changed from a Linux point of view, when migrating from MCSDK to Processor SDK

Directory Structure

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.

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.

U-Boot

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-<soc>-evm.bin to skern-<soc>.bin
  • name_fdt from uImage-<soc>-evm.dtb to <soc>-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 Processor_SDK_Linux_U-Boot_Release_Notes

Linux Kernel

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

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

Kernel Drivers

Listed below are a few major differences from MCSDK (3.10 Kernel).

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.

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

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.

Building the Linux SDK

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

Processor SDK RTOS

Directory Structure

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

Getting Started

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.

Migration from MCSDK (K2x)

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 :
  • <ti/csl/cslr_bcp.h>, <ti/csl/cslr_iqn2.h>, <ti/csl/csl_rac.h>, <ti/csl/csl_tac2.h>, <ti/csl/cslr_aif2.h> and <ti/csl/cslr_pcie.h>
• Deprecated top level cslr_cpsw_5gf.h files - applications including csl 5gf header files would need to migrate to include <ti/csl/csl_cpsw.h> file.

Migration from BIOS-MCSDK (C66x)

CSL

• 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 <ti/csl/csl_cpsw_3gfAux.h> , <ti/csl/csl_cpswAux.h> should be included
  • Instead of <ti/csl/csl_cpsw_3gfssAux.h>, <ti/csl/csl(r)_cpsw_ss_s.h> should be included
  • Instead of <ti/csl/cslr_pcie*.h> needs to be changed to include cslr_pcie.h
  • Instead of <ti/csl/cslr_sgmii.h>, <ti/csl/csl_sgmii.h> include <ti/csl/cslr_cpsgmii.h> and <ti/csl/csl_cpsgmii.h> respectively.
  • Instead of <ti/csl/csl(r)_cpsw_3gf*.h> include <ti/csl/csl(r)_cpsw.h>

CPPI

• Interface with Resource Management (RM) LLD ( Optional )
• Cppi_GlobalConfigParams configuration structure is changed, however there is no change for the applications that include <ti/drv/cppi/device/<soc>/cppi_device.c> file. Applications does not include this directly, need to align the configuration as demonstrated in the cppi_device.c file:

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 <ti/drv/qmss/device/<soc>/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:

PA/SA

• 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.

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.

Common Migration for Both MCSDK and BIOS-MCSDK

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.

MCSDK1.1 to Processor SDK Migration for OMAPL13x devices

For OMAPL13x devices, you can refer to the MCSDK1.1 to Processor SDK Migration link

2.4.6. MCSDK1.1 to Processor SDK Linux Migration Guide for OMAPL13x devices¶

Processor SDK v4.0 release from Texas Instruments adds support for OMAPL13x and aligns the platform software with newer ARM and DSP based SOC’s.

All new development efforts should use Processor SDK. This is the only software package that TI supports on these devices for new development.

Installation

• Processor SDK Linux is available as an installer on ti.com for download

Target Machine

• The Processor SDK Linux installer is available only for 64-bit host machines running Linux. Support for 32-bit machines is dropped primarily due to the Linzro toolchain not supporting 32-bit anymore. Host support for the SDK is described in the Release Notes

Tool Chain

• Processor Linux SDK is using Linaro GCC 6.2-2016.11 cross compiler.

Directory Structure

• The images directory in MCSDK is renamed to prebuilt_images and moved under board_support directory.
• In addition to the prebuilt_images and filesystem, the Linux installer now contains a copy of the Linux Kernel and U-Boot GIT repositories.
• A script create-sdcard.sh is provided in bin directory to create the SD card using prebuilt images in Processor SDK.
• host-tools folder in MCSDK is not included in Processor SDK. Pinmux utility can be downloaded from ti.com. Aisgen utility is replaced by dd command to generate the u-boot ais image.
• For an overview of the directory structure and a brief description of the contents of the folders, please refer to Processor SDK Linux Directory Structure

U-Boot

• Bootz is enabled in u-boot. So use zImage instead of uImage
• A copy of u-boot GIT repo is included in the board-support folder of the Processor SDK installation
• Aisgen utility is not used in Processor SDK to generate the U-Boot ais image, but using dd command:

$ sudo dd if=u-boot.ais of=/dev/sd<N> seek=117 bs=512 conv=fsync

• For more details, refer to Processor SDK U-Boot Release Notes and Processor SDK U-Boot User’s Guide

Linux Kernel

• The Linux kernel is upgraded to 4.9.
• A copy of Kernel GIT repo is included in the board-support folder of the Processor SDK installation
• Kernel is device tree (.dts) based, and not board platform based implementation.
• For more details, refer to Processor SDK Kernel Release Notes and Processor SDK Kernel User’s Guide

Building the Linux SDK

• The Processor SDK Linux can be fully assembled from sources, via Yocto.
• The instructions on how to build the Processor SDK Linux are available in Building the Linux SDK

Inter-Processor Communication (IPC)

• Processor SDK supports IPC 3.x. It is not Syslink based implementation.
• To migrate to IPC 3.x, please refer to IPC 3.x Migration Guide

2.4.7. AMSDK to Processor SDK Migration Guide¶

For many years, the AMSDK has been a great way to get started with Embedded Linux development on TI’s broad market line of ARM Cortex-A microprocessors, also referred to as Sitara. If you go by “what’s in a name?”, you can easily see the connection. The “AM” of AMSDK is the first two letters of part numbers in the Sitara line-up. For example, take the AM335x which is an ARM Cortex-A8 based processor which drives the popular Beaglebone Black board. The “SDK” refers to Software Development Kit. The AMSDK was designed from the ground up to provide a great starting point for developing an embedded Linux system on a Sitara Processor. One of the goals of the AMSDK was to enable a developer to quickly (under 10 minutes) explore and evaluate the possibilities as well as start development on a customized Linux software platform in under an hour. It’s up to each developer to decide if the AMSDK achieved these goals, but the feedback overall has been positive.

Like the Linux kernel itself, which evolves every 77 days or so with a new release, it’s time for the AMSDK 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 AMSDK is being renamed to the Processor SDK for Linux. This new title will allow future devices, which may not carry the “AM” naming convention, to benefit from the same software development experience. Each developer that uses the Processor SDK from project to project can leverage that experience and know with confidence what they can expect.

With this background in place, let’s dig into more specifics.