Texas Instruments Technology for Innovators(tm)

Framework Components 2.25.03.07 Release Notes

July 2010

Introduction, Documentation, What's New, Upgrade Info, Compatibility Information, Device Support, Validation Info, Known Issues, Examples, Version Information, Technical Support.

Introduction

The Framework Components are a collection of framework-independent utility libraries which other software frameworks can build upon.

Primary packages in this Framework Components release are briefly described here. (There are others, see the Configuration Reference Guide documentation for a complete package list.)

The Framework Components are provided as non-rebuildable libraries. Source is provided for debugging and educational value, but is not intended to be modified. Modified sources will not be supported.

Additionally, some distributions of this release include an "fctools" directory containing some dependent products for convenience. Products included in this release are:

See this Framework Components fctools explanation for further details.

Documentation

The following documentation is available:

In addition, users are encouraged to monitor (and contribute to!) the Framework Components content on the TI eXpressDSP Software Wiki.

Release notes from previous releases are also available in the relnotes_archive directory.

What's New

The following significant changes have been made since 1.00

2.25.03.07

2.25.02.06
  • The following defects were resolved:
    ID Headline
    SDOCM00071309 ti.sdo.fc.edma3 attempts to free the same resource twice
    SDOCM00071341 ti/sdo/fc/utils package.bld doesn't build for the GCArmv5T target

  • The following enhancements were resolved:
    ID Headline

2.25.01.05
  • The following defects were resolved:
    ID Headline
    SDOCM00064193 ti.sdo.fc.ires.examples.codecs.auddec1 package.xdc should not use 'requires' for ti.sdo.fc.ires.bufres dependency
    SDOCM00064302 SCPY has incorrect licenses in some files

  • The following enhancements were resolved:
    ID Headline
    SDOCM00065039 Need an example for IRES resource addrspace

2.25
  • Updated Dependencies
    • Updated to LinuxUtils 2.25
    • Updated to EDMA3 LLD 1.11.00.02
  • The following defects were resolved:
    ID Headline
    SDOCM00062645 FC addrspace and memtcm fails to link with DVTb at configuro stage
    SDOCM00057990 DMAN3's package.xs:validate function crashes if built for an unsupported target (should simply return NULL)
    SDOCM00061534 ti.sdo.fc.utils.gtinfra pkg needs to ship gt_dais.h header
    SDOCM00063576 ti.sdo.ce.alg's package.xs always plugs in Sem_* functions for RMAN, MP use-cases would need SemMP_* functions.
    SDOCM00060500 DMAN3.useExternalRM has an issue when used within a CE + BIOS context

  • The following enhancements were resolved:
    ID Headline
    SDOCM00060272 Add/validate support for OMAP-L138 for ACPY3, DMAN3, DSKT2
    SDOCM00061271 Means to release and reacquire scratch group locks in the middle of a "process()" call using IRES Handles
    SDOCM00061269 Add IRES_LATEACQUIRE support for EDMA3, VICP, HDVICP resources
    SDOCM00060307 Add support for access to multiple EDMA3 devices in FC (For Freon etc)

2.24.01
  • Updated Dependencies
    • Updated to LinuxUtils 2.24.03
  • The following defects were resolved:
    ID Headline
    SDOCM00060277 DSKT2 doesn't give detailed trace message when it fails to allocate memory
    SDOCM00060278 Issue with request for IRES_PERSISTENT VICP, HDVICP resources
    SDOCM00060037 Framework components for DM365 allocates IMCOP memory from reserved area

  • The following enhancements were resolved:
    ID Headline
    SDOCM00060276 *SYNC enhancements to support multichannel and low latency use-cases
    SDOCM00060275 Add one more region to the list of RSVD regions in IMCOP memory space

2.24
  • New features
    • WinCE support
  • Updated Dependencies
    • Updated to LinuxUtils 2.24.01
    • Updated to XDAIS 6.24
  • The following defects were resolved:
    ID Headline
    SDOCM00055647 Clean up FC's package dependencies
    SDOCM00055687 ti.sdo.fc.ires.edma3chan doesn't declare its depedency on the ti.sdo.fc.edma3.Settings module
    SDOCM00056099 Template-generated RMAN and DMAN3 fxns generate remarks
    SDOCM00056368 RMAN_assignResources() returns success when underlying IRESMGR_ indicates resource allocation failure
    SDOCM00057717 IRES VICP2 (smgr) gives error granting resources
    SDOCM00057720 Multiple Deletion Creation sequence of MPEG4 encoder results in failure in Framework Components resource allocation
    SDOCM00057723 _vicpsync.h missing from product
    SDOCM00058267 EDMA3 Resource Manager overshoots the maximum limit when multiple encoders are created and deleted

  • The following enhancements were resolved:
    ID Headline

2.23
  • New features
    • RMAN auto-register/unregister feature for XDC cfg built executables that use RMAN.
  • Updated Dependencies
    • Updated to LinuxUtils 2.23
    • Updated to XDAIS 6.23
  • The following defects were resolved:
    ID Headline
    SDOCM00046548 All example codecs should pass qualiTI
    SDOCM00053331 RMAN fails to allocate multiple HDVICP resource requests on Linux builds.
    SDOCM00053484 DMAN3 example fcpy lib build failure in CCS
    SDOCM00054062 fastcopytest.pjt should include EDMA3_LLD_INSTALL_DIR explicity in the pjt's build options
    SDOCM00055054 RMAN_assignResources in the VISA_create call through DVTB fails when the engine instance is closed and opened once again
    SDOCM00055397 Framework Components fastcopy example cleanup for new OMAPL137 platform

  • The following enhancements were resolved:
    ID Headline
    SDOCM00046397 Enhance FC resource managers to autogenerate RMAN_register() calls
    SDOCM00053546 Change EDMA3_LLD location var to EDMA3_LLD_INSTALL_DIR in examples/Makefile
    SDOCM00053802 DMAN3 doesn't check if number of TCCs is correct as per the SOC's cccfg register

2.22
  • New features
    • IRES EDMA3CHAN supported for DM355, DM365 target
    • IRES VICP supported for DM365 target
    • IRES HDVICP supported for DM365 target
    • HDVICPSYNC module supports synchronization between algorithms and HDVICP coprocessor usage
    • IRES ADDRSPACE module supports OS-agnostic accesses to hardware accelerator (and other) address spaces.
  • Updated Dependencies
    • Updated to LinuxUtils 2.22
    • Updated to EDMA3 LLD 1.06.00.01
    • Updated to XDAIS 6.22.01
  • The following defects were resolved:
    ID Headline
    SDOCM00053331 RMAN fails to allocate multiple HDVICP resource requests on Linux builds

  • The following enhancements were resolved:
    ID Headline
    SDOCM00046361 HDINTC module for Kaleido interrupt registration for the DM36x
    SDOCM00046362 IRESMAN for EDMA3CHAN on using LSP (DM365)
    SDOCM00046363 IRESMAN for managing IMCOP memories
    SDOCM00046363 IRESMAN for managing IMCOP memories
    SDOCM00046262 Add support for C674 target
    SDOCM00050216 Add more VICP buffers to ires_vicp2 for DM365

2.21
  • New features
    • IRES VICP supported for DM355 target
    • Memutils module supports cache-related APIs and virt-to-phys mapping
    • VICPSYNC module supports synchronization between algorithms and VICP coprocessor usage
  • Updated Dependencies
    • Updated to LinuxUtils 2.21
  • The following defects were resolved:
  • The following enhancements were resolved:
    • ID Headline
    SDOCM00046122 DMAN3 documentation needs more clarification of nullPaRamIndex
    ID Headline
    SDOCM00046362 IRESMAN for EDMA3CHAN on using LSP (DM355)
    SDOCM00046363 IRESMAN for managing IMCOP memories
    SDOCM00046378 rman examples need more support when building with xdc
    SDOCM00046050 Need to expose PSC addresses in the VICP handles to enable codec access

2.20
  • New features
    • Updated uClibc toolchain
    • RMAN support for ARM targets
    • New configuration option on DMAN3 allows resource management to be handled by the EDMA3 Low Level Resource manager (BIOS-based environments only)
    • Support for OMAP3 devices
    • Functional library and resource management for SDMA channels on OMAP3
  • Removed features
    • Removed support for C55-based devices
  • Updated Dependencies
    • Updated to LinuxUtils 2.20
    • Updated to XDC 3.10
    • Updated to XDAIS 6.20
    • Updated to BIOS 5.32.02
    • Updated to EDMA3 LLD 1.05.00
  • The following defects were resolved:
  • The following enhancements were resolved:
    • ID Headline
    SDSCM00019578 DMAN3 should support the persistent property in IDMA3 requests
    SDSCM00024229 DSKT2 scratch and persistent alloc/free functions not exposed in the DSKT2 public headers
    SDSCM00025464 Some ACPY3 functions give out garbage trace even if GT_set is not called
    SDSCM00025628 RMAN examples missing common.cfg file
    SDSCM00025631 RMAN examples need build instructions
    ID Headline
    SDSCM00025515 HDINTC module hard codes Interrupt and Event number for the BIOS-ISR
    SDSCM00025744 RMAN on ARM should support multi-process
    SDSCM00025399 DMAN3 (and ACPY3) should have configuration for CPU copy
    SDSCM00024890 Standardize lib directory for all FC libraries

2.10
  • New features
    • C64+ libraries built with CG 6.0.16
    • Support for DM6467
    • Introduced DSKT2 APIs for querying alg instance memory usage at runtime
    • Introduced IRES/RMAN app note (see documentation section above)
  • Updated Dependencies
    • EDMA3 Resource Manager 1.04.00
  • The following defects were resolved:
    ID Headline
    SDSCM00021022 In FC examples api.a64P should be picked up from FC not the CCS install
  • The following enhancements were resolved:
    ID Headline
    SDSCM00015973 DMAN3's config parameter validation is required
    SDSCM00020192 DSKT2 debug builds should assert that algs that request IALG_SCRATCH implement algActivate()/algDeactivate()

2.00
  • New features
    • Added ARM-based Linux support to DMAN3. This implementation currently requires the Codec Engine to be configured into the ARM-based Linux system.
    • Initial RMAN implementation - supporting the new XDAIS IRES interface.
    • Introduced DSKT2_createAlgExt() to create algorithms and provide external memory to them regardless of the memory they asked for.
    • Significant tracing rearchitecture. Many packages now include a .trace config param which, when set to true, enables tracing support.
  • Updated Dependencies
    • Updated to XDAIS 6.00
    • Updated to XDC 3.00
    • EDMA3 Resource Manager 1.01.00.01
  • The following defects were resolved:
    ID Headline
    SDSCM00015980 DMAN3's XDC config support fails when configuring .scratchAllocFxn
    SDSCM00016134 ACPY3 build with ACPY3_INLINE_ALL flag gives build errors
    SDSCM00017450 DSKT2 can fail to correctly provide external scratch memory to algorithms
    SDSCM00018734 DMAN3_grantDmaChannels() crashes in case of allocation failures
  • The following enhancements were resolved:
    ID Headline
    SDSCM00020198 DMAN3 should have the option of returning an error if alg requests more resources than configured for its scratch group

1.20
  • C64+ libraries built with CG 6.0.8
  • Updated fctools to XDAIS 5.20 release
  • ACPY3_complete() inline support added.
  • fastcopy example cleanup
  • And the following MRs were resolved:
    ID Headline
    SDSCM00002823 Remove dependency on BIOS types
    SDSCM00012024 DSKT2 User Guide documentation collateral should be provided for Framework Components
    SDSCM00013086 FC DMAN3 example builds have poor out of box experience
    SDSCM00013781 Require instrumentation in ACPY3 library to support DGT logging or any other kind of generic logging
    SDSCM00014395 DSKT2 scratch memory allocation & sharing is not optimal when alignment is required
    SDSCM00014454 Hardlimit of DMAN3_MAXDMARECS to 32 not required in the dman3 library. Should be removed as a config option for DMAN3
    SDSCM00014931 DMAN3_createChannels(), DMAN3_grantDMAChannels() memory overwrite for non-ACPY3 channels

1.10
  • All libraries are built with CG 6.0.7
  • Updated fctools to XDAIS 5.10 release
  • And the following MRs were resolved:
    ID Headline
    SDSCM00013041 ACPY3 susceptible to SDSCM00012367 (Silicon Errata)
    SDSCM00006288 Need to update the Joule DMA design guide
    SDSCM00012532 Source code does not line up when stepping through debug libraries
    SDSCM00012770 ACPY3 specification changes are needed for clarification and to match design and implementation changes
    SDSCM00012773 DMAN3 RTSC Configuration requires custom non-public initialization call to configure DMAN3 heaps

1.03
  • All libraries are built with CG6x 6.0.5

1.02
  • OMAPS00082651 - Allow IDMA3 channel env to be allocated in DSKT2 scratch memory
    • Also tracked as SDSCM00005723 - FC ACPY3 needs to support scratch environment memory for IDMA3 channel objects
  • SDSCM00010132 - ACPY3 Changes Needed for Interoperability with Codecs using QDMA Library
  • SDSCM00010205 - DMAN3 uses wrong QCHMAP offsets

1.01
  • OMAPS00081737 - Race condition can happen in DSKT2_freeAlg
    • Also tracked as SDSCM00007366 - DSKT2_freeAlg and lazy deactivate race condition
  • OMAPS00079468 - ACPY3_activate causing DMA transfer when built with -o3
  • OMAPS00078941 - ACPY3_wait() inline version not inlining
  • OMAPS00078784 - DSKT2 needs an API to deactivate all algs that have been lazily deactivated
    • Also tracked as SDSCM00006538 - DSKT2's lazy deactivate can cause problems when power management is introduced
    • This was satisfied with the introduction of DSKT2_deactivateAll()
  • OMAPS00079710 - DSKT2 should not try to deactivate an codec instance that does not provide algDeactivate()
  • OMAPS00076836 - DSKT2 can introduce some cache coherence issues
    • Also tracked as SDSCM00005847 - DSKT2 doesn't BCACHE_flush MEM_calloc initialized external, persistant data
  • OMAPS00074261 - Support Visual Studio builds of dman3 and acpy3 libraries
  • OMAPS00074262 - Fix CPU copy version of ACPY3 library
  • Added DSKT2 documentation to the configuration reference guide

Upgrade Information

The Framework Components packages are available in the "packages/" subdirectory of the product. If you have a previous release of the Framework Components product, you can install this release next to it, and modify your application and/or server builds to use this newer release.

If you're using the DVEVM, this can be done by setting the FC_INSTALL_DIR variable in the Rules.make file at the top of the DVEVM distribution directory.

Note, if you're upgrading from a release earlier than Framework Components 2.25, be sure to review the Upgrade section for each of the releases between your current Codec Engine release and this one. Previous release notes are available in the relnotes_archive directory.

Compatibility Information

The details provided below describe each package's compatibility with the previous release (2.25).

Note, the Configuration Reference Guide contains further details about each package.

  • ti.sdo.fc.acpy3 - This package is compatible with the previous release. (Compatibility key: 1,0,4 -> 1,0,4)
  • ti.sdo.fc.dman3 - This package is compatible with the previous release. (Compatibility key: 1,0,4 -> 1,0,4)
  • ti.sdo.fc.dskt2 - This package is compatible with the previous release. (Compatibility key: 1,0,4 -> 1,0,4)
  • ti.sdo.fc.edma3 - This package is compatible with the previous release. (Compatibility key: 3,0,0 -> 3,0,0)
  • ti.sdo.fc.hdintc - This package is compatible with the previous release. (Compatibility key: 1,0,4 -> 1,0,4)
  • ti.sdo.fc.ires - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.bufres - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.edma3chan - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.nullresource - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.vicp - This package is compatible with the previous release. (Compatibility key: 1,0,1 -> 1,0,1)
  • ti.sdo.fc.ires.hdvicp This package is compatibile with the previous release. (Compatibility key: 1,0,1 -> 1,0,1)
  • ti.sdo.fc.rman - This package is compatible with the previous release. (Compatibility key: 2,0,0 -> 2,0,0)
  • ti.sdo.fc.utils - This package is compatible with the previous release. (Compatibility key: 1,0,2 -> 1,0,2)
  • ti.sdo.fc.utils.api - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.utils.gtinfra - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.utils.trace - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.scpy - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.sdma - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.shmbuf - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.hdvicpsync - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.memutils - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.vicpsync - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.global - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.addrspace - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
  • ti.sdo.fc.ires.memtcm - This package is compatible with the previous release. (Compatibility key: 1,0,0 -> 1,0,0)
    • Compatibility with previous releases is not currently managed in the examples.

The following packages are "experimental", and therefore compatibility keys are not maintained.

  • ti.sdo.fc.ires.grouputils - Used by algorithms to release and reacquire scratch group locks while in the middle of process call. Also required to lock and unlock "IRES_LATEACQUIRE" resources.

If migrating from a release prior to FC 2.25, consult previous releases available in the relnotes_archive directory.

Compatibility Key Definitions

Compatibility keys are intentionally independent of Marketing product numbers and are intended to:

  1. Enable tooling to identify incompatibilities between components, and
  2. Convey a level of compatibility between different releases to set end user expectations.

Compatibility keys are composed of 3 comma-delimited numbers - M,S,R - where:

  • M = Major. A difference in M indicates a break in compatibility.
  • S = Source. A difference in S indicates source compability. That is, the user's source doesn't require change, but does require rebuilding.
  • R = Radix. A difference in R indicates an introduction of new features, but compatibility with previous interfaces has not broken. If libraries are provided by the package, an application must re-link with the new libraries, but not rebuild from source.

Device Support

This release supports the following devices:

  • DM6446 EVM:
    • single-processor C64+ device, running DSP/BIOS
    • single-processor ARM9 device, running Linux (All except DSKT2 and ACPY3)
  • DM6467 EVM:
    • single-processor C64+ device, running DSP/BIOS
    • single-processor ARM9 device, running Linux (All except DSKT2 and ACPY3)
  • DM6437 EVM:
    • single-processor C64+ device, running DSP/BIOS
  • DM647/8 EVM:
    • single-processor C64+ device, running DSP/BIOS
  • DM355 EVM:
    • single-processor ARM9 device, running Linux (All except DSKT2 and ACPY3)
  • OMAP2430 SDP and OMAP2530 EVM:
    • single-processor DSP-only configuration, running DSP/BIOS
    • single-processor ARM device, running Linux (All except DSKT2 and ACPY3)
  • OMAP3430 SDP and OMAP3530 EVM:
    • single-processor, DSP-only configuration, running DSP/BIOS
    • single-processor ARM device, running Linux (All except DSKT2 and ACPY3)
  • C64+ simulators, single processor configuration:
    • C64+ DSP/BIOS
DMAN3 and ACPY3 can be configured to run on other EDMA3-based devices by configuring DMAN3.qdmaPaRamBase via XDC config scripts or at runtime by setting DMAN3_PARAMS.qdmaPaRamBase.

Applications which use ACPY3 but don't consume DMAN3 as an XDC package will need to define _DMAN3_nullPaRam, _DMAN3_edma3Addr and _DMAN3_paRamAddr (_DMAN3_paRamAddr for non-C64P targets) symbols in their application "C" files

Validation

This release was built and validated against using the following software components:

  • XDAIS 6.25.02.11
  • Linux Utils 2.25.03.09
  • XDCtools 3.16.00.18
  • DSP/BIOS 5.41.00.06
  • EDMA3 Resource Manager 01.11.00.02
  • Pre-built binaries were built with the following toolchains:
    • gnu.targets.Linux86 - 4.1.0
    • gnu.targets.MVArm9 - 4.2.0
    • gnu.targets.UCArm9 - 4.2.1
    • gnu.targets.arm.GCArmv5T - 4.2.0
    • microsoft.targets.arm.WinCE - 14.01.60511
    • ti.targets.C64P - 6.0.16
    • ti.targets.C674 - 6.1.5
    • ti.targets.arm.Arm9t - 4.5.0

This release was validated using the following hardware platforms:

C64+

  • DM6446 EVM
  • DM6467 EVM
  • OMAP2430 SDP
  • OMAP3530 EVM
  • Limited sanity testing using CCS C64+ Simulator

ARM 9 (All except DSKT2 and ACPY3)

  • DM355 EVM
  • DM365 EVM

C674

  • OMAP-L137 EVM
  • OMAP-L138 EVM

Known Issues

ACPY3

  • ACPY3 usage of IDMA0 does not provide any software workaround for DaVinci silicon defect BTS_DAV_SIBUGS 75, titled: "GEM IDMA can hang dependent on chip level implementation." The defect only exists on Davinci Pg1.x silicon. (Fixed for future Davinci Pg2.x, OMAP 2430 and 3430 silicon releases.) There is no plan to address this issue in Framework Components.
  • 3D DMA transfers using Joule CCNT > 1 (i.e. numFrames > 1) are not supported. There is no plan to address this limitation.

EDMA3

  • The level of support for devices that have multiple EDMA3 hardware instances is limited. For e.g, Freon and Primus devices have 2 EDMA3 hardware instances, the dma related modules of Framework Components let you configure/access only one of those devices at a time. No support is available, as yet, for concurrent management/access to mutiple EDMA3 Transfer Controllers.
  • When using the low level driver (EDMA3LLD 1.11.00.02) via DMAN3 or IRES EDMA3CHAN interface, sometimes, requesting more contiguous PaRams than are available on the hardware (or with the resource manager), causes an assert to go off in the EDMA3LLD. Track CQ:- SDOCM00063765

DMAN3

  • In DMAN3, when using the DMAN3_createChannels API with the useExternalRM mode set for DMAN3's config, multiple calls will result in discreet resources being granted even though each call has the same scratch group. This issue is not present when not using External Resource Manager. Track CQ:- SDOCM00063763

Examples

Framework Components examples and instructions are located in the "examples" directory.

Version Information

This product's version follows a version format, M.mm.pp.bb, where M is a single digit Major number, mm is 2 digit minor number, pp is a 2 digit patch number, and b is an unrestricted set of digits used as an incrementing build counter.

To support multiple side-by-side installations of the product, the product version is encoded in the top level directory, ex. framework_components_2_25_03_07.

Subsequent releases of patch upgrades will be identified by the patch number, ex. FC 2.25.01.XX with directory framework_components_2_25_01_XX. Typically, these patches only include critical bug fixes.

Technical Support

For technical support, contact softwaresupport@ti.com

Check the following web site for updates: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/fc/index.html

Last updated: July 2, 2010