Migrating from DSPLink 1 50 to 1 51

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

Translate this page to

Introduction

This page gives information for users attempting to move applications from DSPLink v1.50 to v1.51.

New features in v1.51

Overview

Major feature additions in DSPLink v1.51 are:

Support for the following additional devices:
- OMAP2530 EVM
- Support for OMAP3530 EVM
- Support for DRX416 EVM
- Support for DM6437 connected to Linux PC over PCI
- Support for DM648 connected to Linux PC over PCI
New DSP operating system support
- Support for DSP/BIOS™ 6.xx for DM6446 using DSP/BIOS 6.xx legacy layer for DSP/BIOS 5.xx
New DSPLink Boot Modes support added on DM6446 platform: DSPLink now supports three different types of DSP boot modes on DM6446 platform
- DSPLINK_BOOT_MODE: Default
- DSPLINK_NOLOAD_MODE: External DSP load
- DSPLINK_NOBOOT_MODE: External DSP start
DSPLink packaging changes: DSPLink licensing has been changed to have two separate product packages:
- Linux product with kernel-side GPLv2 / user-side proprietary
- TI proprietary licensed porting kit package for non-Linux OSes.

Other minor enhancements include:

Sample application enhancements
- Profiling has been added to the Message sample.
- The RingIO sample application has been enhanced to demonstrate usage in application scenario.
Defect fixes

Details of Major feature additions

New DSPLink Boot Modes support

DSPLink now supports three different types of DSP boot modes on DM6446 platform:

DSPLINK_BOOT_MODE: Default
- GPP boots first
- Uses DSPLink to load the DSP
- Uses DSPLink to start the DSP running
DSPLINK_NOLOAD_MODE: External DSP load
- GPP boots first
- Application/GPP boot-loader pre-loads the DSP
- Uses DSPLink to optionally power up the DSP
- Uses DSPLink to start the DSP running
DSPLINK_NOBOOT_MODE: External DSP start. This supports two scenarios
- GPP-based load
- GPP boots first
- Application/GPP boot-loader pre-loads the DSP
- Application/GPP boot-loader starts the DSP running
- Uses DSPLink only for IPC with the DSP

OR

- DSP-based load
- DSP boots first, starts running an application
- ARM comes up later and sets up DSPLink, which initializes shared memory
- DSPLink is not used to load or start the DSP
- Uses DSPLink only for IPC with the DSP

For complete details on the new boot load along with information on configuration and application usage, please refer to the Programmer’s Guide document.

DSPLink packaging changes

DSPLink packaging changes: DSPLink licensing has been changed to have two separate product packages:

Linux product with kernel-side GPLv2 / user-side proprietary
TI proprietary licensed porting kit package for non-Linux OSes.

The package to be used must be selected on the basis of intended usage:

Application development
- Users need to pick up the relevant packages for using existing supported configurations.
  - For working on non-Linux OSes, such as PrOS validated on DRA44x and DRx416, developers/application writers need to pick up dsplink_sla_1_51.tar.gz.
  - For working on Linux OS validated with other devices such as DM6446, DM6467, OMAP2530, OMAP3530, DM6437, DM648, developers/application writers need to pick up dsplink_1_51.tar.gz.
Porting
The porting kit dsplink_sla_1_51.tar.gz must be used for porting to any operating system other than Linux for the supported devices. All device support is present within the porting kit, even though it may not be validated in that package.
- To port to a different device on any other OS, dsplink_sla_1_51.tar.gz must be used.
To port to a different device on Linux, dsplink_1_51.tar.gz must be used.

Upgrade and compatibility information

This section gives the details of backward compatibility and upgrade information for applications to move to DSPLink v1.51 from the previous release DSPLink 1.50.
IMPORTANT: There are changes to the default dynamic configuration file $DSPLINK/config/all/CFG_<$PLATFORM>.c. These require application writers to ensure that they merge their copy of the dynamic configuration file with the default one in the release, to ensure that the changes in configuration are carried forward into the application build.

API-level backward compatibility with v1.4x
DSPLink packaging changes: DSPLink licensing has been changed to have two separate product packages:
Linux product with kernel-side GPLv2 / user-side proprietary
TI proprietary licensed porting kit package for non-Linux OSes.
Memory map updation related changes for usage with DSP/BIOS 6.xx
- The file $DSPLINK/make/DspBios/platform.xs has been generated from the original DSP/BIOS 5 file dsplink-davinci-base.tci. This contains the memory map as seen by DSP/BIOS 6. Presently it is set to the default DSPLink memory map. Application Writers can use this as reference for the application specific memory maps.
Static build configuration
- The build configuration script has been enhanced to allow users to move preconfigured installations of DSPLink (using dsplinkcfg script) to a different location without causing any issues in build.
Configuration changes
- CONST qualifier of configuration structures removed
  - The CONST qualifier of configuration structures has been removed. This ensures that application writer can modify using dynamic configuration the default configuration shipped in DSPLink. More details on how to use this feature are available here Configuring_DSPLink_Dynamically
- Probe support removed: The dynamic configuration has been enhanced to remove the functionality of PROBE:
  - PROBERTCID and PROBEINTID have been removed from the LINKCFG_Gpp structure
- Support for Bios 6.xx for DM6446
  - DM6446 platform supports DSP/BIOS version DSP/BIOS ™ 5.xx as well as DSP/BIOS ™ 6.xx.
  - The DspArch field in the LINKCFG_Dsp structure has been updated to support:
    - DspArch_C64x_Bios5: It indicates that the architecture is C64x and the DSP OS version is DSP/BIOS 5.xx.
    - DspArch_C64x_Bios6: It indicates that the architecture is C64x and the DSP OS
  - In order to provide backward compatibility, when the application writer specifies DspArch_C64x, the COFF loader will search through the sections to determine the DSP/BIOS version and process the loading of COFF accordingly. If the application wants to eliminate the search time and knows the DSP/BIOS, they can specify DspArch_C64x_Bios5 or DspArch_C64x_Bios6.
- Support for additional boot modes for DM6446 platform
  - The dynamic configuration has been enhanced to support the following additional configuration: Configuration of DSP control to support:
    - DSP_BootMode_Boot_NoPwr: Default boot mode without power control
    - DSP_BootMode_Boot_Pwr: Default boot mode with power control
    - DSP_BootMode_NoLoad_NoPwr: New NOLOAD boot mode without power control
    - DSP_BootMode_NoLoad_Pwr: New NOLOAD boot mode with power control
    - DSP_BootMode_NoBoot: New NOBOOT boot mode without power control
  - Existing dynamic configuration files will work without any changes, since the first two boot modes map to existing boot modes. If any of the new boot modes are to be used, changes need to be made accordingly in the configuration file. New boot modes are supported in this release only for the DM6446 platform.
Build changes
- Distribution files added: This release adds new distribution files to support:
  - BIOS 6.xx build for DSPLink
    - $DSPLINK/make/DspBios/c64xxp_6.xx_linux.mk
    - $DSPLINK/make/DspBios/c64xxp_6.xx_windows.mk
  - OMAP 2530 /OMAP3530
    - $DSPLINK/make/Linux/omap2530_linux2.6.23.mk
    - $DSPLINK/make/Linux/omap3530_linux2.6.22.mk
    - $DSPLINK/make/Linux/omap_uclibc.mk
- GPP-side distribution files change
  - GPP-side distribution files for all platforms have been enhanced to use only two variable macros for paths:
    - BASE_BUILDOS: Location of the LSP
    - BASE_TOOLCHAIN: Location of the tool-chain
- GPP-side
  - The DSPLink build system has the facility to export header files to a pre-defined folder $DSPLINK/gpp/BUILD/INCLUDE. This enables the application writer who is using the DSPLink build system to export all header files in separate directories to just one folder. Then $DSPLINK/gpp/BUILD/INCLUDE can be added in the path instead of each separate directory.
  - This has now been updated to have two folders USER and KRNL i.e. $DSPLINK/gpp/BUILD/INCLUDE/USER will contain all the header files which have been exported from the USER space library. $DSPLINK/gpp/BUILD/INCLUDE/KRNL will contain all the header files which have been exported from the kernel space.
  - Applications which use the DSPLink build system to build user side applications will need to update the include path from $DSPLINK/gpp/BUILD/INCLUDE to $DSPLINK/gpp/BUILD/INCLUDE/USER.
  - Applications which use the DSPLink build system to build kernel modules will need to update the include path from $DSPLINK/gpp/BUILD/INCLUDE to add $DSPLINK/gpp/BUILD/INCLUDE/KRNL and $DSPLINK/gpp/BUILD/INCLUDE/USER if needed.

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Migrating from DSPLink 1 50 to 1 51 here.