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
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 3.20, 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.
The details provided below describe each package's compatibility with the
previous release (framework_components_3_21_01_26).
Note, the Configuration Reference Guide contains
further details about each package.
Package |
framework_components_3_21_01_26 |
framework_components_3_21_03_34 |
ti.sdo.fc.acpy3 |
1, 0, 4 |
1, 0, 4 |
ti.sdo.fc.dman3 |
1, 0, 4 |
1, 0, 4 |
ti.sdo.fc.dskt2 |
1, 0, 4 |
1, 0, 4 |
ti.sdo.fc.ecpy |
1, 0, 1 |
1, 0, 1 |
ti.sdo.fc.edma3 |
3, 0, 0 |
3, 0, 0 |
ti.sdo.fc.global |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.hdintc |
1, 0, 4 |
1, 0, 4 |
ti.sdo.fc.ires |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.ires.bufres |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.ires.edma3chan |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.ires.hdvicp |
1, 0, 1 |
1, 0, 1 |
ti.sdo.fc.ires.nullresource |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.ires.sdma |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.ires.shmbuf |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.ires.tiledmemory |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.ires.vicp |
1, 0, 1 |
1, 0, 1 |
ti.sdo.fc.memutils |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.rman |
2, 0, 0 |
2, 0, 0 |
ti.sdo.fc.scpy |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.trace.gt |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.utils |
1, 0, 3 |
1, 0, 3 |
ti.sdo.fc.utils.api |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.utils.gtinfra |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.utils.osal |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.utils.osal.noOS |
1, 0, 0 |
1, 0, 0 |
ti.sdo.fc.utils.osalsupport |
1, 0, 0 |
1, 0, 0 |
ti.sdo.opencl |
1, 0, 0 |
1, 0, 0 |
ti.sdo.opencl.platforms.c6472 |
1, 0, 0 |
1, 0, 0 |
ti.sdo.rcm |
2, 0, 0 |
2, 0, 0 |
ti.sdo.tiler |
1, 0, 0 |
1, 0, 0 |
ti.sdo.utils.trace |
1, 0, 0 |
1, 0, 0 |
The following packages that were in the previous release have been removed
from this release.
Package |
Compatibility key |
khronos.opencl |
1, 0, 0 |
If migrating from a release prior to FC 3.21, 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:
- Enable tooling to identify incompatibilities between components,
and
- 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.
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)
- TI816X TI814X EVM:
- single-processor C674 device, running DSP/BIOS
- single-processor Cortex A8 device, running Linux
- single-processor Cortex M3 device, running DSP/BIOS(DSKT2, RMAN, IRES)
- OMAP4430 EVM:
- single-processor C674 device, running DSP/BIOS
- single-processor Cortex A9 device, running Linux
- single-processor Cortex M3 device, running DSP/BIOS(DSKT2, RMAN, IRES)
- C6472 C6474 EVM:
- Multiple C64P processors, running DSP/BIOS
- C6678 C6670 EVM:
- Multiple C66 processors, running DSP/BIOS
- 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
- 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:
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.
Additionally, when DMAN3 is not configured as an XDC package the
application must set the _DMAN3_EDMA3BASE in the linker cmd file
as shown in the DMAN3 fastcopytest example.
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
This release was built and validated against using the following software
components. Please use the versions below or any other that are compatible with the below:
- XDAIS 7.21.00.02
- Linux Utils 3.21.00.04
- IPC 1.23.01.26
- OSAL 1.21.01.08
- XDCtools 3.22.01.21
- DSP/BIOS 6.32.02.39
- EDMA3 Resource Manager 02.11.02.04
- Pre-built binaries were built with the following toolchains:
- gnu.targets.Linux86 - 4.1.0
- gnu.targets.UCArm9 - 4.2.1
- gnu.targets.arm.GCArmv5T - 4.2.0
- ti.targets.C64P - 7.0.0
- ti.targets.C674 - 7.0.0
- ti.targets.arm.elf.A8F - 4.9.0
- ti.targets.arm.elf.M3 - 4.9.0
- ti.targets.elf.C64P - 7.2.0
- ti.targets.elf.C64T - 7.2.0
- ti.targets.elf.C674 - 7.2.0
- ti.targets.elf.arp32.ARP32 - 1.0.0
This release was validated using the following hardware platforms:
C64+
- C6472 EVM
- C6474 EVM
- OMAP3530 EVM
- Limited sanity testing using CCS C64+ Simulator
C66
C674
- TI816X EVM
- TI814X EVM
- OMAP-L137 EVM
M3
TI816X
-
For the TI816X platform, there are issues when performing internal memory
transfers using DMA on the C674. The internal memory addresses seem to be
wrongly interpreted when the Channel Controller queue priorities (or the QUEPRI register)
are set to either 3 or 7. When using DMAN3 or the ti.sdo.fc.edma3.Settings
module, make sure you configure priorities to be something other than 3 or 7.
ECPY
-
ECPY, the APIs for thew new function library for performing DMA
transfers using the IRES EDMA3CHAN2 handle are "experimental".
New APIs/features will likely be added in upcoming releases/patches.
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
Framework Components examples and instructions are located in the
"examples" directory.
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_3_21_03_34.
Subsequent releases of patch upgrades will be identified by the patch
number, ex. FC 3.21.03.XX with directory framework_components_3_21_03_XX.
Typically, these patches only include critical bug fixes.
For technical support, contact softwaresupport@ti.com.
Questions/issues regarding this release may also be posted at the E2E forum at http://e2e.ti.com/support/embedded/default.aspx
Check the following web site for updates: https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/fc/index.html
Last updated: December 2, 2011