|
|
|
This page explains how to build the examples provided in the Codec Engine (CE) product for Windows CE.
Examples currently contain the simple pass-through (copy) codecs, implemented in the XDM algorithm standard.
More details are available at the Codec Engine Examples Overview wiki article.
See the release notes for the specific software and hardware components this release of Codec Engine has been validated against.
This section describes the layout under the examples directory. In most cases, these examples are XDC packages, and there are links to the autogenerated XDC documentation. In some cases, the examples are not proper XDC packages, and documentation is provided in other means (see the specific example's directory).
examples
+---apps
| `---system_files Linux scripts describing which .ko's are required and how to load them for different platforms
| +---DM355
| |---DM357
| |---DM6446
| |---DM6467
| |---OMAP2530
| `---OMAP3530
`---ti
`---sdo
`---ce
`---examples Buildable example codecs, DSP servers, and ARM and/or DSP apps
+---codecs
| +---auddec1_copy
| +---auddec1_ires
| +---auddec_copy
| +---audenc1_copy
| +---audenc_copy
| +---g711
| +---imgdec1_copy
| +---imgdec_copy
| +---imgenc1_copy
| +---imgenc_copy
| +---scale
| +---sphdec1_copy
| +---sphdec_copy
| +---sphenc1_copy
| +---sphenc_copy
| +---universalcopy
| +---vidanalytics_copy
| +---viddec1_copy
| +---viddec2_copy
| +---viddec2split_copy
| +---viddec_copy
| +---videnc1_copy
| +---videnc_copy
| `---vidtranscode_copy
|
+---extensions
| `---scale
|
+---servers
| `---all_codecs
|
`---apps
+---audio1_copy
| +---async
| `---sync
+---audio1_ires
+---audio_copy
+---image1_copy
+---image_copy
+---scale
+---server_api_example
+---server_trace
+---speech
+---speech1_copy
+---speech_copy
+---speech_copy_LAD Not validated on WinCE
+---universal_copy
+---vidanalytics
+---video1_copy
+---video2_copy
+---video2split_copy
+---video_copy
`---vidtranscode
Important: throughout this document, we will use the following notation:
You will need to integrate DSPLink, CMEM, and LPM into your Platform Builder environment. For DSPLink integration, follow the instructions in the DSPLink Install Guide for WinCE.
Important Note: It is possible that pre-built dsplink and cmem binaries are provided by the BSP. Make sure that the inclusion of these binaries is disabled. Check for pre-built cmem binaries in %_WINCEROOT%\PLATFORM\<BSP>\Files folder. These binaries should either be deleted or renamed.
You can manually add the CMEM and LPM configurations to the platform.reg and platform.bib files. You can also integrate CMEM by adding it to your Platform Builder subprojects.
The CMEM dlls are located either in WinCE Utils or under cetools, depending on
your Codec Engine distribution. We will refer to this location as
WINCEUTILS_INSTALL_DIR. Similarly, the LPM driver may also be under its
own installation, or under cetools. We will refer to its location as LPM_INSTALL_DIR.
Copy the prebuilt cmemk.dll from
WINCEUTILS_INSTALL_DIR\packages\ti\sdo\winceutils\cmem\drivers\OMAP3530\obj\ARMV4I\retail
(or Davinci) to the
%_WINCEROOT%\PLATFORM\<BSP>\Files folder.
Copy the lpmdrv.dll and lpmdrv.pdb files
for your board from
LPM_INSTALL_DIR\packages\ti\bios\power\drivers\wince\omap3530\lpm\obj\ARMV4I\retail
to the %_WINCEROOT%\PLATFORM\<BSP>\Files folder.
Add the following lines to the platform.bib file in
%_WINCEROOT%\PLATFORM\<BSP_FOLDER>\FILES.
;-- CMEM --------------------------------------------------------------------
IF SYSGEN_CMEM
cmemk.dll $(_FLATRELEASEDIR)\cmemk.dll NK SHK
ENDIF SYSGEN_CMEM
;----------------------------------------------------------------------------
;-- LPM ---------------------------------------------------------------------
IF SYSGEN_LPM
lpmdrv.dll $(_FLATRELEASEDIR)\lpmdrv.dll NK SHK
ENDIF SYSGEN_LPM
;----------------------------------------------------------------------------
Make sure to define the environment variables, SYSGEN_CMEM and SYSGEN_LPM, by setting them in you project properties.
Add the CMEM and LPM registry data to the %_WINCEROOT%\PLATFORM\<BSP_FOLDER>\FILES\platform.reg file.The following registry
entry for OMAP3530 can be copied to the platform.reg, or used as an example
to create your own CMEM configuration. If you change the CMEM address range
in the registry, you may also need to change the DSP server's memory map to
ensure that the CMEM address range does not overlap with the DSP memory
segments. (The DSP server memory map is defined in a tconf configuration
file. For example, the codec engine all_codecs server for OMAP3530 has its
memory map in examples/servers/all_codecs/all_evm3530.tci).
;-- CMEM --------------------------------------------------------------------
IF SYSGEN_CMEM
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\CMEMK]
"Prefix"="CMK"
"Dll"="cmemk.dll"
"Index"=dword:1
; Make 7 pools available for allocation for block 0
; Make 0 pools available for allocation for block 1
"NumPools0"=dword:7
"NumPools1"=dword:0
"Block0_NumBuffers_Pool0"=dword:20
"Block0_PoolSize_Pool0"=dword:1000 ; size in bytes (hex)
"Block0_NumBuffers_Pool1"=dword:8
"Block0_PoolSize_Pool1"=dword:20000 ; size in bytes (hex)
"Block0_NumBuffers_Pool2"=dword:5
"Block0_PoolSize_Pool2"=dword:100000 ; size in bytes (hex)
"Block0_NumBuffers_Pool3"=dword:1
"Block0_PoolSize_Pool3"=dword:15cfc0 ; size in bytes (hex)
"Block0_NumBuffers_Pool4"=dword:1
"Block0_PoolSize_Pool4"=dword:3e800 ; size in bytes (hex)
"Block0_NumBuffers_Pool5"=dword:1
"Block0_PoolSize_Pool5"=dword:36ee80 ; size in bytes (hex)
"Block0_NumBuffers_Pool6"=dword:3
"Block0_PoolSize_Pool6"=dword:96000 ; size in bytes (hex)
;; "Block1_NumBuffers_Pool1"=dword:2
;; "Block1_PoolSize_Pool1"=dword:4000 ; size in bytes (hex)
; Physical start + physical end can be use to ask CMEM to map a specific range of physical addresses.
; This is a potential security risk. If physical start == 0 then the code hits a special case.
; physical end - physical start == length of allocation. In the special case, memory is allocated
; via a call to AllocPhysMem() (as shown in this example). MmMapIoSpace() is used to map the normal
; case where physical start != 0.
; physical start and end for block 0
"PhysicalStart0"=dword:85000000
"PhysicalEnd0"=dword:86000000
; physical start and end for block 1
"PhysicalStart1"=dword:0
"PhysicalEnd1"=dword:0
ENDIF SYSGEN_CMEM
;----------------------------------------------------------------------------
Here is an example CMEM configuration for DM6446:
;-- CMEM --------------------------------------------------------------------
IF SYSGEN_CMEM
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\CMEMK]
"Prefix"="CMK"
"Dll"="cmemk.dll"
"Index"=dword:1
; Make 3 pools available for allocation for block 0
; Make 0 pool available for allocation for block 1
"NumPools0"=dword:3
"NumPools1"=dword:0
"Block0_NumBuffers_Pool0"=dword:20
"Block0_PoolSize_Pool0"=dword:1000 ; size in bytes (hex)
"Block0_NumBuffers_Pool1"=dword:8
"Block0_PoolSize_Pool1"=dword:20000 ; size in bytes (hex)
"Block0_NumBuffers_Pool2"=dword:2
"Block0_PoolSize_Pool2"=dword:100000 ; size in bytes (hex)
; Physical start + physical end can be use to ask CMEM to map a specific range of physical addresses.
; This is a potential security risk. If physical start == 0 then the code hits a special case.
; physical end - physical start == length of allocation. In the special case, memory is allocated
; via a call to AllocPhysMem() (as shown in this example). MmMapIoSpace() is used to map the normal
; case where physical start != 0.
; physical start and end for block 0
"PhysicalStart0"=dword:87800000
"PhysicalEnd0"=dword:88000000
; physical start and end for block 1
"PhysicalStart1"=dword:0
"PhysicalEnd1"=dword:0
ENDIF SYSGEN_CMEM
;----------------------------------------------------------------------------
NOTE: Make sure that any reserved memory for CMEM specified in your
%_WINCEROOT%\PLATFORM\<BSP_FOLDER>\FILES\config.bib,
matches the addresses in platform.reg. For example, below is the MEMORY
section of a config.bib for OMAP3530, reserving a chunk of memory for CMEM starting at 0x85800000 (the
physical address 0x80000000 is mapped to the virtual address 0x84000000, so
subtract 0x400000 from 0x89800000 to get 0x85800000):
MEMORY
ARGS 84000000 00001000 RESERVED ; 4K
IF SYSGEN_DSPLINK
NK 84001000 01FFF000 RAMIMAGE ; 32MB - 4K
RAM 86000000 02800000 RAM ; 40 MB
DISPLAY 88800000 01000000 RESERVED ; 16MB
CMEM_DSP 89800000 02800000 RESERVED ; 40 MB
ELSE
NK 84001000 02FFF000 RAMIMAGE ; 48MB - 4K
RAM 87000000 04000000 RAM ; 64MB
DISPLAY 8B000000 01000000 RESERVED ; 16MB
ENDIF
If we set the start address of CMEM block0 to 0x85000000 in platform.reg, we
should modify the config.bib. In the example config.bib above, the memory
reserved for DISPLAY would overlap with the CMEM block in platform.reg. The
following shows the MEMORY section modified for the CMEM block0 starting at
0x85000000, along with memory reserved for other codec engine and dsplink
memory blocks (changed values are displayed in red, added entries are
displayed in blue):
MEMORY
ARGS 84000000 00001000 RESERVED ; 4K
IF SYSGEN_DSPLINK
NK 84001000 01FFF000 RAMIMAGE ; 32MB - 4K
RAM 86000000 02000000 RAM ; 40 MB
DISPLAY 88000000 01000000 RESERVED ; 16MB
CMEM_DSP 89000000 01000000 RESERVED ; 40 MB
DDRALGHEAP 8A000000 01800000 RESERVED ; 24 MB
DDR2 8B800000 00600000 RESERVED ;
DSPLINKMEM 8BE00000 00100000 RESERVED ;
RESETCTRL 8BF00000 00001000
RESERVED ;
ELSE
NK 84001000 02FFF000 RAMIMAGE ; 48MB - 4K
RAM 87000000 04000000 RAM ; 64MB
DISPLAY 8B000000 01000000 RESERVED ; 16MB
ENDIF
Add the following LPM registry key to the platform.reg file:
;-- LPM ------------------------------------------------------------------
IF SYSGEN_LPM
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\LPM]
"Prefix"="LPM"
"Dll"="lpmdrv.dll"
"Index"=dword:1
"Trace"=dword:0
ENDIF SYSGEN_LPM
;-----------------------------------------------------------------------------
Note: the debug trace messages are only supported by the debug build of
the driver. To enable driver trace messages, copy the driver files from
the debug folder and set the following registry value:
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\LPM\Trace = 1
Since the platform.bib and platform.reg files have been modified, you will need to rebuil the BSP.
Follow these steps to integrate the CMEM build into your Platform Builder project.
Important: throughout the rest of this document, we will use the following notation:
Codec Engine no longer comes with a pre-built version of DSPLink in the
cetools directory. You will need to get the DSPLink product and build it.
Follow the instructions in the Install Guide for DSP/BIOS Link for the
platform you are using, to install and build DSPLink. The configuration of
DSPLink for use with Codec Engine may be slightly different than that
described in the DSP/BIOS Link install guide. For example, to configure
DSPLink on OMAP3530, run the following commands:
cd <DSPLINK_INSTALL_DIR>\dsplink\etc\host\scripts\msdos
dsplinkenv.bat
dsplinkcfg.bat --platform=OMAP3530 --nodsp=1 --dspcfg_0=OMAP3530SHMEM --dspos_0=DSPBIOS5XX --gppos=WINCE --comps=poslm
To configure
DSPLink on DM6446, run the following commands:
cd <DSPLINK_INSTALL_DIR>\dsplink\etc\host\scripts\msdos
dsplinkenv.bat
dsplinkcfg.bat --platform=DAVINCI --nodsp=1 --dspcfg_0=DM6446GEMSHMEM --dspos_0=DSPBIOS5XX --gppos=WINCE --comps=poslm
The dsplinkk.dll will be present in the %_WINCEROOT%\PLATFORM\<BSP_FOLDER>\target\ARMV4\retail. You will need to copy it to the %_FLATRELEASEDIR%
Copy the cmemk.dll file for your board from the WINCEUTILS_INSTALL_DIR
directory to the %_FLATRELEASEDIR% directory. For example,
if you are using OMAP3530, copy the file from
WINCEUTILS_INSTALL_DIR\packages\ti\sdo\winceutils\cmem\src\module\OMAP3530\obj\ARMV4I\retail
Note: You may also want to copy the file into the
%_WINCEROOT%\PLATFORM\<BSP_FOLDER>\FILES
directory, since doing a clean build of the BSP will wipe out
the release directory.
Copy the lpmdrv.dll and lpmdrv.pdb files for your board
from the $(LPM_INSTLL_DIR) directory to the %_FLATRELEASEDIR% directory.
For example, if you are using OMAP3530, copy the files from
LPM_INSTALL_DIR\packages\ti\bios\power\drivers\wince\omap3530\lpm\obj\ARMV4I\retail
Note: You may also want to copy these files into the
%_WINCEROOT%\PLATFORM\<BSP_FOLDER>\FILES
directory, since doing a clean build of the BSP will wipe out
the release directory.
Since new files have been added to the %_FLATRELEASEDIR% directory,
you will need to rebuild the BSP. Select the following menu command from
Visual Studio
Build > Make Run-Time Image
This step is optional, but recommended if you plan to modify the samples in any way. It will ensure you have a backup copy of the original examples, as provided by the Codec Engine product.
At the root of the Examples directory is a build-related file named xdcpaths.mak that all Codec Engine example makefiles include. Almost all users must edit this file to specify where various software components needed by Codec Engine are on their system, and often to narrow the list of hardware platforms to build for (thereby reducing the example build time and possibly the scope of external components).
The variables defined in xdcpaths.mak that most users must assign are: DEVICES, GPPOS, PROGRAMS, and various *_INSTALL_DIR variables. Each are described more below as well as in comments throughout the xdcpaths.mak file.
Advanced users will note that these GNU make-based variables can be overridden on the command line. As a result, it is possible to tailor these makefiles without modifying them - by simply setting the variables on the command line when running "gmake".
The DEVICES variable indicates which hardware platforms should be built for. Most users are only interested in building for a single platform, and the other platforms can be removed from the DEVICES variable.
Note that there is a one-to-one mapping between the "short name" in the DEVICES macro and the "platform package" which is used. For example, the OMAP3530 value in DEVICES maps to the ti.platforms.evm3530 platform package.
The GPPOS variable indicates which GPP (General Purpose Processor, often an ARM) OS's should be built for. Most users are only interested in building for a single GPP OS (e.g. WinCE or Linux glibc or Linux uClibc), and the other GPP OS's can be removed from the GPPOS variable.
Note that there is a one-to-one mapping between the "short name" in the GPPOS macro and the "target module" which is used. For example, the WINCE value in GPPOS maps to the microsoft.targets.arm.WinCE target Module.
The PROGRAMS variable indicates roughly which system architecture the examples should be built for. Generally, Codec Engine supports "local" and "remote" codecs, and as a result there are 3 types of executables that can be built - APP_LOCAL, APP_CLIENT and DSP_SERVER.
APP_LOCAL indicates that all examples that support the apps and codecs running on the same processor should be built. This is typically set for single core devices (e.g. DM365, DM6437), but can als be set for multi-core devices (e.g. OMAP3530, DM6446) where the app and codec run on either the GPP or the DSP.
APP_CLIENT and DSP_SERVER typically go together, and indicate that all examples that support remote execution of codecs should be built. If DSP_SERVER is set in the PROGRAMS variable and an appropriate multi-core platform is set in the DEVICES variable, the examples in examples/ti/sdo/ce/examples/servers may be built. APP_CLIENT indicates the "client" side of a "client/server" system, so GPP-side apps will be built (for the appropriate GPP OS's and hardware platforms set in GPPOS and DEVICES respectively).
Note that you can set all 3 (APP_LOCAL, APP_CLIENT, and DSP_SERVER) or any subset of them. As a further example, if only DSP_SERVER is set, no applications will be built, but all components required to create a server (including codecs) will be built.
The xdcpaths.mak file also contains variables to indicate where products which Codec Engine may depend on are installed. The list of dependent products is a direct result of what values are assigned in the DEVICES, GPPOS and PROGRAMS variables. For example, if you've set PROGRAMS to only APP_LOCAL, DEVICES to only DM355, and GPP_OS to LINUX_UCLIBC, you aren't required to provide DSPLINK_INSTALL_DIR, BIOS_INSTALL_DIR, CGTOOLS_V5T or CC_V5T
Make sure you set the variables WINCE_ROOTDIR and WINCE_PROJECTROOT correctly.
Further, if you're using a "full" installation of Codec Engine (see http://tiexpressdsp.com/index.php?title=Codec_Engine_FAQ#Why_do_some_distributions_have_a_cetools_directory_and_others_don.27t.3F for more details), many of the dependencies will be "auto-assigned" for you to the cetools/packages directory.
Please refer to the comments throughout xdcpaths.mak for more details.
Each directory contains a GNU makefile which enables you to build the sample in the current directory. Top-level directories also contain a makefile which steps into subdirectories and builds all the examples under the parent directory.
FYI, the xdcpaths.mak file is included by the individual makefiles for all the example codecs, servers, and applications.
Please keep in mind that MOST BUILD TROUBLES OCCUR WHEN ONE OF THE VARIOUS *_INSTALL_DIR VARIABLES ARE INCORRECT! Make sure there are no extra spaces (check the end of lines!), that every individual path (segment separated by the semicolon) is correct, character for character, and the build process is very likely to go smoothly.
Open a command window and change directory to ti\sdo\ce\examples\codecs and type
gmake clean
gmake
Alternatively, you can change into a specific codec's directory (e.g. ti\sdo\ce\examples\codecs\viddec_copy), and type
gmake clean
gmake
Change directory to ti\sdo\ce\examples\extensions and type
gmake clean
gmake
Alternatively, you can change into a specific example extension directory (e.g. ti\sdo\ce\examples\extensions\scale), and type
gmake clean
gmake
Note that this is only necessary for dual processor environments, like DM6446.
Change directory to ti\sdo\ce\examples\servers and type
gmake clean
gmake
Alternatively, you can change into a specific server's directory (e.g. ti\sdo\ce\examples\servers\video_copy), and type
gmake clean
gmake
Note: when developing your own codecs and applications, you will likely take one of the DSP server sample and modify it to suit your needs. These are the source files for this server application that you need to know about:
Change directory to ti\sdo\ce\examples\apps (where the makefile is) and type
gmake clean
gmake
For a given application you want to run, you need to copy that application's executable to the target, and if your application requires a DSP server, you need to copy that DSP server to the target as well. (You can see which DSP server -- a DSP binary with .x64P or .x674 extension -- is required by the application if you look at the application's .cfg file.) In addition, you should copy the input data file "in.dat" to the target, keeping the relative position between the application executable and the in.dat file.
Note, you can copy the DSP Server to the target by using the "Windows CE Remote File Viewer" (see Example 1). The Windows CE app and "in.dat" can be copied to the %_FLATRELEASEDIR%, and run with the "Windows CE Command Prompt" (see Example 1).
Also, you must make sure that all the required kernel modules (.dll's) for your target are built into the target image.
Example 1: Running the image1_copy example on evm3530:
The ARM-side of the image1_copy example for evm3530 is in the directory
examples\ti\sdo\ce\examples\apps\image1_copy\bin\ti_platforms_evm3530. Copy the
app_remote_wince.exe file to the %_FLATRELEASEDIR%, along with in.dat -- which is in the
image1_copy directory.
The remote.cfg file in that directory lists "all.x64P" as its
DSP server image, so you must copy the all.x64P DSP executable for
evm3530 from examples\ti\sdo\ce\examples\servers (more precisely
from
examples\ti\sdo\ce\examples\servers\all_codecs\bin\ti_platforms_evm3530\)
to the target. To copy all.x64P to the target, in Visual Studio, open the "Windows CE
Remote File Viewer", by selecting "File Viewer" from the Target->Remote
Tools menu. In the Remote File Viewer, select the File->Export File
menu option, and browse to the server (eg, all.x64P) to download to the
target.
Copy the image1_copy apps to %_FLATRELEASEDIR%. Since various
codec engine examples have the same name, it may be more convenient to just copy
the apps directory to %_FLATRELEASEDIR%. To run the image1_copy example,
open the "Windows CE command prompt" by selecting the Target->Target Control
menu item in Visual Studio. For the local Windows CE app, in the command
prompt type the following command (all one line):
s apps\image1_copy\bin\ti_platforms_evm3530\app_local_wince.exe "Release\\apps\\image1_copy\\in.dat" "Release\\apps\\image1_copy\\local.out.dat"
To run the remote Windows CE app, type the following command:
s apps\image1_copy\bin\ti_platforms_evm3530\app_remote_wince.exe "Release\\apps\\image1_copy\\in.dat" "Release\\apps\\image1_copy\\remote.out.dat"
Last updated: June 19, 2010