2.4. Migration Guide

Overview

This page covers migration information for applications built on top of the Processor SDK for Linux.

2.4.1. Processor SDK 05.xx Releases

2.4.1.1. Processor SDK 05.03

  • This release is backwards compatible with 05.02 release.

2.4.1.2. Processor SDK 05.02

  • The minimum SD card size is now 16GB when creating an SD card with the default images for Processor SDK Linux.

Multicast Filtering Mask

  • The parameter for setting a multicast filtering mask is now ‘pruss<ID>_port<PORT>_mc_mask’ instead of ‘pruss<ID>_mc_mask’ because support was added to enable per port multicast filtering for Dual EMAC.

ip link command

  • ip link parameter for setting up VLAN tag for HSR/PRP, sv_cfi is renamed to sv_dei.

2.4.1.3. Processor SDK 05.01

  • Introduced AM65x as a new platform. Please refer to release notes for more details

PRUETH Driver

1. debugfs file path has changed

The path for debugfs file has changed to include the PRU-ICSS ID as there could be upto two instances of offloaded hsr/prp prueth driver and so has to distictly identify which instance the debugfs file refers to.

For example, the path for hsr/prp changed from

  • /sys/kernel/debug/prueth-<hsr/prp>/
to
  • /sys/kernel/debug/prueth-<hsr/prp>-<ID>/

Where ID is the PRU-ICSS ID as described in the HSR/PRP User Guide.

  • For HSR on PRU-ICSS2 of AM571x, path is changed to /sys/kernel/debug/prueth-hsr-2/
  • For HSR on PRU-ICSS1 of AM571x, path is changed to /sys/kernel/debug/prueth-hsr-1/
  • For PRP on PRU-ICSS2 of AM571x, path is changed /sys/kernel/debug/prueth-prp-2/
  • for PRP on PRU-ICSS1 of AM571x, path is changed to /sys/kernel/debug/prueth-prp-1/

All of the existing debugfs files except prp_emac_mode have moved to the new location. prp_emac_mode is now changed to sysfs file as decribed in the below section. The files are not writeable anymore as it is meant only for showing debug information. The write functions are moved to the upper layer HSR/PRP driver and implemented though proc entries. See the Linux HSR/PRP driver section for more details.

2. sysfs file path has changed

The path for sysfs files have also changed from

  • /sys/devices/platform/pruss<ID>_eth/eth2/
to
  • /sys/devices/platform/pruss<ID>_eth/net/eth2/

Where ID is the PRU-ICSS ID as described in the User Guide.

For example, nsp_credit sysfs file is now accessed at

/sys/devices/platform/pruss2_eth/net/eth2/nsp_credit

prp_emac_mode file is at

/sys/devices/platform/pruss2_eth/net/eth2/prp_emac_mode

Linux HSR/PRP Driver

1. debugfs file path has changed

The debugfs file directory created by the driver now uses the interface name so that multiple instances of the device can co-exist and each will have its own unique path names.

Path is now changed from

  • /sys/kernel/debug/<hsr/prp>/
to
  • /sys/kernel/debug/<if_name>/

For example, if hsr interface name is hsr0, the path will be - /sys/kernel/debug/hsr0/

Write functions are now supported through proc entries. So similar functions are removed from debugfs. See below section for details of proc entries. stats file is renamed to lre_info which shows SV frame tx count along with additional debug information about the LRE.

2. proc file paths

Following commands can be used for updating values at the prueth offloaded device which was earlier supported through debugfs files at the prueth device.

  • /proc/<if_name>/clear-nt - Replaces /sys/kernel/debug/prueth-<hsr/prp>/node_table_clear
  • /proc/<if_name>/hsr-mode - Replaces /sys/kernel/debug/prueth-<hsr/prp>/hsr_mode
  • /proc/<if_name>/dlrmt - Replaces /sys/kernel/debug/prueth-<hsr/prp>/dup_list_reside_max_time
  • /proc/<if_name>/dd-mode - Replaces /sys/kernel/debug/prueth-<hsr/prp>/duplicate_discard
  • /proc/<if_name>/prp-tr - Replaces /sys/kernel/debug/prueth/transparent_reception

2.4.1.4. Processor SDK 05.00

  • This is the first release for 2018 LTS (Kernel: 4.14, U-boot: 2018.01, gcc: 7.2.1 and Yocto: 2.4 (rocko)).

  • With Yocto migration, several open source components (Qt, Wayland, Weston, GStreamer, iPerf, etc.) are all upgraded. For the exact versions of the new components, please refer to the Software Manifest., and for any migration issues, refer to the corresponding component’s release notes, and Processor SDK Known Issues list.

  • Following are major compatability changes for TI drivers, components.

  • IPC
    • Remoteproc core
      • RPMSG_VIRTIO is no longer automatically selected by remoteproc platform drivers, has to be enabled specifically in defconfigs
      • The RSC_CUSTOM remoteproc custom resource type has been replaced with two new RSC_PRELOAD_VENDOR and RSC_POSTLOAD_VENDOR resource types.
      • Two new debugfs variables “resource_table” and “carveout_memories” are added to print the resource table and carveout memories used by a remoteproc
      • Error recovery with virtio-rpmsg-bus stack is broken on Upstream vanilla 4.14 kernel. Error recovery is supported only on TI kernels.
    • PRUSS remoteproc
      • The PRUSS remoteproc bindings have been revised significantly to improve scalability and flexibility
        • New child nodes are added to represent the CFG, IEP and MII_RT sub-modules.
        • Default firmware names are moved from driver to DT
        • Client users will require a new “prus” mandatory property instead of the previous “pruss” property
        • “ti,pruss-gp-mux-sel” property is removed from PRU nodes and added as an optional property to client nodes.
        • “label” property is dropped from PRU nodes
        • “interrupts” and “interrupt-names” properties were moved from INTC node to their parent node.
      • Client user API has changed to acquire and use a PRU core

    • Keystone_remoteproc
      • The “label” binding property is dropped from the driver bindings, and is replaced with an alias using the stem “rproc”
      • The “ti,sci-id” property for K2G DSP nodes is also dropped.
      • The keystone-dsp-mem driver is converted to a regular module from a platform driver, so the dspmem nodes are dropped. The module uses revised bindings.
    • Userspace
      • New IPC and CMEM releases are needed to use with 4.14 kernel due to difference in AF_RPMSG family number and other kernel API changes
  • iperf2 is now replaced by iperf3

  • Keystone-2: PA/PA2 is not supported in NetCP driver.

  • Keystone-2: NWAL is not supported

  • MMC: AM57x uses sdhci-omap.c driver instead of omap_hsmmc.c driver

  • PCIe: The way in which PCIe endpoint is configured has changed. More details can be found from PCIe End Point Driver.

  • AM335x ICE v2: A new DT file (am335x-ice-v2-prueth.dts) is added to support PRUSS Ethernet ports. The following configurations are supported.

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.2.1. Processor SDK 04.03

  • Added am572x-idk-pps.dts and am571x-idk-pps.dts which are extensions of the am572x-idk.dts abd an571x-idk.dts respectively. The new DTS enables the PPS IO pins (sync/latch) and PTP BC bindings at the modified AM572x-idk and AM571x-idks, where the USB/LCD Display are disabled
  • Camera support for AM572x GPEVM is not in the default DTB.Use am57xx-evm*-cam-mt9t111.dtb for mt9t111 camera, and am57xx-evm*-cam-ov10635.dtb for ov10635 camera
  • Processor SDK documentation is now created from reStructuredText sources using Sphinx, and hosted on software-dl.ti.com instead of processors wiki
  • For AM57xx, with the addition of new components in the filesystem, the minimum SD-card size is 8 GB (4 GB SD cards no longer work).
  • For am57xx devices, the location of the saved U-Boot environment has moved from the external SD card to eMMC. Because of this change, the state of the U-Boot environment can no longer be guaranteed on a newly created SD card. The uEnv.txt file located on the boot partition of the SD card contains the logic to compensate for this change. Upon the initial boot, the environment will be reset to the default, and the empty file ”.psdk_setup” will be created on the boot partition. Subsequent boots will detect this file and bypass resetting the environment.

2.4.2.2. Processor SDK 04.02

Linux

PRUETH Driver

The module parameter syntax has changed from “prueth.pruss1_ethtype” and “prueth.pruss2_ethtype” in older release to “ti_prueth.pruss1_ethtype” and “ti_prueth.pruss2_ethtype”.

2.4.2.3. Processor SDK 04.01

IPC

PRUSS remoteproc

  • PRUs are no longer automatically booted (remoteproc ‘auto_boot’ is set to false) by remoteproc core. A PRU has to be booted either by PRU Client Drivers or a PRU applications in userspace. The kernel-space boot is triggered using the rproc_boot() kernel API, and the user-space applications can use the sysfs to start and stop the corresponding remoteproc. Please see Documentation/ABI/testing/sysfs-class-remoteproc file in kernel for sysfs usage details.
  • PRU remoteproc driver no longer configures the PRU Ethernet firmwares automatically using board-machine compatibles. The needed firmware names are configured by the PRU Ethernet driver now using the rproc_set_firmware() function.
  • Userspace PRU applications have to make sure to unload any existing PRU client drivers using a specific PRU, and set their firmware using sysfs before starting and using a PRU

2.4.2.4. Processor SDK 04.00

  • This is the first release for 2017 LTS (Kernel: 4.9, U-boot: 2017.01, gcc: 6.2.1 and Yocto: 2.2 (morty)), with following major changes.

IPC

remoteproc

  • The debugfs ‘state’ variable is replaced with a sysfs ‘state’ variable accepting ‘start’ and ‘stop’ to boot and shutdown a remote processor from userspace
  • A new sysfs variable ‘firmware’ is also added to set a new firmware. remoteprocs need to be in stopped state before a firmware can be set. New firmwares still need to reside in /lib/firmware
  • Booting a remote processor is now triggered by the insertion of the respective remoteproc platform driver. On 4.4, with virtio-rpmsg enabled firmwares, this only happened when both the remoteproc platform driver and virtio_rpmsg_bus module were installed.
  • Upstream 4.9 remoteproc and rpmsg cores are not suitable for TI platforms. A minimum of 4.10-rc4 (or the required remoteproc/rpmsg patches from 4.10-rc4) is needed if porting TI remoteproc drivers onto upstream.

rpmsg

  • virtio_rpmsg_bus module split into a ‘rpmsg_core’ and virtio-rpmsg transport specific ‘virtio_rpmsg_bus’ modules.
  • Removal of virtio_rpmsg_bus no longer stops a remote processor and should be avoided if a remote processor is running. * If removed and installed again, the rpmsg communication devices will not be reprobed.

Keystone_remoteproc

  • A new ‘label’ binding property is now mandatory. It will have the string names for the DSPs in the format “dsp<X>” (eg: dsp0, dsp7 etc)
  • K2G DSP nodes will require a new “ti,sci-id” property, and a different value for “power-domains” property (this is generic to all K2G devices)

PRUSS remoteproc

  • The AM437x specific am437x_pruss_wrapper module has been replaced with a generic pruss_soc_bus module, and is required to be installed on all SoCs.
  • New compatibles on AM335x and AM437x SoCs - The previous ‘am3352-xxx’ and ‘am4372-xxx’ have been replaced with a ‘am3356-xxx’ and ‘am4376-xxx’ compatibles since PRUSS are not present on AM3352 and AM4372 SoCs. The PRU nodes are also not enabled by default in base ‘am33xx.dtsi’ and ‘am4372.dtsi’ files.
  • New device hierarchy structure - The PRUSS node hierarchy from 4.4 is moved one-level down under a new parent pruss_soc_bus node.

CPSW CPDMA Descriptor Usage

There is a notable change in how to place cpsw cpdma descriptors in DDR and configure descs number: TI K4.4 device tree property was used “descs_pool_size” - descs_pool_size : total number of CPDMA CPPI descriptors to be used for both ingress/egress packets processing. if not specified the default value 256 will be used which will allow to place descriptors pool into the internal CPPI RAM.

New approach https://processors.wiki.ti.com/index.php/Linux_Core_CPSW_User%27s_Guide#Configure_number_of_TX.2FRX_descriptors

PCI ENDPOINT

The usage of ‘pci-ep’ configfs directory to configure PCI Endpoint has been changed in accordance with upstream review comments. Please see https://processors.wiki.ti.com/index.php/Linux_Core_PCIe_EP_User%27s_Guide#4.9_Kernel, for additional details

Display

fbdev is only set up for the primary display, instead of all displays. This results in the secondary displays to be left disabled by the kernel, until an userspace application enables the displays.

U-Boot RNDIS boot

AM335x USB client (RNDIS) boot and Ethernet boot modes are now supported using default defconfig (am335x_evm_defconfig). Similarly AM437x USB client (RNDIS) boot is now supported by am43xx_evm_defconfig. Separate defconfigs for above boot modes no longer exist.

Keystone-2 features

The following features are not ported to 2017 LTS

  • SRIO Kernel driver
  • 10G Uboot
  • IPSec sideband and inflow mode
  • QoS

2.4.3. Processor SDK 03.xx Releases

2.4.3.1. Processor SDK 03.03

  • HDMI-connected monitor no longer takes precedence over built-in LCD as a default graphics display for e.g. Matrix
  • See the Release Notes for full list of modifications.

2.4.3.2. Processor SDK 03.02

  • The QT QPA eglfs_kms, which supports multiple screens, has been enabled and used as the default eglfs platform plugin. For more information, see QT and Graphics Migration
  • bootmonitor now goes thru mkimage and as a result the load address changed. Users should manually execute following commands in their u-boot environment to properly install the secure monitor on k2 platforms:
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
  • HDMI-connected monitor no longer takes precedence over built-in LCD as a default graphics display for e.g. Matrix

2.4.3.3. Processor SDK 03.01

  • defconfig_builder is now used to generate working kernel defconfigs
  • In K2 U-Boot, added multi slave support.
  • In K2 Linux PA driver, added pre-classification support. So explicit lut rules for broadcast and multicast are removed and the same is achieved through this feature in PA
  • 10G Ethernet driver now supports auto configuration using MCU firmware (a.k.a 10G KR firmware). The firmware file name is ks2_xgbe_serdes_mcu_fw.bin which is available at the same location as other serdes firmwares.
  • The current version of the serdes firmware is 03.03.00.02C and the same is not backward compatible with the firmware in the previous SDK release (03.00.00)

2.4.3.4. Processor SDK 03.00

  • First 2016 LTS Release (Linux Kernel: 4.4, U-Boot: 2016.05, GCC 5.3, Yocto 2.1)
  • Unified kernel configuration based on multi_v7_defconfig
  • Migrated from SysVinit to systemd for user space initialization.
  • U-Boot drivers now uses DT, but is transparent to users
  • The content of <evm>-<os>-sdk-arago-src-<ver>.tar.gz on the download page changed from sources to a fetcher script that obtains the sources. This is to efficiently share the sources between different platforms and OSes supported by Processor SDK. See the README inside the tar-ball for instructions
  • This release adds support for RT Linux on AM335x ICE and K2G GPEVM
  • In K2 U-Boot, multi slave support is currently missing. To use multiple interfaces, please disable CONFIG_DM_ET option in u-boot .config and build.
  • See the Release Notes for full list of modifications.
  • For information on migrating from MCSDK (K2x) to Processor SDK, see this migration page.

2.4.4. Processor SDK 02.xx Releases

2.4.4.1. Processor SDK 02.00.02

  • This release adds RT Linux support on AM335x, K2H/K, K2E, K2L
  • This release supports AM572x IDK and K2G EVM
  • OpenCV now uses OpenCL under the hood, to offload compute tasks to C66x cores. This is transparent to the application
  • The SGX driver for AM335x has been enhanced to support DRM/WAYLAND based Multi-Window Display. For more information, see AM3 Graphics Migration
  • See the Release Notes for full list of modifications.
  • For information on migrating from MCSDK (K2x) to Processor SDK, see this migration page.

2.4.4.2. Processor SDK 02.00.01

  • This release adds support for devices from the KeyStone architecture: K2E, K2H/K, and K2L
  • This release also supports RT Linux is supported on AM4 and AM5 device
  • The SGX driver for AM4 has been enhanced to support DRM/WAYLAND based Multi-Window Display. For more information, see AM4 Graphics Migration
  • There is no migration impact to customers using AM3, and AM5.
  • See the Release Notes for full list of modifications.
  • For information on migrating from MCSDK (K2x) to Processor SDK, see this migration page.

2.4.4.3. Processor SDK 02.00.00

  • This release adds support for AM57x
  • First 2015 LTS (Kernel 4.1, U-boot 2015.07) Release
  • Starting this release, Processor SDK Installer is 64-bit, and installs only on 64-bit host machine. Support for 32-bit host is dropped as Linaro toolchain is available only for 64-bit machines
  • For AM3, AM4, Graphics SDK is now obsolete and Graphics stack is integrated into Processor SDK, and supports null DRM based Full Window, with Front and Flip modes. For more information, see Graphics Migration
  • Ethernet performance degraded ~10% on am335x-evm due to move from preempt_voluntary
  • See the Release Notes for full list of modifications.

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>

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.

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

Linux Kernel

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.

2.4.7.1. Migrating from AMSDK 8.0 to Processor SDK 1.0

As suggested above, this transition at this point in time, is largely a name change. The good news is, migration should be very simple. From a component point of view, Processor SDK for Linux 1.0 is very similar to AMSDK 8.0:

Component AMSDK 8.0 Processor SDK 1.0
U-Boot Bootloader v2014.07 v2014.07
Linux Kernel 3.14.26 3.14.26
Toolchain Linaro GCC 4.7 2013.03 hard-float Linaro GCC 4.7 2013.03 hard-float
GUI Development Platform Qt 4.8 Qt 5.4
Graphics SDK 05.01.01.02 05.01.01.02
Supported Platforms AM335x and AM437x AM335x and AM437x
Supported Hosts Ubuntu 12.04 and 14.04 Ubuntu 12.04 and 14.04

Table: AMSDK 8.0 to Processor SDK 1.0 Component Comparison

It is clear from the above that these SDKs are very similar. The biggest difference by far is the transition from Qt 4.8 to Qt 5.4. If you’d like to learn more about this specifically, please see the Qt 4 to 5 Migration. If you have a “headless” system, or don’t use Qt, then this is really a “don’t care”.

The rest of the Arago filesystem provided with the SDK was updated as well. Please consult the Software Manifest for specific changes.

2.4.7.1.1. Documentation

Since the components are mostly common, the documentation is also very similar. The headings and such have been updated to include the new Processor SDK naming, but the content, except when improved or necessary, is largely the same.

2.4.7.1.2. Hardware Platforms

Both SDKs support the same hardware platforms from TI. Here’s the list from the Processor SDK, for completeness.

2.4.7.1.3. Board Porting

One of the major efforts to developing a customer Linux Embedded System is porting the bootloader, U-Boot in this case, and the Linux kernel to a new hardware platform. Since the U-Boot and Kernel sources provided with the Processor SDK 1.0 are identical, this effort is minimal to non-existent. Custom drivers and any other bootloader or kernel code should move over seamlessly.

2.4.7.1.4. Application Development

If using the Arago Filesystem provided with the SDK (i.e. you haven’t yet used Yocto/Open Embedded to create your own), the specific versions of the packages provided might change slightly. Please consult the Software Manifest for any packages your are concerned with.

GUI Development

As highlighted above, this is the largest change between the two SDKs. If Qt 4.x is used currently, it is possible that adaptation to Qt 5.4 will be necessary. It depends largely on the Qt components used and how they transition to Qt 5.4. Again, please consult the Qt 4 to 5 Migration Guide for more information.

2.4.7.2. Summary

The AMSDK that you may be familiar with is getting a new name, the Processor SDK for Linux. This name change paves the way for adding more devices from TI’s processor line-up and allow developer’s to enjoy the same experience with more options. What seems like a simple name change at this point, will continue to grow to become an extensive software offering covering a broad range of devices, as well as operating systems, examples, tools, and other important components developers need in this fast-paced, time-to-market driven environment. The experience gained will translate nicely to the next project or the next set of challenges, enabling developers to be more efficient and successful.

The migration from the AMSDK to the Processor SDK is expected to be minimal, with a few noted exceptions. It’s a great time to explore the “new” AMSDK, and see how it will help solve the challenges faced today, and preparing for those in the future.