Does process() return an error or does it crash?
If it returns an error, there is often an extendedError field that
contains more details - and often the codec data sheets provide details
for codec-specific extendedError values.
If it crashes... that's a bit tougher, but here are some ideas.
In a closed system, where you only have to interoperate with yourself, you can
do whatever you want. I don't think there's any limitation in Codec Engine or
BIOS that will prevent you from calling malloc/free from within your algorithm.
Your algorithm would obviously fail any xDAIS validation
From: Cheng Yang [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 10:19 PM
To: davinci-linux-open-source@linux.davincidsp.com; Ring, Chris
Subject: Re: Memory operation in the DSP side
Thanks! Your answer is very helpful
What failure do you see (crash, error code returned from
VIDENC1_create(), etc)?
Can you set the environment var CE_DEBUG=1, re-run your app and see any
failures in the generated trace?
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Peter
Some details on setting toolchain options here:
http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ#How_do_I_add
_compile_options_when_building_the_example_applications.3F
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Darren
1. Codec datasheets/users guides should contain the codec-specific
extended error codes. (Unfortunately, the extended error codes vary
from codec to codec, so you'll have to consult the codec docs)
3. Which version of Codec Engine? If a recent release (2.00 or later),
you can set a CE_DEBUG
http://www.google.com/search?q=0X80008013
http://www.google.com/search?q=0X80008013
This is Engine_open() failing - 0x80008013 often indicates a memory map
mismatch between the DSP image and your application.
Chris
From: [EMAIL PROTECTED]
, 2008 8:14 AM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: #define for a CE version
Chris,
I am trying to run a CE 1.2 package in CE 2.0.
The only change that I have to do to my CE 1.2 package is to add the
following macro
: Thursday, April 17, 2008 10:36 PM
To: Ring, Chris
Cc: davinci-linux-open-source@linux.davincidsp.com;
[EMAIL PROTECTED]
Subject: RE: GStreamer issue on DaVinci board
Hi Chris,
Thanks for your response.
You had suggested us
Please read through this thread for some further background:
http://www.mail-archive.com/[EMAIL PROTECTED]
om/msg04198.html
That rationalizes _why_ we use CMEM for ARM-side codecs. Ask a followup
if you need more info - I'm not sure we have what you want out of the
box, but we can talk through
CMEM is independent of Link, and is included as a separate product in
the DVSDK. All CMEM sources are provided.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Philip Balister
Sent: Wednesday, May 14, 2008 12:12 AM
To:
This confusing error is caused when the codec's create params are too
big. Often this is seen when the .size field of the create params is
uninitialized.
I don't recall off hand how big too big is, but from the error it may
be 32 32-bit words... or slightly less.
FWIW, there was a bug filed
You've got it right, the upper bits are 'generic'(e.g.
XDM_UNSUPPORTEDPARAM), span all codecs, and are defined in xdm.h.
The lower bits (e.g. 0x1e in your example below) are codec specific.
The User's Guide for your particular codec should describe details about
any bits it sets in this range.
Of Vladimir Pantelic
Sent: Tuesday, May 27, 2008 10:10 AM
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355
Ring, Chris wrote:
Given that... users that need this functionality _today_
may have to
resort to hacks
Sent: Tuesday, May 27, 2008 11:46 AM
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355
Ring, Chris wrote:
Per the xDAIS spec, codecs themselves never allocate
memory, then only
indicate (via the IALG interface) what type
Regarding the missing header file, are you a DVSDK user?
If so, you can probably find EDMA3 LLD product in the DVSDK, and should
be able to add its packages/ directory to your XDCPATH (depending on
your build flow, this may be in an xdcpaths.mak file, or explicitly set
in your environment).
If
The algSettings config params are only applied to algorithm-requested
memory (requested via IALG during VISA *_create() calls). There are two
global params that affect how this algo-requested memory is allocated:
1. algSettings.useHeap is used to alloc from a heap or pool. Pools
are
Looks like you're a Codec Engine user. If you need to update to Link
1.50, you should ensure you use a Codec Engine release that's compatible
with it.
[ Unfortunately, Link 1.40 and 1.50 are not binary compatible, so you
can't just swap it in underneath Codec Engine - CE will get confused. ]
Can you set the environment variable CE_DEBUG=2 and re-run your app?
This may drop some interesting trace describing 'how far' your app got,
and perhaps a clue as to what's failing.
FWIW, I added a brief description of CE_DEBUG here, too:
If you're a codec _producer_, there are details about these files in the
Algorithm Creator User's Guide: http://www-s.ti.com/sc/techlit/sprued6
You can also use the Codec Packaging Wizard to automate generation of
these files in many cases:
Recent releases of xDAIS (since xDAIS 5.21) and Codec Engine (since CE 1.20)
include a golden C G.711 codec (both encode and decode). The Codec
Engine-independent codec is in xdais_X_YY/examples/ti/xdais/dm/examples/g711.
The Codec Engine XDC packaging is in
From: Albert Burbea [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2008 11:07 PM
To: Ring, Chris
Cc: [EMAIL PROTECTED]; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: g711 open source codec
Hi Chris
AFAIK, I think that this codec is not for commercial use... Can you
] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 4:59 AM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Cc: [EMAIL PROTECTED]
Subject: RE: g711 open source codec
Chris,
Thanks for your help.
We are using codec_engine folder for compiling g711.
while compiling we got following
This is described in the CE Algorithm Creator User's Guide (see section 2.2.5
in the latest doc):
http://www-s.ti.com/sc/techlit/sprued6
Each codec Module should implement the getStackSize() function in their
MODULE.xs file. If they _don't_, the default getStackSize() implementation
is used,
The xDAIS manager for ARM algs is buried inside Codec Engine. Internally,
there is a slightly modified port of the old ALG reference API, but we don't
support it independent of Codec Engine.
As a result, it is not as full featured as DSKT2; for example, the framework
doesn't provide lazy
I've seen signal 11 errors come from ld when the linker is asked to link
libs/objs that are incompatible. On one occasion, it was trying to link object
files built with incompatible EABI flags. On another occasion it was trying to
link an ARM object file with a DSP object file(!).
You might
There's a silicon errata that may be applicable - not sure.
Advisory 1.3.1 here:
http://focus.ti.com/lit/er/sprz241k/sprz241k.pdf
... states that the OSD window addressing is limited to 128 MB.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of
There's a good overview here:
http://wiki.davincidsp.com/index.php?title=Cache_Management
... which includes a section on common cache errors and some details about
Codec Engine's support for cache management.
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL
If by open several different Codec servers you mean create multiple codec
instances...
Yes, it's possible create multiple codec instances (e.g. by calling
AUDDEC1_create() multiple times) from the same thread.
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL
No, there's only one DSP, and only one Server image can be loaded on it at a
time.
Chris
From: Asa [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2008 10:58 AM
To: Ring, Chris; dv_mail
Subject: Re: Opening several CE servers
Thanks for the reply.
Actually
, July 14, 2008 8:02 AM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Ring, Chris
Subject: DM6446 : Gstreamer Problem.
Hi Chris and all,
I am working on TI Davinci board (DM6446). We used the Gstreamer port for TI
Davinci for running multimedia applications.I am able to build the Gstreamer
().
There is an example in CE's examples/ti/sdo/ce/examples/extensions/scale
directory you can model your code after.
Chris
From: Veeranna [mailto:[EMAIL PROTECTED]
Sent: Monday, July 14, 2008 10:42 PM
To: Ring, Chris
Subject: Re: Help:: querry on VISA_delete
HI Chris
I believe this is defined by the TI codegen and is undocumented(!). The next
release of xDAIS has updated examples where that preprocessor guard is replaced
with:
#ifdef __TI_COMPILER_VERSION__
#endif
The __TI_COMPILER_VERSION__ preprocessor symbol is also defined by the TI
codegen, but it
There's a bottoms up and tops down overview description here:
http://wiki.davincidsp.com/index.php?title=Codec_Engine_Overview
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ondrej Pindroch
Sent: Tuesday, July 29, 2008 5:29 AM
To:
Multiple process support (which includes your multiple application use case)
was added in Codec Engine 2.00. Prior to that release, you're limited to a
single process (multiple threads within that process is supported).
Also, when using multiple processes, if you're running remote algorithms
that didn't
clean up correctly).
Chris
From: minhong [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2008 3:19 AM
To: Ring, Chris; davinci-linux-open-source
Subject: Re: Questions about codec engine
Thanks for the answer for question1.
For question2, I used
Regarding the missing Comm symbols, can you post your DSP-side .cfg script?
Careful if there's any IP in it... this is a big list and DSP servers have lots
of 'interesting' components in them. :) I'm mainly interested in the OSAL/IPC
config.
Chris
-Original Message-
From: [EMAIL
FYI:
http://www.virtuallogix.com/products/vlx-embedded/vlx-for-digital-multimedia.html
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Quiney
Sent: Wednesday, October 01, 2008 5:43 PM
To: Abhishek Bajpai;
From: Abhishek Bajpai [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 11:54 PM
To: Ring, Chris
Cc: Phil Quiney; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Query for BSP of TMS320DM6437
Thanks Ring,
But the link is discussing about the virtual
First, since this is a TI codec, you should ask for it already XDC packaged.
Given an XDC packaged codec, you should be able to just untar it into a
directory, add that directory to your XDCPATH and begin using it from your
app/config script.
The rest of this is
Mat, thanks for posting the follow-up, I'm sure others will appreciate it.
For the archives, the article Mat's referring to is here:
http://wiki.davincidsp.com/index.php?title=Codec_Combos_Evaluation
I've updated the section with a little commentary to help explain the effect of
the patch.
Setting CE_DEBUG=2 (or 3) will provide more details. Turning on trace is the
right way to start.
CMEM provides memory for the algorithm - there are some CMEM-related debugging
techniques documented here:
http://wiki.davincidsp.com/index.php?title=CMEM_Overview
Chris
Great question, and once resolved we need to add this to the wiki article you
indicated. Unfortunately I don't have the answer for you. :(
This linker command file generation is a feature of the XDC tools, which are
migrating into the Eclipse Open Source community. They are maintaining a
From the XDCtools team:
The linker command file is generated using a template that is provided by the
platform, IF the user does not explicitly provide one. You can supply a linker
command file template via:
1. The -linkTemplate option to the configuro
Which version of CE are you using? Might look into this:
http://wiki.davincidsp.com/index.php?title=Link_Arbiter_Daemon
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mat Laibowitz
Sent: Sunday, October 26, 2008 1:19 PM
To:
with any other
tricks/techniques/limitations you dig up!
Chris
From: Mat Laibowitz [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2008 9:01 AM
To: Ring, Chris
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: still trying to access CE from two
Please read through this article - the Codec Engine uses the build types
defined by the XDC tools, and this shows how to integrate this into your build:
http://rtsc.eclipse.org/docs-tip/Consuming_Configurable_Content/makefiles
Fundamentally, you need to add the _generated_ compiler.opt options
Not quite. You shouldn't do xdc.useModule('ti.sdo.ce.image1.IIMGENC1') because
IIMGENC1 is an Interface, not a Module. Kind of the right idea - we need to
get that ti.sdo.ce.image1 support package brought into the executable.
What really should happen is that
http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ#Can_I_have_multiple.2C_different_engines_open_at_the_same_time.3F
Chris
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On
Double-check that your config.bld/user.bld assignment of the C64P target's
.rootdir is valid.
http://rtsc.eclipse.org/docs-tip/Trouble_Shooting#Configuration_fails_with_an_.22incompatible_use_of_the_target_22_error
Chris
From:
This comment isn't quite right either:
I've been faced to a similar issue. Check that the parameters structure exist
as long the Engine run (not allocated on the stack). The TI routine will
simply keep the pointer and use it. It will not copy it.
As far as create params go (specifically for
Quick one... this comment may not be right:
I would be more than happy to use VIDENC1_create - but it
takes a param
structure of VIDENC1_Params - which doesn't support the extended
arguments that I'm trying to change.
So long as the extended fields are _scalars_ (e.g. not pointers), and the
of the size parameter.
Chris
From: Stephen Berry [mailto:s...@i-d-2.com]
Sent: Thursday, February 26, 2009 9:56 AM
To: Ring, Chris
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: using extended params for MPEG4 encoding
Ring, Chris wrote:
Quick one
0x80008018 is RMS_EINVPROT (EINVPROT == Error, invalid protocol), found in
ti/sdo/ce/rms.h. This error occurs if the stubs (ARM-side) and skeletons
(DSP-side) don't speak the same protocol. That is, the marshalling protocol
of arguments in the stubs doesn't match the unmarshalling protocol of
The DSP can only be loaded with one image (Server) at a time. The first app
loads the DSP with App1.x64P. When the 2nd app tries to load the DSP with
App2.x64P, LAD denies the request (error code 3 == LAD_ACCESSDENIED) since the
DSP is already loaded with App1.x64P.
If you need to run App1
Server is only relevant for remote codecs. Remote codecs exist on
processors with full-blown DSP's (e.g. OMAP3, DM644x, etc) and significant
hardware accelerators (e.g. DM357).
The DM355 does _not_ have a DSP, and therefore does not have remote codecs. So
there is no server in the system.
The codecs.decode_slice package is saying I have a library for the
environment/configuration you're building, and it's named
lib/decode_slice.a470MV. It does this via the getLibs() fxn in it's
package.xs file.
Just a sanity check (as this is a common error)... the codec is saying I have
a
To: Ring, Chris
Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Ring, Chris wrote:
It's a bit too much info, but please review the Overview
section here:
http://tiexpressdsp.com/index.php?title=Dma_overview
the
idea.
Chris
-Original Message-
From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
Sent: Friday, April 17, 2009 4:15 PM
To: Ring, Chris
Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Ring
You might review the Server_getNumMemSegs()/Server_getMemStat() API calls
(available at runtime after Engine_open()). These provide statistics about the
memory resources on remote processors.
Calling these services after each codec create/delete may help you better
understand memory usage on
Can you run your app with the CE_DEBUG env var set to 2 or 3?
http://tiexpressdsp.com/index.php?title=CE_DEBUG
Looks like you're DSP load is ok, but something's going wrong locating or
starting the remote alg. CE_DEBUG=3 will increase the amount of trace, as well
as provide the DSP-side
Sorry if I missed it... what version of Codec Engine are you using?
Seems like it's been there forever, but CE_DEBUG was only added in CE 2.x and
later.
Chris
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
Another runtime sanity check - you might use
Engine_getNumAlgs()/Engine_getAlgInfo() to enumerate the algorithms in a given
Engine, including their name and attributes (e.g. whether they're local or
remote, etc).
In this case, the lookup is failing on the ARM-side... are you using
This is most likely because you ran out of DSP-side resources (memory, DMA, HW
accelerators, etc).
If you're using Codec Engine 2.00 or later, you can turn on CE_DEBUG to get
more insight:
http://tiexpressdsp.com/index.php?title=CE_DEBUG
Chris
From:
I don't know the details about these codecs, but if they share a sparse
resource, you may need to configure them with the same groupId. Then the
framework (Codec Engine + Framework Components) will try to grant resources the
codecs request as 'shared' into the groupId - and will ensure the
Just a quick can we talk through this patch a bit note...
I _think_ there are existing codecs on some DaVinci platforms (e.g. DM365) that
are already using this SRAM memory. The current [easy] solution to their use
case was to keep this memory out of the kernel, and simply give it to CMEM to
-Original Message-
From: David Brownell [mailto:davi...@pacbell.net]
On Friday 22 May 2009, Tivy, Robert wrote:
I think the way codecs are going to request SRAM is by
asking for all of it,
Yeech. I hope that's on the list of bugs to fix!
AFAIK, it's not, nor is it a bug.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
All of this discussion isn't relevant to the need for an in-kernel
SRAM allocator upstream. What is being discussed here is various ways
of using or not using it. IMHO, this discussion isn't relevant to
New thread, as requested...
I like Rob/David's suggestion of adding calls to
request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM)
when they're given this SRAM memory to manage to help catch collisions. CMEM
added this recently too, so at least we'd get a nice error msg
The size of that struct is implicitly built into the
ti.sdo.ce.examples.extensions.scale package. Specifically, scale_stubs.c
(the ARM-side code responsible for marshalling the args into a msg for the
DSP-side) needs to be rebuilt if that struct changes.
I think you need to rebuild the
Newer releases - especially of products with kernel mode components like Link
and CMEM - handle cleanup after app crashes better. Which versions are you
using, and which devices (DM644x? OMAP3?)?
Unfortunately, sometimes crashes/reboots are unavoidable - e.g. if a DSP-side
write from a DSP
You mention you're building an ARM application, but the build looks like it's
building a DSP-side server.
If you _are_ building an ARM app, it's wrong that the ti.sdo.ce.osal.bios
package is coming into the picture at all. You might double check that your
ARM-side app's config script is
Looks like there's inadvertent spaces at the end of many of the *_INSTALL_DIR
variable assignments in xdcpaths.mak. Trim this trailing white space.
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
krishnan [mailto:jaya.krish...@samsung.com]
Sent: Tuesday, June 09, 2009 9:51 PM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: ARM application build issue
Hi Chris,
Thank you for the suggestion.
My application is ARM side only, but as you
The XDC docs are good, but [intentionally] vague as they're targeted at a huge
range of developers.
Assuming you're interested in the Codec Engine development flow, this article
is a decent starting point to help understand the basics from codec developer
up the stack to application developer:
This comes up a lot, I'll add this to the CE FAQ.
If you're building a _library_:
* If you're not using XDC's package.bld-based build, you'll have to
explicitly define your 'target' via the -Dxdc_target__=something option.
* If you're using XDC's package.bld-based build, the appropriate
Double check that your ARM-side .cfg script is correctly setting the OSAL
.runtimeEnv to DSPLINK_LINUX. Something like this:
==
/* Load support for the Codec Engine OSAL */
var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');
/* Configure CE to use it's
-
From: Ottavio Campana [mailto:ottavio.camp...@dei.unipd.it]
Sent: Thursday, June 18, 2009 7:01 AM
To: Ring, Chris
Cc: Ottavio Campana; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: have you ever seen this error?
(again, it seems the first time it did not have the list
If possible, I'd recommend removing the osalGlobal.armDspLinkConfig assignment
in your app.cfg script. You should be able to use the default memory map
initialized by Engine.createFromServer():
http://tiexpressdsp.com/index.php/Configuring_Codec_Engine_in_Arm_apps_with_createFromServer
Chris
I agree, it is a bug. It was fixed in CE 2.10.01, released over a year ago,
but unfortunately the DVSDKs are significantly trailing the latest Codec Engine
releases. :(
I've added details about this bug here in the CE 2.00 section:
http://tiexpressdsp.com/index.php/Codec_Engine_Known_Issues
: Thursday, June 25, 2009 9:14 AM
To: Brian G Rhodes
Cc: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Codec Engine 2_23_01 Failure to load Server
Brian G Rhodes wrote:
Chris,
I found that my map is proper, and the issue is elsewhere.
It looks
like
AFAIK, package.bld files are generated automatically. You need to
adjust makefiles for correct toolchains.
FYI, package.bld scripts aren't typically autogenerated, they're source files
that generate cross-platform, cross-toolchain GNU makefiles (package.mak).
Chris
-Original
http://tiexpressdsp.com/index.php/Debugging_the_DSP_side_of_a_CE_application_on_DaVinci_using_CCS
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Sandeep YEDIRE
http://tiexpressdsp.com/index.php/CE_DEBUG
Chris
From: Sandeep YEDIRE [mailto:sandee...@yahoo.co.in]
Sent: Tuesday, July 07, 2009 9:35 PM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Cc: bmi...@acmet.com
Subject: Re: Debugging or using trace
Depending on how you build your server, there may be one auto-generated already
- search for a *.map file in your package/cfg/... directory tree.
As a concrete example, the CE all_codecs example has a .map file in
ti/sdo/ce/examples/servers/all_codecs/package/cfg/bin/platname/all.xext.map
Using the Way Back Machine (internet archive), I was able to find sprz241e.pdf
- you may have luck with the others. Here's what I did:
1. Google for sprz241e to find a URL that used to work.
2. Put that URL into the search box at http://www.archive.org
3. Found one copy of that page archived
a .map file with the -m option. Run 'lnk64P --help' for
the options.
Chris
From: Sandeep YEDIRE [mailto:sandee...@yahoo.co.in]
Sent: Thursday, July 09, 2009 7:59 AM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire; bmi...@acmet.com
FWIW, I dug into the trace logs a little from a framework POV and nothing
jumped out at me. The framework is providing the memory which the codec is
asking for, but ultimately, as you point out in #3, the codec is just returning
error when the framework says hey, codec, time to create
Yes, BIOS, the OS on the DSP, provides a MEM_alloc() fxn. See the BIOS docs
for details.
(If you're an algorithm, and care about XDAIS compliancy, you get dynamic
memory, but you only get one chance to ask for it... via memTabs during your
alg initialization.)
Chris
It's not clear what you're asking, but there are some details and techniques
that may help here:
http://tiexpressdsp.com/index.php/Stack_issues
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
Did you try the suggested fix (highlighted in red below)?
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
chandrashekar reddy
Sent: Tuesday, September 15, 2009 6:02
When the DSP becomes unresponsive well after startup, like in this case, it's
typically b/c some DSP side code has crashed.
Is it always when encoding the 3rd frame (if I counted right)? Does it happen
when encoding different scenes?
Can you connect with CCS and see what the DSP is doing? If
You need to rebuild the CMEM module against the same Linux kernel you're
running on your target.
I added this to the CMEM FAQ so Google finds this next time:
http://tiexpressdsp.com/index.php/CMEM_Overview#CMEM_FAQ
Chris
From:
First, it looks like your on a DM355 or DM365 as this codec is 'local' (i.e.
running on the same processor as your app). That helps eliminate some
complexity (e.g. no DSP Link, and no DSKT2... the warning msg is misleading -
there's no DSKT2 in a DM355/365 system).
Also from the trace, I can
FYI, if you're not familiar with CMEM, there's an overview here:
http://tiexpressdsp.com/index.php/CMEM_Overview
Chris
-Original Message-
From:
davinci-linux-open-source-bounces+cring=ti@linux.davincids
p.com
[mailto:davinci-linux-open-source-bounces+cring=ti@linux.d
Just a quick [hopefully not confusing] clarifying point...
All this discussion is correct assuming all the codecs are 'remote'; that is,
all codecs execute on the DSP. If any codecs are ARM-based (e.g. all the
DM355/365 codecs) and managed by Codec Engine, their XDAIS-requested memory
will
There's an example in
$(CE_INSTALL_DIR)/examples/ti/sdo/ce/examples/apps/speech_copy_LAD that
demonstrates the LAD-based config - does that example build for you? Maybe
compare differences between that example and yours?
Else, perhaps post your app .cfg script and full build output? Setting
Recent Linux Utils releases are available here:
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html
I'm not sure what kernel revision the arago kernels are up to, but I think the
most recent Linux Utils release (2.25.02.08) was validated on a 2.6.33-based
Rob's right, the Link details are intentionally hidden under Codec Engine. But
it's often useful to know what's going on underneath.
There are more details about CE and DSP Link interaction during DSP start/stop
in section 2's Opening an Engine and Closing an Engine here:
Just as an example of what this might be - the newer codec _may_ require more
resources than before (e.g. DMA channels), and if those extra resources aren't
made available (typically done in the .cfg script), the creation may fail.
You may be able to learn more about the exact cause of the
101 - 200 of 203 matches
Mail list logo
