RE: When a decoder process fails
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. We've had a recent influx of support calls where it was simply just the DSP-side codec over-running its stack and crashing - the solution is to reconfigure the codec in the server with a larger stack and rebuild the Server: http://wiki.davincidsp.com/index.php?title=Stack_issues [ This is sometimes very easy to identify if you can connect to the DSP using CCS and look at all the BIOS tasks and their stack usages. If the stack is blown, the task will be highlighted in red. ] Another common 'hang' failure is if the codec _requires_ internal memory but doesn't get it (because, perhaps, there was none left, or the Server wasn't configured correctly). If the codec doesn't get internal memory - yet requires it, it may hang as some DMA-related APIs require access to internal memory. Codecs that can't run without internal _should_ be ensuring the memory they receive is internal... but some don't and will just hang. [ Again, connecting to the DSP using CCS is often helpful to identify this as well - if the DSP is spinning in ACPY3_wait(), this often points at the codec didn't get internal memory but needed it problem. ] Could 'simply' be a bug in the codec that's crashing, too. Probably want to check with your codec vendor and see if there are any known issues or updates available. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vijay Manohar Dogiparthi Sent: Friday, March 21, 2008 12:42 AM To: Davinci-linux-open-source@linux.davincidsp.com Subject: When a decoder process fails Sir, I want to know when a module's *_process() function fails. Opening the Codec Engine, Creation of algorithm instance, Control the behavior the way the algorithm instance runs,... were successful even. When I was decoding, the process function of a algorithm fails.. Please through some light on, the possible conditions for it to fail. How to set the values to the parameters of this function. Help is highly appreciated. Regards, Vijay Manohar Why delete messages? Unlimited storage is just a click away. http://in.rd.yahoo.com/tagline_mail_1/*http://help.yahoo.com/l/in/yahoo /mail/yahoomail/tools/tools-08.html/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Memory operation in the DSP side
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 testing. ( And on that note, here's a quick pitch for the resurrected QualiTI tool available in xDAIS 6.10, and the new TI eXpress DSP wiki here: http://tiexpressdsp.com/wiki/index.php?title=QualiTI_XDAIS_Compliance_Tool ) As your signature indicates you're from a University, this may be an opportunity to share the reasons xDAIS places this restriction on algorithms with your students, and help them understand why calling malloc/free are not good things to do in an open environment. Here are a few: * malloc() and free() are often non-deterministic, so methods calling malloc()/free() lose their determinism * malloc() can fail(!), what should your algorithm do if that happens? xDAIS algs restrict failures due to lack of resources to creation time. * malloc() and free() don't provide fine-grained _types_ of memory requests (e.g. internal, external, scratch, persistent, etc) which complex algorithms typically need. * and as a result, the use of malloc()/free() hinders frameworks (like Codec Engine and Framework Components) from sharing scratch resources across algorithms, which complex systems with many algorithms typically need. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cheng Yang Sent: Thursday, March 27, 2008 8:16 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Memory operation in the DSP side Hi, all I am developping an algorithm for the DSP. In the Codec Engine framework, the codec is run in the DSP/BIOS. And the codec has to be complied with the xDAIS standard. So the codec is not allowed to do any memory alloction operation. It is for the convenience of algorithm users. However, in our project, we are not going to export the codec to others, which means we will provide the DSP server directly. So will it be safe for the codec to do memory operation such as malloc() and free()? Any discussion will be appreciated! Best regards! - Cheng Yang 杨成 Digital Signal Processing and Transmission Lab E.E. Department, Fudan University Shanghai, P.R. China Lab: +86 (0) 21 65643633 Mobile: +86 13818155051 Email: [EMAIL PROTECTED] ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Memory operation in the DSP side
Typically, the 'creation parameters' will provide enough context to allow an algorithm to declare their worst-case-for-this-use-case memory requirements. The creation params are passed in from the application to the algorithm via the IALG_Fxns.algAlloc() function - which is also the fxn through which the alg returns its memory requirements. For example, image decoders will often have maxHeight and maxWidth fields in their creation parameters which the calling application must provide. Given that, the algorithm can respond with its internal memory requirements. In your case, you may find that you can declare your alg's memory requirements as a function of some creation param that will help your alg constrain and declare its worst case mem usage. Hope that helps - we may need a little more detail if you need a more relevant example. Chris 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 ! I want to use malloc() because our algorithm is very complicated. It is difficult to determine how much memory is needed. I mean the memory needed is dynamic for different input data. Therefore it is not convenient to allocate the memory in advance. How do you solve the problem? Requesting a buffer large enough in algAlloc() ? - Original Message - From: Ring, Chris mailto:[EMAIL PROTECTED] To: Cheng Yang mailto:[EMAIL PROTECTED] ; davinci-linux-open-source@linux.davincidsp.com Sent: Friday, March 28, 2008 11:37 AM Subject: RE: Memory operation in the DSP side 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 testing. ( And on that note, here's a quick pitch for the resurrected QualiTI tool available in xDAIS 6.10, and the new TI eXpress DSP wiki here: http://tiexpressdsp.com/wiki/index.php?title=QualiTI_XDAIS_Compliance_Tool ) As your signature indicates you're from a University, this may be an opportunity to share the reasons xDAIS places this restriction on algorithms with your students, and help them understand why calling malloc/free are not good things to do in an open environment. Here are a few: * malloc() and free() are often non-deterministic, so methods calling malloc()/free() lose their determinism * malloc() can fail(!), what should your algorithm do if that happens? xDAIS algs restrict failures due to lack of resources to creation time. * malloc() and free() don't provide fine-grained _types_ of memory requests (e.g. internal, external, scratch, persistent, etc) which complex algorithms typically need. * and as a result, the use of malloc()/free() hinders frameworks (like Codec Engine and Framework Components) from sharing scratch resources across algorithms, which complex systems with many algorithms typically need. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cheng Yang Sent: Thursday, March 27, 2008 8:16 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Memory operation in the DSP side Hi, all I am developping an algorithm for the DSP. In the Codec Engine framework, the codec is run in the DSP/BIOS. And the codec has to be complied with the xDAIS standard. So the codec is not allowed to do any memory alloction operation. It is for the convenience of algorithm users. However, in our project, we are not going to export the codec to others, which means we will provide the DSP server directly. So will it be safe for the codec to do memory operation such as malloc() and free()? Any discussion will be appreciated! Best regards! - Cheng Yang 杨成 Digital Signal Processing
RE: DM355: More than four encoders??
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 Sommerfeld Sent: Friday, April 04, 2008 11:33 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: DM355: More than four encoders?? Hi, I have 4 MPEG4 encoders running successfully on the DM355. So far, my attempts to add a fifth one always result in failure. I don't see any cmem errors occuring, suggesting that CMEM fundamentally has the memory to allocate. I can also configure for 4 encoders and 1 decoder and this works fine. Has anyone tried 5+ MPEG4 encoders yet? I hope I'm not hitting some kind of hard limit. Thanks, Pete ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to specify the compiler option for the codec
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 Longhorn Sent: Saturday, April 12, 2008 1:09 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: How to specify the compiler option for the codec Darren Longhorn wrote: Cheng Yang wrote: Hi, all I am writing my algorithm and generating the codec library. Will anyone tell me how to specify the CCS compiler option? The makefile is generated by xdc tools and there seems to be no way to set my own compiler option. Besides, is it possible to get some timing information in my codec ? The clock() and time() function do not work correctly. There's are javascript for each compiler that you can set in your .bld file(s) to get xdc to add options to the autogenerated makefile. I don't have the source to hand right now, but if you look in config.bld or your user.bld, you should be able to find an example. What I meant to say there was that there are javascript properties for each compiler. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: MJPEG codec - only 14 bytes after encoding ...
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 env var to 1, 2, or 3 to easily get the trace. If an older release, it's not quite as easy... but we can help you. Section 4.8 has the [confusing] details: http://www-s.ti.com/sc/techlit/sprue67 Exactly what you need to do will depend on how your app is written (e.g., if it uses TraceUtils, the how do I get DSP-side trace answer is different than if it doesn't). Please give that section a read, and post a follow-up if you need further help. [ Looking at your use case - if your app.cfg is configuring TraceUtils attrs to SOCRATES_TRACING, the refresh rate is initially set to zero, meaning the ARM-side polling thread will never pull the DSP-side trace contents off the DSP. Once the refresh rate is set to non-zero, the TraceUtil thread will begin pulling trace data off - you may want to look in that doc for the traceutils command pipe and issue a socrates=on to it. Else, change the app.cfg script from SOCRATES_TRACING to something more friendly like FULL_TRACING which has an initial refresh period that's non-zero. ] 4. Often, we've found that the DSP Servers are configured way too close to the edge WRT stack usage. Enabling trace has, on many occasions, caused the stack to be blown. Might check this topic: http://wiki.davincidsp.com/index.php?title=Stack_issues Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ragas sag Sent: Monday, April 14, 2008 9:36 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: MJPEG codec - only 14 bytes after encoding ... Hello Xperts, 1) KIndly comment on the following mentioned error's from the TI processor. How do i analyse or understand the cause ? Error's: a) VIDDEC_process() failed with a fatal error (-1 ext: 0x81d) b) VIDDEC_process() failed with a fatal error (-1 ext: 0x201e) 2) The video decode code fails to run for a video that is more than 10mnts. I tried to run two test vectors ( MPEG 2, *.m2v files) each nearly 20mnts, And each time it hangs/stops at nearly 9 -11 minutes time. Why ? Is their any limitation with the programme ? 3) I want to enable TI side CE trace util activity. I used CE_TRACE=*=01234567 TRACEUTIL_DSP0TRACEMASK=*=01234567 TRACEUTIL_VERBOSE=1 programme name input file nameonly arm side activity is written to a file. I want to collect dsp activity, what do i need to change in the above configuration/setting , to trace / write DSP activity to stdout / file ? Without the need of any *.cgf file. 4) And when i enable the CE_TRACE above, my code crashes / hangs in between why? Due to which what i started out to analyse, end's with something to analyse again. I am placing this question in this forum, hoping that i will get some help to fix my problems. Warm Regards, Ragas ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: GStreamer issue on DaVinci board
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] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 15, 2008 4:30 AM To: davinci-linux-open-source@linux.davincidsp.com; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: FW: GStreamer issue on DaVinci board Hello All, I am getting Process_create failed error messages when running GStreamer. I am usjng MPEG4combo.x64p as codec server. Error messages are: [EXECUTED COMMAND: gst-launch-0.10 --gst-debug-level=0 filesrc location=sample_mpeg4.mp4 ! gdecoder Codec=1 ! ffmpegcolorspace ! ffenc_wmv2 ! ffmux_asf ! filesink location=sample3.avi] Setting pipeline to PAUSED ... Pipeline is PREROLLING ... gdecoder: plugin_init BEGIN.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_base_init BEGIN... gdecoder: gst_gdecoder_base_init END... gdecoder: gst_gdecoder_class_init BEGIN... gdecoder: gst_gdecoder_get_codec_type Begin gdecoder: gst_gdecoder_get_codec_type End gdecoder: gst_gdecoder_class_init END... gdecoder: plugin_init END.. gdecoder: gst_gdecoder_init BEGIN.. gdecoder: gst_gdecoder_reset BEGIN.. gdecoder: gst_gdecoder_reset END.. gdecoder: gst_gdecoder_init END.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_set_property BEGIN...2.. gdecoder: set ARG_CODEC_NAME property gdecoder: Codec set to enum value 1 gdecoder: gst_gdecoder_set_property END... gdecoder: gst_gdecoder_sink_getcaps invoked and call gst_caps_copy gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_change_state BEGIN.. gdecoder: State Changed from NULL_TO_READY gdecoder: gst_gdecoder_change_state END.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_change_state BEGIN.. gdecoder: State Changed from READY_TO_PAUSED gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_sink_activate invoked gdecoder: STREAMING IS FALSE gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_sink_activate_pull BEGIN.. gdecoder: gst_gdecoder_sink_activate_pull END... gdecoder: gst_gdecoder_change_state END.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_loop BEGIN.. gdecoder: gst_gdecoder_process BEGIN0... gdecoder: gst_gdecoder_decoder_initialize BEGIN.. gdecoder: gst_gdecoder_open_engine BEGIN.. gdecoder: Opening MPEG4 Engine... @0x000cf336:[T:0x41a38b60] OP - Process_create_d Loading and starting DSP server FAILED, status=[0x80008013] @0x000cf47d:[T:0x41a38b60] OP - Process_delete_d Closing remote transport FAILED, status=0x8000800b. @0x000cf5c1:[T:0x41a38b60] OP - Process_delete_d Stopping DSP FAILED, status=0x8000801b @0x000cff10:[T:0x41238b60] CE - rserverOpen: can't start './MPEG4Combo.x64P'; Process_create failed gdecoder: Engine_open failed gdecoder: Engine_open failed gdecoder: Fatal error, Open_Engine failed gdecoder: Could Not Initialize Decoder gdecoder: gst_gdecoder_loop END.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_loop BEGIN.. gdecoder: gst_gdecoder_process BEGIN0... gdecoder: gst_gdecoder_decoder_initialize BEGIN.. gdecoder: gst_gdecoder_open_engine BEGIN.. gdecoder: Opening MPEG4 Engine... ERROR: from element /pipeline0/gdecoder0: Could not write to resource. Additional debug info: gstgdecoder.c(971): gst_gdecoder_process (): /pipeline0/gdecoder0: Could Not Initialize Decoder ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_change_state BEGIN.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_sink_activate_pull BEGIN.. @0x000e314e:[T:0x41a38b60] OP - Process_create_d
RE: #define for a CE version
Ah. Can you just stop using the deprecated [really unsupported] Memory_getPhysicalAddress() API? The supported Memory_getBufferPhysicalAddress() is available in both CE 1.20 and 2.00. Chris -Original Message- From: Raghavendra B K [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 15, 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 : ti_sdo_ce_osal_Memory_USEDEPRECATEDAPIS If I have to maintain a single ceapp.c across 1.2 and 2.0, I need to put the above macro inside another macro which is tied to the version of the codec engine. The macro will be needed at build time. Regards Raghavendra. -Original Message- From: Ring, Chris [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 15, 2008 8:14 PM To: Raghavendra B K; davinci-linux-open-source@linux.davincidsp.com Subject: RE: #define for a CE version What are you really trying to do? Do you need this at build time, config time, runtime, or all? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Raghavendra B K Sent: Tuesday, April 15, 2008 3:10 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: #define for a CE version All, Is there a preprocessor directive (#define) or a global switch which can be used to distinguish between 2 versions of Codec Engine? Regards, Raghavendra ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] ** ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: GStreamer issue on DaVinci board
When VIDDEC_process() hangs, do you have tracing enabled? If so, does
it also hang when there is no tracing enabled? I'm grasping at straws,
but we've seen several occasions where the servers were built with stack
sizes so close to the edge that even turning on trace will cause them to
overrun their stack and cause a crash.
It seems like the GStreamer distribution has the right memory map (as
Engine_open() succeeds, and even VIDDEC_create() succeeds!). The
loadmodules.sh script you tried has a different memory map, and because
Engine_open() is failing, that makes me think it's incorrect for the
server you're using. So... I think you should stick with the first, and
see if we can find why VIDDEC_process() is crashing.
And for your last comment, when VIDDEC_process() returns -1, it should
also be returning a value in the 'extendedError' field that may provide
further context (maybe something as simple as unsupported parameter).
These extendedError's are typically codec specific, so you likely would
need the codec data sheets to interpret them further.
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 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 to look into memory mismatch. But in our
case, both the DSP image (the codec servers) and the application
(gdecoder) are from TI. The memory map required for TI's GStreamer
implementation is packaged in their download. Even with that memory map,
however, we were getting an error.
Below are the steps that we have executed:
***
We executed the code using the memory map specified in the TI
GStreamer Plugins files. The script that sets it is as follows
(equivalent to loadmodules.sh in the DVEVM directory):
insmod cmemk.ko phys_start=0x8780 phys_end=0x88E0
pools=20x4096,8x202752,10x131072,2x1048576,1x2097152,18x614400
insmod dsplinkk.ko ddr_start=0x8F80 ddr_size=0x60
rm -rf /dev/dsplink
mknod /dev/dsplink c `awk \\$2==\dsplink\ {print \\$1}
/proc/devices` 0
We executed this with MPEG4combo.x64p as codec server.
It was not returning from the VIDDEC_process API call and on
pressing Ctrl-C, started to pre-roll the pipeline hanging there. On
pressing another Ctrl-C, the system hanged and had to be rebooted.
Now, the original loadmodules.sh script that came with DVEVM has
the following commands:
insmod cmemk.ko phys_start=0x8780 phys_end=0x8800
pools=1x3145728,5x829440,1x61440,1x10240
# insert dsplinkk, tell it that DSP's DDR is at physical
250MB-254MB
insmod dsplinkk.ko ddr_start=0x8fa0 ddr_size=0x40
rm -f /dev/dsplink
mknod /dev/dsplink c `awk \\$2==\dsplink\ {print \\$1}
/proc/devices` 0
These settings gave the Process create failure error, which is
presumably due to memory map mismatch.
***
To make sure for version compatibility we are using released
tested version of GStreamer with DVSDK 1.2
I have tried two different versions of the open source component
of GStreamer - 0.10.11 (which TI has packaged) and 0.10.17 (the latest
from GStreamer website). Both rendered the same results.
One experiment I did has actually provided a different behavior.
I changed the command executed to include a max buffer sizes for queues
(in line with the demo scripts from TI). So the command looks like:
gst-launch-0.10 --gst-debug-level=0 filesrc
location=sample_mpeg4.mpeg4 ! queue max-size-buffers=60 ! gdecoder
Codec=1 ! queue max-size-buffers=180 ! ffmpegcolorspace ! videorate !
video/x-raw-yuv,framerate=10fps ! avimux ! filesink location=sample3.avi
On running this, we do not get the hanging VIDDEC_process
anymore. However, it returns a -1 (without much trace information) so
the decoding fails.
Hope to hear from you.
Regards,
Jitendra
Ext: 864
From: Ring, Chris [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 15, 2008 7:14 PM
To: Jain, Jitendra [PROTOOL/RTC/INPU];
davinci-linux-open-source@linux.davincidsp.com; [EMAIL PROTECTED
RE: Any way for CE to alloc non-cmem memory during create to ARM onlycodecs.
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 it further. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Omkiran Sharma Sent: Thursday, May 08, 2008 10:52 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Any way for CE to alloc non-cmem memory during create to ARM onlycodecs. Hi, ARM only codecs should have no need for CMEM memory. By default it appears that CE now allocates CMEM memory to the local codecs during create (ialg based memtab requests). I could find a Memory_type enumeration in the osal headers, however I could not figure out if there is any way to configure the codec engine such that it will give non cmem buffers to the local codec during creation. Is there any setting I can set in the cfg file for the same? (Something similar to what we do for DSKT2, where we can specify the heap the memory can come from) Regards, Omkiran ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: did you try openembedded?
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: davinci-linux-open-source@linux.davincidsp.com Subject: Re: did you try openembedded? [EMAIL PROTECTED] wrote: I'd like to try openembedded instead of the old montavista that came with my board. My problem is that I cannot understand how I can integrate cmemk, dsplink and all the CE infrastructure with openembedded. I'd like to hear if somebody has ever done it. I have started to look at adding a recipe to OE for dsplink. Is the source for cmemk part of dsplink, if not, where can I get it? Philip ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Engine_createNode error
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 (and fixed) to clean up the error message. For the archives, the ID was SDSCM00019266, and it was fixed in CE 2.00. In that release and newer, if the create params are too big the create() call will return a error before going down to the DSP, rather than generate the confusing assert msg. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of linuxvom Sent: Wednesday, May 14, 2008 8:41 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Engine_createNode error hi all i'm linking my alg lib made by CCS into CodecEngine,but when called VIDENC_create from gpp side error occurs like below: -- - @0x00119a02:[T:0x4003a6e8] ti.sdo.ce.video.VIDENC - VIDENC_create Enter (server =0x28650, name='videnc', params=0xbefffc58) @0x00119b0e:[T:0x4003a6e8] CV - VISA_create(0x28650, 'videnc', 0xbefffc58, 0x828 , 'ti.sdo.ce.video.IVIDENC') @0x00119be8:[T:0x4003a6e8] CE - Engine_createNode(0x28650, 'videnc', 828, 0xbeff fc58) @0x00119ca0:[T:0x4003a6e8] OC - Comm_create Enter(queueName='gppfromnode', msgq Queue=0x28878, attrs=0x0) @0x00119e57:[T:0x4003a6e8] OC - Comm_create return (0x28898) app.out: Engine.c:184: Engine_createNode: Assertion `nodeAttrs-size = (sizeof (RMS_Word) * 32)' failed. Aborted -- --- what's the meaning yet? what is nodeAttrs-size? can anybody help me thanks ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Regarding : xDM error's..
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. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ragas sag Sent: Monday, May 19, 2008 6:01 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Regarding : xDM error's.. Dear Xperts, When i am running an MPEG 4 stream using the decode() demo, I am getting some xDM error's. And this is the best place to get some answer's for my question's. I am using DM6446 DVEVM. I am getting the following error's. VIDDEC_process() 1 failed with a fatal error (-1 ext: 0x201e) I haven't been able to understand or make something of the error being thrown. And 0x201e = 10 0001 1110 ^ According to TI : XDM_UNSUPPORTEDPARAM = 14, /** Bit 14 - Unsupported input parameter or configuration ). I obtained the detail's about Extended Error , present in xdm.h file. Am i right about the Bit 14 above ? 1) How do i understand or make out details about the other bit's in the error message ? 2) Guide me to some material or documention on these error's ? I was not able to get much information. 3) What is that unsupported input parameter / configuration ? 4) Any error handling mechanism ? I would be really happy if anybody out their, could guide me. It's been bothering me from some time. Thank you in advance Warm Regards, Sagar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Cache issue with MPEG4 Encoder / Decoder on DM355
Per the xDAIS spec, codecs themselves never allocate memory, then only indicate (via the IALG interface) what type of memory they require... the actual allocation is delegated to the framework (e.g. Codec Engine). So the codec should never make calls malloc() itself. (One reason not to 'hack it' is that CE may not give the codec the call to free() it! Because the codec is passive, the framework can free the codec just by not calling it anymore and freeing its resources) The issue is that, while xDAIS allows the codec to indicate _some_ of the memory constraints (e.g. size, alignment, etc), it doesn't define any way to indicate cacheability or physical-contiguousness. (Per my original reply, that's the gap we're intending to close in a Q3 release.) Chris -Original Message- From: [EMAIL PROTECTED] p.com [mailto:davinci-linux-open-source- [EMAIL PROTECTED] On Behalf Of Vladimir Pantelic Sent: Tuesday, May 27, 2008 11:09 AM Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355 Tivy, Robert wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf 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 in the near term. One system-specific hack/approach could be to modify CMEM to identify all the alloc requests from the audio codecs (perhaps by size?), and convert all the requests identified for the audio codecs as cacheable, regardless of whether it's asked for cacheable or not. Yes, it's a hack, but might get you past this until we have more official support in xDAIS/CE. Couldn't the ARM side audio codec just use malloc() instead of calling whatever code to request memory from CE? If the ARM side codec uses HW accelerators then it probably still needs contiguous memory from CMEM. If it's just using CPU reads/writes then it could use malloc(). Yes, but the point is about the conflict of video codecs needing *non-cached* CMEM and audio codecs needing *cached* (CMEM or other) memory. So I am asking whether the audio codec can just use malloc()/free() to get it's buffers instead of going through whatever means CE offers for memory allocation. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Cache issue with MPEG4 Encoder / Decoder on DM355
You can try rand()... lemme know how that works out for you. ;) We need to get xDAIS updated to understand these other memory spaces - it's long overdue. We just haven't seen customer demand force the issue as most xDAIS codecs are running on more embedded OS's (like DSP BIOS) without virtual memory or where cacheability on a per-buffer granularity isn't feasible. Linux is a good place to help push xDAIS forward... but we've got some growing pain to get through. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Vladimir Pantelic 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 of memory they require... the actual allocation is delegated to the framework (e.g. Codec Engine). So the codec should never make calls malloc() itself. (One reason not to 'hack it' is that CE may not give the codec the call to free() it! Because the codec is passive, the framework can free the codec just by not calling it anymore and freeing its resources) ah, ok, didn't know that. The issue is that, while xDAIS allows the codec to indicate _some_ of the memory constraints (e.g. size, alignment, etc), it doesn't define any way to indicate cacheability or physical-contiguousness. (Per my original reply, that's the gap we're intending to close in a Q3 release.) Yes, I was just trying to find a more clever hack, how about rand() instead of malloc(), no free() needed :-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: EDMA channel acqusition through IRES using Codec Engine 2.00 onDM6446
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 you're not a DVSDK user, you'll need to get the EDMA3 LLD product from here: https://www-a.ti.com/downloads/sds_support/targetcontent/psp/edma3_lld/i ndex.html A few things to note: * Codec Engine doesn't have a direct dependency on this EDMA3 LLD product, which explains why it's not in the cetools/packages directory and isn't mentioned in the CE release notes. (It's a fine line between where cetools is today, and it becoming a mini-DVSDK. I don't want to throw everything in there... but I can sympathize with you on this particular issue) * Framework Components _does_ have a dependency on it, so you _will_ find the required version in the FC release notes. And if you get FC 2.00 standalone release - independent of the DVSDK - you'll also find the right version of the EDMA3 LLD in FC 2.00's fctools/packages directory. * A quick peek at FC 2.00's release notes shows that the right version of the EDMA3 LLD product is the 1.01 release. I know this is confusing, but there is some [attempted, and continuously improving?] logic to it. There are some details about the cetools and fctools philosophy here: http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ#Why_do_some_ distributions_have_a_cetools_directory_and_others_don.27t.3F I can't address the DMA question, but others on the list probably can. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of prashanth shankar Sent: Monday, June 02, 2008 7:19 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: EDMA channel acqusition through IRES using Codec Engine 2.00 onDM6446 Hi, I have Codec Engine 2.00 package for DM6446 and it has ce_tools packages inside it. I want to acquire EDMA channels through IRES for my codec. I first tried to acquire the EDMA channels by adding the IRES interface functions in the viddec_copy example. It is required to include the header file #include ti/sdo/fc/ires/edma3chan/iresman_edma3Chan.h in the server main.c file. But this header file inturn asks for the header file #include ti/sdo/edma3/rm/edma3_rm.h and the folder ti/sdo/edma3 is not present in Codec Engine 2.00 package. Hence I am not able to build the server exectuable. Also, I want to know how to configure the transfer on thus acquired channel. Should I have to get the physical address of the Event Set Register and perform AND opertion on this register with the contents of esrBitMaskL and esrBitMaskM values that are present in the IRES_EDMA3CHAN_Obj that is returend after the EDMA channel resource is acquired. Also should I have to get the physical address of the Interrupt pending register and perform AND opertion on this register with the contents of iprBitMaskL and iprBitMaskM values that are present in the IRES_EDMA3CHAN_Obj and poll on the corresponding bit for the transfer complete. I would require some help to reslove this issue. Thanks and Regards, Prashanth ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: useHeap option on DM355
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 typically more difficult to configure right, heaps are subject to
fragmentation. Often development starts with heaps, then migrates to
pools once the requested sizes become known and stable.
2. algSettings.useCache is used to alloc from cacheable memory.
Both are [lightly] documented here:
https://www-a.ti.com/downloads/sds_support/targetcontent/CE/ce_2_10/code
c_engine_2_10_01/xdoc/index.html#ti/sdo/ce/alg/Settings.html
Neither of these settings affect the application requested memory. Apps
can still use CMEM directly, and/or the Memory_* APIs to request
whatever type of memory they need (cached/non-cached, heap/pool, etc).
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Divya Varadarajan
Sent: Thursday, June 05, 2008 8:56 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: useHeap option on DM355
Hi all,
I am trying to integrate some speech codecs (using Codec Engine) on
DM355 and have the following query.
Codec Engine uses CMEM to allocate the memory for all components(local
or remote), however there is an option
available which specifies the usage of heap memory(The option is given
below)
algSettings = xdc.useModule('ti.sdo.ce.alg.Settings');
algSettings.useHeap = true;
Can anyone please clarify as to what this option is for?
Once I select this option will the memory I access be from
CMEM or heap?
Also if the memory I access through any local component is from heap
,then will it be cached(taking into consideration that ARM memory is
cached)?
Thanks in advance,
Divya
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: problem with memory map in dsplink_1_50
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. ]
This article shows some details on what CE releases work with which
underlying components:
http://wiki.davincidsp.com/index.php?title=Codec_Engine_Roadmap
From that article, you can see that you must update to CE 2.10 if you
want to use Link 1.50.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of SergA
Sent: Friday, June 06, 2008 6:25 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: problem with memory map in dsplink_1_50
Hi.
Early I worked with dsplink_1_40, my app work fine. Now I try pass to
dsplink_1_50.
And now I get the following error:
Error: DSP-side memory map does not match configuration.
Compare DSP-side TCF/MAP file with
/dsplink/config/all/CFG_PLATFORM.c
There is a pice of my DSP servers TCF file:
{
comment:DDRALGHEAP: off-chip memory for dynamic algmem
allocation,
name: DDRALGHEAP,
base: 0x84e0, // 78MB
len:0x02c0, // 44MB
space: code/data
},
{
comment:DDR: off-chip memory for application code and data,
name: DDR,
base: 0x87A0, // 122MB
len:0x0020, // 2MB
space: code/data
},
{
comment:DDRCode: off-chip memory for application code,
name: DDRCode,
base: 0x87C0, // 124MB
len:0x001ff000, // 2MB - 4KB
space: code/data
},
{
comment:DDRSeqCode,
name: DDRSeqCode,
base: 0x87DFF000, // 126MB - 4KB
len:0x1000, // 4KB
space: code/data
},
{
comment:DSPLINK: off-chip memory reserved for
DSPLINK code and
data,
name: DSPLINKMEM,
base: 0x87E0, // 126MB
len:0x0010, // 1MB
space: code/data
},
{
comment:RESET_VECTOR: off-chip memory for the reset vector
table,
name: RESET_VECTOR,
base: 0x87F0, // 127MB
len:0x0080, // 128B
space: code/data
}
I pass memory map to dsplink in my application:
osalGlobal.armDspLinkConfig = {
memTable: [
[DDRALGHEAP, {addr: 0x84e0, size:
0x02c0, type: other}],
[DDR, {addr: 0x87A0,
size: 0x0040, type: main }],
[DSPLINKMEM, {addr: 0x87E0, size:
0x0010, type: link }],
[RESETCTRL, {addr: 0x87F0, size:
0x0080, type: reset}],
],
doPowerControl: true,
};
I try to correct /dsplink/config/all/CFG_Davinci_DM6446.c,
and recompile
dsplink and my app. But this error still appear.
Help me please, what is incorrect?
Best regards.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Video Decode algoritm creation issue in TMS320DM6467
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: http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ#What_should_ I_do_first.3F Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Santoshkumar GK Sent: Tuesday, June 10, 2008 2:38 AM To: Davinci_linux_open_source (E-mail) Subject: Video Decode algoritm creation issue in TMS320DM6467 Hi, I am working on TMS320DM6467 board. I gone through the decode demo provided by TI. For video decode algorithm creation they are using Vdec2_create() API. But the same doesnt work in my application, the creation of algorithm is failing. I tried using VIDDEC2_create(),VIDDEC_create() with suitable changes in the parameters. Can u please let me know why this am i getting this problem. Thanks and Regards, Santosh Kumar G.K The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: codec_engine_1_02 folder's content info
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: http://wiki.davincidsp.com/index.php?title=RTSC_Codec_And_Server_Package _Wizards In brief, these files help manage 'packages', which are essentially the unit of delivery of a component. Some of these files are used for building and releasing the package (e.g. package.bld), some are used to describe the content of the package to the XDC Tools during the config step (e.g. G711DEC.xdc and G711DEC.xs). Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] com] On Behalf Of Ramesh Sent: Monday, June 16, 2008 2:39 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: codec_engine_1_02 folder's content info Hi all, Now I am studying Codec engine. I have codec_engine_1_02. I could understand some lines of the CS.XDC,BLD and makefile. Does any document tells very clearly that how the files are placed with an example. Thanks Ramesh. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: g711 open source codec
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 codec_engine_X_YY/examples/ti/sdo/ce/examples/codecs/g711 if you want to use it in Codec Engine framework. [ If you want to find your own copy, Google for sun g711 filetype:c. ] These are examples, so they're not optimized at all, but they are xDM compliant (implementing the ISPHENC1 and ISPHDEC1 interfaces) and packaged for use by Codec Engine. It's also in straight C code, so it can run on an ARM, DSP, or just about anything else you want to build it for. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, June 15, 2008 10:05 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: g711 open source codec Hello All, We are looking for G711 open source codec running on ARM of DM6446. If anyone has idea about it or have link/documents kindly let us know. Thanking you all in advance. -Jitendra ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: g711 open source codec
The banner at the top of the source file says this: /* * This source code is a product of Sun Microsystems, Inc. and is provided * for unrestricted use. Users may copy or modify this source code without * charge. * * SUN SOURCE CODE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING * THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR * PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. * * Sun source code is provided with no support and without any obligation on * the part of Sun Microsystems, Inc. to assist in its use, correction, * modification or enhancement. * * SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE * INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY THIS SOFTWARE * OR ANY PART THEREOF. * * In no event will Sun Microsystems, Inc. be liable for any lost revenue * or profits or other special, indirect and consequential damages, even if * Sun has been advised of the possibility of such damages. * * Sun Microsystems, Inc. * 2550 Garcia Avenue * Mountain View, California 94043 */ I'm not a lawyer, so interpret this as you see fit. To my non-lawyer eyes, unrestricted use means I can do whatever I want with it, which is how I justified shipping it as an example. But I can't stress enough that my comments shouldn't be taken as legal advice!!! If legal advice is what you're looking for, this list is not likely the place to find it. Chris 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 pls check? Albert On 6/18/08, Ring, Chris [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: 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 codec_engine_X_YY/examples/ti/sdo/ce/examples/codecs/g711 if you want to use it in Codec Engine framework. [ If you want to find your own copy, Google for sun g711 filetype:c. ] These are examples, so they're not optimized at all, but they are xDM compliant (implementing the ISPHENC1 and ISPHDEC1 interfaces) and packaged for use by Codec Engine. It's also in straight C code, so it can run on an ARM, DSP, or just about anything else you want to build it for. Chris From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, June 15, 2008 10:05 PM To: davinci-linux-open-source@linux.davincidsp.commailto:davinci-linux-open-source@linux.davincidsp.com Subject: g711 open source codec Hello All, We are looking for G711 open source codec running on ARM of DM6446. If anyone has idea about it or have link/documents kindly let us know. Thanking you all in advance. -Jitendra ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.commailto:Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: g711 open source codec
http://linux.omap.com/pipermail/davinci-linux-open-source/2008-January/005075.html In examples/xdcpaths.mak, make sure you set * REQUIRE_FC to 1 * FC_INSTALL_DIR to the location of your Framework Components installation. Chris From: [EMAIL PROTECTED] [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 errors: ** # all files complete. all files complete: Wed Jun 18 17:27:38 IST 2008. make[1]: Leaving directory `/home/jitu/temp/examples/ti/sdo/ce/examples/apps/speech/dsponly' make -C speech/linuxonly all make[1]: Entering directory `/home/jitu/temp/examples/ti/sdo/ce/examples/apps/speech/linuxonly' XDCPATH=/home/jitu/temp/examples/ti/sdo/ce/examples/apps/speech/linuxonly/../../../../../../..;/home/jitu/g711/dvsdk_1_30_00_23/codec_engine_2_00/packages;/home/jitu/g711/dvsdk_1_30_00_23/xdais_6_00/packages;/packages;/home/jitu/g711/dvsdk_1_30_00_23/cmem_2_00/packages;/packages /home/jitu/g711/dvsdk_1_30_00_23/xdc_3_00_02_11/xs xdc.tools.configuro -c /opt/mv_pro_4.0/montavista/pro/devkit/arm/v5t_le -o app \ -t gnu.targets.MVArm9 -p ti.platforms.evmDM6446 \ app.cfg making package.mak (because of package.bld) ... generating interfaces for package app (because package/package.xdc.xml is older than package.xdc) ... configuring app.x470MV from package/cfg/app_x470MV.cfg ... js: /home/jitu/g711/dvsdk_1_30_00_23/xdc_3_00_02_11/packages/xdc/cfg/Main.xs, line 248: exception from uncaught JavaScript throw: Error: xdc.loadPackage: can't find package 'ti.sdo.utils.trace' along the path '/home/jitu/temp/examples;/home/jitu/g711/dvsdk_1_30_00_23/codec_engine_2_00/packages;/home/jitu/g711/dvsdk_1_30_00_23/xdais_6_00/packages;/packages;/home/jitu/g711/dvsdk_1_30_00_23/cmem_2_00/packages;/home/jitu/g711/dvsdk_1_30_00_23/xdc_3_00_02_11/packages;/home/jitu/g711/dvsdk_1_30_00_23/xdc_3_00_02_11/packages;/home/jitu/temp/examples/ti/sdo/ce/examples/apps/speech/linuxonly/app/./..;'; try redefining the package path (XDCPATH). /home/jitu/g711/dvsdk_1_30_00_23/xdc_3_00_02_11/packages/xdc/cfg/Main.xs, line 154 /home/jitu/g711/dvsdk_1_30_00_23/xdc_3_00_02_11/packages/xdc/xs.js, line 144 gmake: *** [package/cfg/app_x470MV.c] Error 1 make[1]: *** [app] Error 2 make[1]: Leaving directory `/home/jitu/temp/examples/ti/sdo/ce/examples/apps/speech/linuxonly' make: *** [all] Error 2 End of error messages ** Can anyone throw light on this? -Jitendra -Original Message- From: Ring, Chris [mailto:[EMAIL PROTECTED] Sent: Wed 6/18/2008 8:22 AM To: Jain, Jitendra [PROTOOL/RTC/INPU]; davinci-linux-open-source@linux.davincidsp.com Subject: RE: g711 open source codec 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 codec_engine_X_YY/examples/ti/sdo/ce/examples/codecs/g711 if you want to use it in Codec Engine framework. [ If you want to find your own copy, Google for sun g711 filetype:c. ] These are examples, so they're not optimized at all, but they are xDM compliant (implementing the ISPHENC1 and ISPHDEC1 interfaces) and packaged for use by Codec Engine. It's also in straight C code, so it can run on an ARM, DSP, or just about anything else you want to build it for. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, June 15, 2008 10:05 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: g711 open source codec Hello All, We are looking for G711 open source codec running on ARM of DM6446. If anyone has idea about it or have link/documents kindly let us know. Thanking you all in advance. -Jitendra ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to specify codec stack size? DM6446
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, which prints out the msg below as a warning and uses 1024 integers - in your case, 4kB. If you use the Codec Packaging Wizard, this getStackSize() implementation is generated for you by actually interrogating your codec library(!) to determine the worst case stack usage: http://wiki.davincidsp.com/index.php?title=RTSC_Codec_And_Server_Package_Wizards And finally, there is some associated reading about stack usage and issues here: http://wiki.davincidsp.com/index.php?title=Stack_issues Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mohamed AbdElwahed Sent: Thursday, June 19, 2008 4:45 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: How to specify codec stack size? DM6446 Kindly i want to know, How to set a specific DSP codec stack size? currently, In my codec i have this Msg, Codecs.xxx.XXX did not supply a stack size; assuming 4096 bytes is sufficient is there any help, and/or document to read it. thanks very much -- Mohamed AbdElwahed Ibrahim Get news, entertainment and everything you care about at Live.com. Check it out!http://www.live.com/getstarted.aspx ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM warnings during codec create
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 deactivation of ARM algs. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tivy, Robert Sent: Friday, June 20, 2008 9:52 AM To: Omkiran Sharma; davinci-linux-open-source@linux.davincidsp.com Subject: RE: CMEM warnings during codec create This warning is produced at GT trace level 6, so it can be disabled by not enabling 6 in CE_TRACE (but CE_DEBUG=[1|2|3] might turn it on). The simplest solution is to pass Memory_DEFAULTALIGNMENT in the align parameter. I'm not sure about the DSKT2 question, perhaps the answer is IRES/RMAN? Regards, - Rob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Omkiran Sharma Sent: Friday, June 20, 2008 2:31 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: CMEM warnings during codec create Hi, During codec create we get a warning saying that pool based allocation does not support an alignment using default alignment 0x during codec create. While it does not cause any issues, is there any way to switch of this warning? This raised another question in my head: While we have a DSKT2 manager on the DSP, who is the manager on the ARM side? Regards, Omkiran ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: problem in building code using montavista 4.0.1
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 check your link line, and the libs you're trying to link together. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Santoshkumar GK Sent: Monday, June 23, 2008 11:09 PM To: Davinci_linux_open_source (E-mail) Subject: problem in building code using montavista 4.0.1 Hi, I am woking on TMS320DM6467 EVM board. I am trying to build my code using montavista 4.0.1 tool chain. But I am getting segmentation fault at last with the following message collect 2: ld terminated with signal 11. My code is getting compiled using montavista 4.0 tool chain. The decode demo builds with montavista 4.0.1 and gives error when building by montavista 4.0 toolchain. can u please suggest me a solution on bulding my code using montavista 4.0.1. And is there any difference between both tool chains because demo code is not building in 4.0.Please reply as soon as possible. Regards, Santosh Kumar G.K The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davincifb driver works only at reserver memory 120M-126M usingioremap
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 steven.zhang Sent: Thursday, June 26, 2008 8:31 PM To: Tivy, Robert Cc: torran; davinci; [EMAIL PROTECTED] Subject: RE: davincifb driver works only at reserver memory 120M-126M usingioremap Thanks Rob. But I am afraid not. You know, when FB driver is loading(on kernel booting), CMEM is not insmod(after kernel boot up) at all. Regards, Steven On Thu, 2008-06-26 at 16:41 -0500, Tivy, Robert wrote: Are you using CMEM? Typically, CMEM is configured (during 'insmod', usually from the loadmodules.sh script) to use 120MB - 128 MB. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of steven.zhang Sent: Thursday, June 26, 2008 1:33 AM To: davinci Cc: torran; [EMAIL PROTECTED] Subject: davincifb driver works only at reserver memory 120M-126M usingioremap Hi, all. I change davincifb driver DMA buffer allocation from dma_alloc_coherent() into using ioremap() to reserver FB memory. If the reserve memory resides between 120M-126M, it works fine,while larger than 126M, its output is lines instead of linux tux. phys memory of my board is 256M, and pass mem=120M into bootargs. any thoughts? Regards, steven ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Cache Coherency between ARM core and DSP
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 PROTECTED] On Behalf Of Griffis, Brad Sent: Sunday, June 29, 2008 1:55 PM To: amr ali; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cache Coherency between ARM core and DSP Be careful with your cache operations. A WB-inv is not the catch all operation. You can do some damage if you do it in the wrong place. A few hints/tips: * Make sure that only one of the processors is accessing the data at any given time. * Before touching a buffer for the first time the processor should do a block invalidate to make sure it doesn't have any old data corresponding to that address range. * After finishing work with a buffer the processor should do a block writeback (invalidate) to push all the new data out to DDR. FYI, I'm speaking pretty generically with my above comments. I'm not sure what cache operations are already being performed by Codec Engine, DSP Link, Framework Components, etc. Someone else may comment on those specifically. It would be helpful if you share your motivations for doing these cache operations. Are you having cache coherence issues? If you share more about why you're doing it we might be able to make enhancements in Codec Engine to help you out. They might even already exist! Brad From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of amr ali [EMAIL PROTECTED] Sent: Sunday, June 29, 2008 2:53 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Cache Coherency between ARM core and DSP Hi, If I want to perform cache coherency my self on some data I pass from ARM to DSP and vice-versa, what should I do? A suggested scenario is to make the following modifications in ARM code: WB cache invalidate it VISA API WB cache invalidate it again Your suggestions are welcome. Should I do same thing in DSP code? BR, Amr Ali. Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Opening several CE servers
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 PROTECTED] On Behalf Of Asa Sent: Thursday, July 03, 2008 9:33 AM To: dv_mail Subject: Opening several CE servers I was wondering if it is possible to open several different Codec servers from the same thread? Thanks, Asa ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Opening several CE servers
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 what I meant is the following: I have two separate Codec servers (.x64P) files each containing one codec. I would like to test something quickly, so I don't want to spend the time integrating the two codecs into one codec server. I was wondering if there is a way for the application to open both codec servers with Engine_open(), create an instance of each codec using it's own ce handle and then use each codec? Something along the following lines: ceHandle_1 = Engine_open(engineName_1, NULL, NULL); ceHandle_2 = Engine_open(engineName_2, NULL, NULL); codecHandle_1 = xxx_create(ceHandle_1,...); codecHandle_2 = yyy_create(ceHandle_2,...); From what I know that's not possible, but I was wondering if someone might know of a way of doing it. Asa - Original Message - From: Ring, Chrismailto:[EMAIL PROTECTED] To: Asamailto:[EMAIL PROTECTED] ; dv_mailmailto:davinci-linux-open-source@linux.davincidsp.com Sent: Thursday, July 03, 2008 1:30 PM Subject: RE: Opening several CE servers 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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Asa Sent: Thursday, July 03, 2008 9:33 AM To: dv_mail Subject: Opening several CE servers I was wondering if it is possible to open several different Codec servers from the same thread? Thanks, Asa ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM6446 : Gstreamer Problem.
Which version of Codec Engine are you using? The first step is typically to turn on tracing. There are some details here: http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ#What_should_I_do_first.3F ... though the instructions will be different if you're using something older than CE 2.00. If the tracing doesn't reveal an issue in using the Codec Engine/VISA APIs, it's likely in the codec - or more likely in the _usage_ of the codec (like passing invalid parameters, etc). Chris From: Robin Gujjar [mailto:[EMAIL PROTECTED] Sent: Monday, 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 port successfully. I am able to play the MP3 and.aac, but I am not able to play video files, (AVI,ASF). Here is where gst-launch application hangs. We dont know yet why this function returns error. gdecoder: VIDDEC_process() returned failure Can you please give me some pointer for solving this problem. I will be thankful to you . I am using all the script from the TI port without any modification and my Debug msg is like this : --- gdecoder: plugin_init BEGIN.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_base_init BEGIN... gdecoder: gst_gdecoder_base_init END... gdecoder: gst_gdecoder_class_init BEGIN... gdecoder: gst_gdecoder_get_codec_type Begin gdecoder: gst_gdecoder_get_codec_type End gdecoder: gst_gdecoder_class_init END... gdecoder: plugin_init END.. gdecoder: gst_gdecoder_init BEGIN.. gdecoder: gst_gdecoder_reset BEGIN.. gdecoder: gst_gdecoder_reset END.. gdecoder: gst_gdecoder_init END.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_set_property BEGIN...2.. gdecoder: set ARG_CODEC_NAME property gdecoder: Codec set to enum value 2 gdecoder: gst_gdecoder_set_property END... Engine handle set to value 0 gdecoder: gst_gdecoder_sink_getcaps invoked and call gst_caps_copy gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End Sink getcaps invoked Src getcaps invoked Setting pipeline to PAUSED ... gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_change_state BEGIN.. gdecoder: State Changed from NULL_TO_READY gdecoder: gst_gdecoder_change_state END.. Sink Activate invoked pull_range not supported on sinkpad Running In Push Mode gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_change_state BEGIN.. gdecoder: State Changed from READY_TO_PAUSED gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_sink_activate invoked gdecoder: STREAMING IS TRUE gdecoder: gst_gdecoder_change_state END.. Pipeline is PREROLLING ... FINE gdecoder: gst_gdecoder_sink_getcaps invoked and call gst_caps_copy gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End Sink getcaps invoked gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_sink_event BEGIN.. gdecoder: Got newsegment event on sink pad gdecoder: gst_gdecoder_sink_event END.. gdecoder: gst_gdecoder_sink_getcaps invoked and call gst_caps_copy gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: Inside gst_gdecoder_sink_setcaps BEGIN... gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: MPEG4 gdecoder: Inside gst_gdecoder_sink_setcaps END... gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_chain BEGIN.. gdecoder: Pushing 0 to time stamp queue, buffer size= 2 gdecoder: gst_gdecoder_process BEGIN0... gdecoder: gst_gdecoder_decoder_ initialize BEGIN.. gdecoder: gst_gdecoder_open_engine BEGIN.. gdecoder: Opening MPEG4 Engine... gdecoder: gst_gdecoder_open_engine END.. gdecoder: Created MPEG4 decoder gdecoder: gst_gdecoder_decoder_initialize END.. gdecoder: Actual Input Buffer Size is = 414720 gdecoder: Codec engine reported minimum input buffer size = 414720 gdecoder: gst_gdecoder_decode BEGIN.. gdecoder_decode: Streaming ON.. inBufSize = 2, inData = 0x435c9000 gdecoder: inbuf size = 2 , ptr = 0x435c9000 gdecoder: outbuf size = 691200 , ptr = 0x43672000 gdecoder_decode:No time stamp overflow.. inputID = 1112895648 gdecoder: VIDDEC_process() returned failure gdecoder: gst_gdecoder_process END.. gdecoder: gst_gdecoder_chain END.. gdecoder: gst_gdecoder_get_type Begin gdecoder: gst_gdecoder_get_type End gdecoder: gst_gdecoder_chain BEGIN.. gdecoder: Pushing 4000 to time stamp queue, buffer size= 2 gdecoder: gst_gdecoder_chain END.. gdecoder: gst_gdecoder_get_type Begin Thanks and regards Robin Singh
RE: Help:: querry on VISA_delete
[ Looping the mailing list, as this is generally interesting. ] Well... no need to implement your alg's algFree() method, perhaps (though it's recommended). But your extended API's *_delete() fxn still needs to be implemented. Your extension API implementation - *_create()/delete()/process()/control() - should be independent of OS/processor and built for both sides of the RPC. When the alg is remote, the ARM-side _delete() will be called, and will invoke VISA_delete(). In the VISA_delete() implementation, CE will detect that the alg is remote, and do what's needed to invoke your extension API's _delete() on the DSP... which will, exactly as on the ARM, call VISA_delete(). This time, the VISA_delete() implementation will detect that the alg is on the same processor, and will call DSKT2_freeAlg(). This will, as the article describes, _not_ call your alg's algFree(). 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, Thanks for the quick response. So no need to impliment delete function in DSP side. Thank you, Veeru - Original Message - From: Ring, Chrismailto:[EMAIL PROTECTED] To: Veerannamailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2008 10:17 AM Subject: RE: Help:: querry on VISA_delete Good question, this is a DSKT2 feature. I've added this to the Framework Components FAQ: http://tiexpressdsp.com/wiki/index.php?title=Framework_Components_FAQ#Why_doesn.27t_DSKT2_freeAlg.28.29_call_my_alg.27s_algFree.28.29_method.3F Chris From: Veeranna [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2008 8:53 PM To: Ring, Chris Subject: Help:: querry on VISA_delete Hi All, We are using Codec_eingine_2_10 with my DVEVM 6446 board. we have our extension layer( stub skeleton). Everything is working fine in terms of Create, Process and Control call. Once we call delete from Application ie, it goes to stub and we call VISA_Delete. we see that this delete call never comes to the DSP side. We have mapped this call with the function pointer(Free) in our Function table.In Free function we fill up the memtab structure what codec engine supposed to free.So on the codec side ideally the delete call should be able to print the DSP trace but as per our observation the call never comes to free on dsp side. All the other calls like process, control and create ( it will call 2 function alloc and initobj functions mapped in V table) can be seen on the codec side. Can you please tell whats the reason for the same ? We have seen through the memstats that all the memory is getting Free properly after the Delete call.It seems that VISA_Delete does need the free implementation(In Function Table) on codec side to free the algorithm instance and algorithm heap.. When We was working on xdais compliant code that time we checked the function table, free function gets called from ALG_delete function.So please explain why free function doesnt get called through VISA_delete. Thank you, Veeru -- _ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: where does the _TI_ define come from
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 _is_ documented and supported.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Vladimir Pantelic
Sent: Monday, July 28, 2008 12:13 PM
To: davinci
Subject: where does the _TI_ define come from
e.g. in videnc_copy.c:
...
/*
* VIDENCCOPY_TI_IALG
* This structure defines TI's implementation of the IALG interface
* for the VIDENCCOPY_TI module.
*/
#ifdef _TI_
/* satisfy xDAIS symbol requirement without any overhead */
asm(_VIDENCCOPY_TI_IALG .set _VIDENCCOPY_TI_VIDENCCOPY);
#else
/*
* We duplicate the structure here to allow this code to be
compiled and
* run non-DSP platforms at the expense of unnecessary data space
* consumed by the definition below.
*/
IALG_Fxns VIDENCCOPY_TI_IALG = { /* module_vendor_interface */
IALGFXNS
};
...
where does this _TI_ get defined? I see it is defined for a
C64 build but not for GCC, but I want to know where it is set.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Where to start
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: davinci-linux-open-source@linux.davincidsp.com Subject: Where to start Hi all Im trying to understud how XDM, XDAIS and so on work. Or how to start creating aplications. There is lot of documentation. But I do not know where to start. Is there some step by step tutorial? Many thanks Ondrej Pindroch ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Questions about codec engine
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 on another processor (e.g. DM644x, DM6467), you must use LAD: http://wiki.davincidsp.com/index.php?title=Link_Arbiter_Daemon Given all that, on to your questions: 1. Yes, you can - and must(!) - call CERuntime_init() from both processes. 2. Your use case should work; please confirm which version of CE you're using (must be 2.00 as described above) if you want us to report further details about the assert you're seeing. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of minhong Sent: Thursday, July 31, 2008 2:27 AM To: davinci-linux-open-source Subject: Questions about codec engine Hi, all, I've several questions that need your help. 1. If I have two applications said A1(used to encode MPEG4) and A2(used to decode JPEG), I think I'll have CERuntime_init() called in each application. When I execute A2 after A1 is executed and still running, the two applications seem to terminate together. So, what's wrong for this situation ? May I call CERuntime_init() while the other process has called it ? 2. As mentioned in 1. what is the correct way if I want to show JPEG repeatedly while MPEG4 is being encoded. ? I used two threads for different jobs (one for MPEG4 encoding, said video_thread and one for JPEG decoding, said image_thread). When the video_thread is running, I'll do some command to invoke the jpeg_thread for decoding a picture. Eventually, I'll got the message: ERROR: assertion violation: Sem_posix.c, line308 and the application is halt. I'm wondering if I can call any IMGDEC_control/IMGDEC_process API if VIDENC_process is repeatedly called in the video_thread. minhong. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Questions about codec engine
That assert occurs when the underlying Linux semop() call to pend on a multi-process semaphore returns -1 (or failure). In CE 2.00, we added multi-process support using Linux's System V semaphores which don't have a very nice cleanup policy if one of the processes owning/using the semaphore crashes. If it's reproducible, can you run your app with the env var CE_DEBUG set to 3 and send the [big] log file to this list? Also, upon failure, can you run ipcs -s on a console and send the results? This will report any shared semaphores that are in the system (perhaps leaked by a process 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 CE 2.00. If there're further details for the assert, it'll be appreciate. I tried this and it never showed the assert: In both video_thread and image_thread, I assume that the VISA APIs need a critical region such that I did a mutex_lock before calling VISA APIs and mutex_unlock after that. Do I have to do this critical region protection ? minhong. - Original Message - From: Ring, Chrismailto:[EMAIL PROTECTED] To: minhongmailto:[EMAIL PROTECTED] ; davinci-linux-open-sourcemailto:davinci-linux-open-source@linux.davincidsp.com Sent: Thursday, July 31, 2008 9:06 PM Subject: RE: Questions about codec engine 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 on another processor (e.g. DM644x, DM6467), you must use LAD: http://wiki.davincidsp.com/index.php?title=Link_Arbiter_Daemon Given all that, on to your questions: 1. Yes, you can - and must(!) - call CERuntime_init() from both processes. 2. Your use case should work; please confirm which version of CE you're using (must be 2.00 as described above) if you want us to report further details about the assert you're seeing. Chris ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Building decodeCombo.x64p
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 PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of shyamal mehta Sent: Monday, September 15, 2008 2:00 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Building decodeCombo.x64p Hi, I am trying to build decodeCombo.x64p from my Linux machine. My configuration is as following: DVSDK: 1_30_00_40 XDC : 3_00_02 CGTool : 6_00_15 BIOS : 5_31_08 CE : 2_00_01 F/w Comp : 2_00_01 xDAIS: 6_00_01 I get following error : =start= lnk64P decodeCombo.x64P ... warning: cannot retain specified section order within '.daisalg'; need to reorder contents due to need for trampolines; any specified '.' expressions or symbol assignments within the specification of '.daisalg' will be compromised or ignored undefinedfirst referenced symbol in file - _Comm_init package/cfg/decodeCombo_x64P.o64P error: relocation overflow occurred at address 0x0044 in section '.text' of input file 'package/cfg/decodeCombo_x64P.o64P'. The 29-bit PC-relative displacement 471211392 at this location is too large to fit into the 21-bit PC-Relative field; the destination address is too far away from the instruction. You may need to add a mask to the assembly instruction or use other target specific assembly features if you really only need the lowest 21 bits of this symbol. Please see the section on Relocation in the Assembly User's Guide. _Comm_put /home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/t i/sdo/ce/bioslog/lib/bioslog.a64P _Comm_create /home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/t i/sdo/ce/bioslog/lib/bioslog.a64P _Comm_get /home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/t i/sdo/ce/bioslog/lib/bioslog.a64P _Comm_getSrcQueue /home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/t i/sdo/ce/bioslog/lib/bioslog.a64P error: relocation overflow occurred at address 0x0944 in section '.text' of input file 'LogServer.o64P (/home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/ ti/sdo/ce/bioslog/lib/bioslog.a64P)'. The 29-bit PC-relative displacement 471260336 at this location is too large to fit into the 21-bit PC-Relative field; the destination address is too far away from the instruction. You may need to add a mask to the assembly instruction or use other target specific assembly features if you really only need the lowest 21 bits of this symbol. Please see the section on Relocation in the Assembly User's Guide. error: relocation overflow occurred at address 0x0958 in section '.text' of input file 'LogServer.o64P (/home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/ ti/sdo/ce/bioslog/lib/bioslog.a64P)'. The 29-bit PC-relative displacement 471260336 at this location is too large to fit into the 21-bit PC-Relative field; the destination address is too far away from the instruction. You may need to add a mask to the assembly instruction or use other target specific assembly features if you really only need the lowest 21 bits of this symbol. Please see the section on Relocation in the Assembly User's Guide. error: relocation overflow occurred at address 0x0a24 in section '.text' of input file 'LogServer.o64P (/home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/ ti/sdo/ce/bioslog/lib/bioslog.a64P)'. The 29-bit PC-relative displacement 471260280 at this location is too large to fit into the 21-bit PC-Relative field; the destination address is too far away from the instruction. You may need to add a mask to the assembly instruction or use other target specific assembly features if you really only need the lowest 21 bits of this symbol. Please see the section on Relocation in the Assembly User's Guide. error: relocation overflow occurred at address 0x0ab8 in section '.text' of input file 'LogServer.o64P (/home/shyamal/dvsdk_1_30_00_40/codec_engine_2_00_01/packages/ ti/sdo/ce/bioslog/lib/bioslog.a64P)'. The 29-bit PC-relative displacement 471260248 at this location is too large to fit into the 21-bit PC-Relative field; the destination address is too far away from the instruction. You may need to add a mask to the assembly instruction or use other target specific assembly features if you really only need the lowest 21 bits of this symbol. Please see the section on Relocation in the Assembly User's
RE: Query for BSP of TMS320DM6437
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; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Query for BSP of TMS320DM6437 Hi, There is no Linux BSP for the DM6437 as it has no ARM core (unlike the DM355/6446/6467) - it is a DSP (TMS320C64x) only device. AFAIK Linux does not run on DPSs. Regards Phil Q Phil Quiney, Senior Software Engineer Trinity Convergence Cambridge Business Park Cowley Road Cambridge CB4 0WZ, UK T: +44(0)1223-435536 F: +44(0)1223-435560 www.trinityconvergence.comhttp://www.trinityconvergence.com/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhishek Bajpai Sent: 01 October 2008 11:55 To: davinci-linux-open-source@linux.davincidsp.com Subject: Query for BSP of TMS320DM6437 Dear Friends, I am new to embedded linux and just started developement on TMS320DM6437 EVM. do you have any idea of available BSP on this board or can help me to run linux on this media controller. Thanks in advance Regards Abhishek Bajpai -- Even The word Impossible says I M Possible ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Query for BSP of TMS320DM6437
Dig in a little with VirtualLogix - might have to contact them directly, I don't know if they monitor this list. My understanding is that their Linux port to DM6437 didn't _require_ BIOS and was capable of just running Linux. (Not an official TI statement, just a recollection) Chris 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 core which implements both linux and DSP/Bios. I am looking for a solution by which I can put the linux kernel on the core itself. do you know about any group working on it. thanks in advance Regards Abhishek Bajpai 2008/10/1 Ring, Chris [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] FYI: http://www.virtuallogix.com/products/vlx-embedded/vlx-for-digital-multimedia.html Chris From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Phil Quiney Sent: Wednesday, October 01, 2008 5:43 PM To: Abhishek Bajpai; davinci-linux-open-source@linux.davincidsp.commailto:davinci-linux-open-source@linux.davincidsp.com Subject: RE: Query for BSP of TMS320DM6437 Hi, There is no Linux BSP for the DM6437 as it has no ARM core (unlike the DM355/6446/6467) - it is a DSP (TMS320C64x) only device. AFAIK Linux does not run on DPSs. Regards Phil Q Phil Quiney, Senior Software Engineer Trinity Convergence Cambridge Business Park Cowley Road Cambridge CB4 0WZ, UK T: +44(0)1223-435536 F: +44(0)1223-435560 www.trinityconvergence.comhttp://www.trinityconvergence.com/ From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Abhishek Bajpai Sent: 01 October 2008 11:55 To: davinci-linux-open-source@linux.davincidsp.commailto:davinci-linux-open-source@linux.davincidsp.com Subject: Query for BSP of TMS320DM6437 Dear Friends, I am new to embedded linux and just started developement on TMS320DM6437 EVM. do you have any idea of available BSP on this board or can help me to run linux on this media controller. Thanks in advance Regards Abhishek Bajpai -- Even The word Impossible says I M Possible -- Even The word Impossible says I M Possible ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: error finding codec
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 background for the curious. There's some glossary here to help (interesting glossary words are highlighted in black): http://rtsc.eclipse.org/docs-tip/Glossary Every package has a name (defined in it's 'package.xdc' file), and the directory structure it's in must reflect that name. It can't arbitrarily be copied under the ce examples. The codec package is search for along the XDCPATH. Your statement below (highlighted in red) is not correct. The XDC tools don't recursively search deep into all directories on the XDCPATH, rather they just look for packages sitting in the directories named on the XDCPATH. So, if your codec is in a package named ti.sdo.codecs.h264enc, it should be located in a directory ti/sdo/codecs/h264enc (e.g. you would find a file named 'ti/sdo/codecs/h264enc/package.xdc'). The directory which holds the 'ti' directory in this case, would be a repository, and would need to be located on the XDCPATH. While not necessarily recommended, if the Codec Engine examples are already on your XDCPATH (e.g., if your XDCPATH already includes dvsdk_1_40_00_28/codec_engine_2_10_01/examples), you could drop the codec package - with its fully qualified ti/sdo/codecs/h264enc/... name - into this examples/ repository. And finally, if you're a codec vendor, or need to XDC package a codec library yourself, I'd recommend using the Codec Packaging Wizard: http://wiki.davincidsp.com/index.php?title=RTSC_Codec_And_Server_Package_Wizards It handles a lot of these naming details, as well as more complex issues like indicating stack usage and exported symbol name management for you. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Burbea Sent: Monday, October 06, 2008 1:34 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: error finding codec Hi everybody Some introduction: I work using the standard dvsdk directory tree structure, and I work with dvsdk 1.40.00.28http://1.40.00.28 I added the h264 encoder from TI under tto the dvsdk_1_40_00_28/codec_engine_2_10_01/examples/ti/sdo/ce/examples/codecs directory, compiled it and everything seems OK. Now, I go and build the dvsdk_1_40_00_28/codec_engine_2_10_01/examples/ti/sdo/ce/examples/server directory, and I get this message js: /home/albertb/erezk_tests/dvsdk_1_40_00_28/xdc_3_00_06/packages/xdc/xdc.tci, line 275: exception from uncaught JavaScript throw: Error: xdc.loadPackage: can't find package 'ti.sdo.ce.examples.codecs.h264enc' along the path '/home/albertb/erezk_tests/dvsdk_1_40_00_28/codec_engine_2_10_01/examples/ti/sdo/ce/examples/servers/all_codecs/../../../../../..;/home/albertb/erezk_tests/dvsdk_1_40_00_28/codec_engine_2_10_01/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/xdais_6_10_01/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/dsplink-davinci-v1.50-prebuilt/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/cmem_2_10/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/framework_components_2_10_01/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/biosutils_1_01_00/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/bios_5_32_01/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/xdc_3_00_06/packages;/home/albertb/erezk_tests/dvsdk_1_40_00_28/codec_engine_2_10_01/examples/ti/sdo/ce/examples/servers/all_codecs/./../../../../../..;'; try redefining the package path (XDCPATH). I understand that XDC can not find the codec, but why? As far as I understand, it should scan all the subdirectories of all the directory list in XDCPATH until it finds the required codec. If this is correct, the h264enc is (deep) under the dvsdk_1_40_00_28/codec_engine_2_10_01/examples directory, that is pointed by the '/home/albertb/erezk_tests/dvsdk_1_40_00_28/codec_engine_2_10_01/examples/ti/sdo/ce/examples/servers/all_codecs/../../../../../.. directoy in the XDC path What am I doing wrong? -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: codec engine failed to create algorithm
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.
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mat Laibowitz
Sent: Monday, October 13, 2008 8:08 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: codec engine failed to create algorithm
Well, I figured out the problem about five minutes after sending this email. I
guess it is always helpful to formulate a question from the problem.
The issue is on the wiki:
The JPEG Encode v1.10 (sprc441) must be patched as follows because of a defect
in the codec package. In the file
dm6446_jpegenc_combo_1_10\packages-evaluation\ti\sdo\codecs\jpegenc\ce\JPEGENC.xdc
disable the line referencing idma3Fxns with the string DMJPGE_TIGEM_IDMA3.
Not sure exactly what this means, but if the defect has to do with DMA, then it
is understandable why it did not work and could not setup the codec's memory.
I removed this line and it works fine.
Thanks,
-mat
On Mon, Oct 13, 2008 at 10:19 PM, Mat Laibowitz [EMAIL
PROTECTED]mailto:[EMAIL PROTECTED] wrote:
Hi again.
I have been able to get several apps running using codecs with codec engines.
I am now trying to get the jpeg encoder evaluation codec from TI for the DM6446
working and having some problems.
It compiles and runs, but exits with
JPEG Encoder algorithm creation failed
which is a result of this call:
encHandle = IMGENC_create( pJpegencState-ce, jpegenc, encParams );
if(encHandle == Null)
{
printf(JPEG Encoder algorithm creation failed\n);
exit(1);
}
The CE debug trace is below. Does anyone know quickly why this could be
happening? It seems like it cannot communicate with the codec being served.
The rest of my codec engine based apps seem to run correctly. This could also
be something in the way I am compiling this codec.
Thanks,
-mat
@3,069,067us: [+0 T:0x4001c940 S:0xbedb4ad4] ti.sdo.ce.image.IMGENC -
IMGENC_create Enter (engine=0x2e880, name='jpegenc', params=0xbedb4bfc)
@3,069,272us: [+0 T:0x4001c940 S:0xbedb4aa4] CV - VISA_create(0x2e880,
'jpegenc', 0xbedb4bfc, 0x828, 'ti.sdo.ce.image.IIMGENC')
@3,069,444us: [+0 T:0x4001c940 S:0xbedb49d4] CV - VISA_create2(0x2e880,
'jpegenc', 0xbedb4bfc, 0x18, 0x828, 'ti.sdo.ce.image.IIMGENC')
@3,069,647us: [+0 T:0x4001c940 S:0xbedb497c] CE - Engine_createNode(0x2e880,
'jpegenc', 828, 0xbedb4bfc, 0x18, 0xbedb4ad0)
@3,069,870us: [+0 T:0x4001c940 S:0xbedb4954] OC - Comm_create
Enter(queueName='gppfromnode', queue=0x2eb50, attrs=0x0)
@3,070,367us: [+0 T:0x4001c940 S:0xbedb4954] OC - Comm_create return (0x2eb70)
@3,070,586us: [+0 T:0x4001c940 S:0xbedb495c] OC - Comm_put Enter(queue=0x0,
msg=0x4148bc80)
@3,070,802us: [+0 T:0x4001c940 S:0xbedb495c] OC - Comm_put return (0)
@3,070,968us: [+0 T:0x4001c940 S:0xbedb4954] OC - Comm_get
Enter(queue=0x1, msg=0xbedb49d4, timeout=-1)
@3,072,372us: [+0 T:0x4001c940 S:0xbedb4954] OC - Comm_get return (0)
@3,072,588us: [+0 T:0x4001c940 S:0xbedb4964] OC - Comm_delete Enter
(comm=0x2eb70)
@3,073,187us: [+0 T:0x4001c940 S:0xbedb4974] OC - Comm_delete return
@3,073,398us: [+6 T:0x4001c940 S:0xbedb497c] CE - Engine_createNode Remote
node creation FAILED (0x80008008).
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM355: MPEG4 + MJPEG together
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 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Sommerfeld Sent: Monday, October 20, 2008 8:12 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: DM355: MPEG4 + MJPEG together Hi, Has anyone had problems running MPEG4 alongside MJPEG on the DM355? ie. encode the same frame in the same application with MPEG4 followed by MJPEG? For me, the MJPEG IMGENC1_process call hangs. More generally, what is the best way to debug things like this? I use CE_DEBUG=1 but it doesn't give me enough info. I find debugging memory allocation problems with the DM355 especially difficult to debug as it will not always tell me that it has run out of memory. If it doesn't I might get a SIGSEGV or no feedback at all. This really slows down debugging. I'd love to know how much/many pools I have remaining free at a given point. Any help is greatly appreciated. Thanks, Peter ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Codec Engine Code Overlays with more than one codec?
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 forum
on the eclipse.org site, which would be a great place to post this question:
http://www.eclipse.org/newsportal/thread.php?group=eclipse.dsdp.rtsc
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Itay Chamiel
Sent: Wednesday, October 22, 2008 7:36 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Codec Engine Code Overlays with more than one codec?
Hi,
I've just read the following article:
http://wiki.davincidsp.com/index.php?title=CodecEngineCodeOverlays
Basically it explains how to link a codec such that some of its code gets
loaded into slow external memory, but the linker allocates room in fast memory
and fools the rest of the program to think that the code is actually located in
the fast memory section. The codec is responsible for copying the code from
external to internal memory at the correct time, to prevent the wrong code from
being called.
Unfortunately, the article seems to skip mentioning the reason for actually
doing this exercise, rather than simply link the code directly into fast memory
in the first place: the ability to have *several* such pieces of code, all
located at the same address, each being swapped in at the appropriate time.
The article also doesn't explain how to do this, and here is where I'm stuck:
I have two different codec packages supplied by a third-party developer. Both
codecs support overlays, and are capable of performing the memory copy as
described above. They both have an option which I may set in the XDC config
file, alg_name.alg.overlays = true.
The problem is that when enabling overlays for both codecs, both codecs attempt
to allocate their run addresses in the small section named L1PSRAM, and the
linker fails because there is not enough room in L1PSRAM for both code
sections, and - here's the important bit - there is nothing to tell the linker
that the two run addresses should be overlaid.
The only way to tell the linker to overlay two code sections into the same
memory location is using the UNION keyword. Unfortunately, the linker command
file auto-generated by XDC is divided into parts (each starting with a comment
Content from package name). Each of these parts contain its own SECTIONS {
.. } group, containing the code and data allocations relevant to that package.
Obviously a UNION { .. } group cannot span two such parts.
The only solution I have found so far is to manually modify the auto-generated
linker command file, moving the two data sections into a single UNION with a
shared run address. Once I did that, the project linked, and ran correctly
(both codecs simultaneously) with a measurable performance increase.
Unfortunately, this is no good as a permanent fix because the command file gets
overwritten at each full build.
Since the article I linked to above has no explanation of this, and the codec
authors themselves do not currently know how to solve this problem short of
repackaging the two codecs as a single package, I'd like to know if the
community has answers to this question.
Thanks,
-itay
--
Itay Chamiel
Software Engineer
Mango DSP
itayc at mangodsp.com
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Codec Engine Code Overlays with more than one codec?
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 tool; xs xdc.tools.configuro -linkTemplate ... (see http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/tools/configuro/package.html) or, 2. If you are using the xdc build engine, the optional attribute linkTemplate passed to addExecutable (see http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/bld/Executable.html#.Attrs). Platforms usually reference the template contained in the target's package and in the case of TI targets the template is ti/targets/linkcmd.xdt. So, while not the best answer, it is possible to copy the current template ($(XDC_INSTALL_DIR)/packages/ti/targets/linkcmd.xdt) to some other location, modify it to insert the appropriate UNION statements, and use one of the methods above to override the default ti/targets/linkcmd.xdt template. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Itay Chamiel Sent: Thursday, October 23, 2008 5:46 AM To: Vladimir Pantelic Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: Codec Engine Code Overlays with more than one codec? Vladimir Pantelic wrote: what about removing the overlay related stuff from the codecs link.xdt and adding them UNIONised in the servers link.cmd file? Well, that would work, but it would be rather ugly. As far as I have seen with XDC so far, third-party packages are basically a closed unit which the integrator is not supposed to modify. So, I don't like this because (A) I need to touch files that conceptually should not be touched by me, (B) the codec package becomes unusable as a self contained unit - any project using it must manually add the relevant lines to the link.cmd file, (C) I need to do this manual process every time the third party releases a new version of the codec, and (D) I need to do an extra manual process every time I add or remove a codec from my project. I understand that this is might be the only way to accomplish this, but I'm surprised at TI for going to such great lengths to make everything self-contained, nice and automatic (see the wiki page I linked to in my original post to see the effort done to make the job trivial for the integrator) but leaving this whole issue kind of half-baked. -itay -- Itay Chamiel Software Engineer Mango DSP itayc at mangodsp.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: still trying to access CE from two applications
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: davinci-linux-open-source@linux.davincidsp.com Subject: still trying to access CE from two applications Sorry to ask this question again, but I still don't have this working. Is it even possible to have two applications on the same DM6446 device access codec engine servers? I have tried having two applications access different codecs in the same server combo and only the first one to open it works. I have also tried having two separate server combos, one for each application with completely different codecs in each one, and it still did not work. In both cases the second application to try to do a algorithm create fails and cannot create the algorithm. I feel like this is a pretty basic requirement and should work. I particularly think having two servers should work. Perhaps I need to change the memory settings in the server.cfg or tcf so they don't overlap and can work together. Any help would be greatly appreciated. Thanks, -mat ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: still trying to access CE from two applications
You must start LAD daemon before using any apps that use it (e.g. Codec Engine or native Link apps), so your when I run the first app without first starting LAD, it fails experience is expected. Intermittent failures, however, are not. The next step may be to enable trace - which is a little tricky with multiple processes. Typically, LAD users will enable just the ARM-side trace from each of the ARM-side apps, and utilize a server trace app that pulls all the DSP trace off the DSP in a single place. If this approach isn't used, app A will get some of app B's DSP-side trace mixed in, and vice versa. There's an example app provided with CE - see examples/apps/server_trace - to start a trace-collecting app that collects the DSP-side tracing (and as a result disables DSP-side trace collection from the other apps). Then, rather than using the CE_DEBUG env var to enable trace (which also [incorrectly in this use case] enables DSP-side trace collection), you can use the CE_TRACE env var to just enable the ARM-side trace - from each of your 2 processes. Might look something like this: 1. Start LAD daemon (with 2 arguments, arg1 == log file name, arg2 == verbose for extra chatter). 2. Start server_trace app (to collect DSP-side trace) 3. Run app1 and app2 with CE_TRACE env var set to *=01234567 to set all trace masks (*) to all 8 levels of trace enabled (01234567) on the ARM side and no trace on the DSP side. That may help point out where things are going awry. And finally, I just updated the LAD article with some known limitations from an internal design doc - don't know if you're bumping into any, but thought it was worth mentioning. http://wiki.davincidsp.com/index.php?title=Link_Arbiter_Daemon Feel free to update that wiki article 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 applications So I have been trying to get the LAD to work. Is there any more information on it besides the wiki page? Basically, I have reconfigured my apps to use it and recompiled the LAD with my library paths. Then when I run the first app without first starting LAD, it fails. If I run it after starting LAD it runs. So it looks like it is somewhat setup. However, the first app does not run every time. It is intermittent. Sometimes I start it and it can't open the codec engine and quits, other times it runs without fail. When I have it running, I can then start the second app and, similarly, it runs some of the time, but mostly can't open the codec engine and quits. Very strange behavior. Maybe there are some configuration options that I am missing. Or something about how to setup the server packages. Thanks, -mat On Sun, Oct 26, 2008 at 5:26 PM, Mat Laibowitz [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: OH! This looks like it is exactly what I am looking for. I will try it out. Not sure how I missed this, just got going with the latest codec engine as well, so it should work fine. Thanks so much. -mat On Sun, Oct 26, 2008 at 4:31 PM, Ring, Chris [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: 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] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Mat Laibowitz Sent: Sunday, October 26, 2008 1:19 PM To: davinci-linux-open-source@linux.davincidsp.commailto:davinci-linux-open-source@linux.davincidsp.com Subject: still trying to access CE from two applications Sorry to ask this question again, but I still don't have this working. Is it even possible to have two applications on the same DM6446 device access codec engine servers? I have tried having two applications access different codecs in the same server combo and only the first one to open it works. I have also tried having two separate server combos, one for each application with completely different codecs in each one, and it still did not work. In both cases the second application to try to do a algorithm create fails and cannot create the algorithm. I feel like this is a pretty basic requirement and should work. I particularly think having two servers should work. Perhaps I need to change the memory settings in the server.cfg or tcf so they don't overlap and can work together. Any help would be greatly appreciated. Thanks, -mat ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Setting up C Code to connect to JPEG Codec
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 to your compile line (this binds the data types in xdc/std.h to concrete data types defined by your toolchain). [ You'll also need to add the _generated_ linker.cmd libraries to your link line. ] Please ask if you have followup questions. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Neerav Patel Sent: Monday, December 08, 2008 9:39 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Setting up C Code to connect to JPEG Codec Hi, I am a beginner with the DM355 EVM Board, and I am trying to get the jpeg codec working in C Code. SPRUE67 says to include 3 header files, which are #include xdc/std.h #include ti/sdo/ce/Engine.h #include ti/sdo/ce/CERuntime.h But when I add these headers and nothing else I get a large amount of errors. What am I doing wrong? Thanks in advance! Error List: /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:101: error: parse error before IArg /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:101: warning: type defaults to `int' in declaration of `IArg' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:101: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:102: error: parse error before UArg /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:102: warning: type defaults to `int' in declaration of `UArg' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:102: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:104: error: parse error before Int8 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:104: warning: type defaults to `int' in declaration of `Int8' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:104: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:105: error: parse error before Int16 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:105: warning: type defaults to `int' in declaration of `Int16' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:105: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:106: error: parse error before Int32 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:106: warning: type defaults to `int' in declaration of `Int32' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:106: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:111: error: parse error before UInt8 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:111: warning: type defaults to `int' in declaration of `UInt8' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:111: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:112: error: parse error before UInt16 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:112: warning: type defaults to `int' in declaration of `UInt16' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:112: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:113: error: parse error before UInt32 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:113: warning: type defaults to `int' in declaration of `UInt32' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:113: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:126: error: parse error before Uint8 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:126: warning: type defaults to `int' in declaration of `Uint8' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:126: warning: data definition has no type or storage class /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:127: error: parse error before Uint16 /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages /xdc/std.h:127: warning: type defaults to `int' in declaration of `Uint16' /localhome/administrator/dvsdk_1_30_00_40/xdc_3_00_02/packages
RE: undefined reference to 'IMGENC1_create' error
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 ti.sdo.codecs.jpegenc.dm355.ce.JPEGENC Module
should declare (in it's JPEGENC.xdc Module spec file) that it implements the
ti.sdo.ce.image1.IIMGENC1 interface. That will cause the support for that
interface (namely the library with those IMGENC1_* APIs) to be added to the
generated linker.cmd file when the config step sees a codec that needs that
support has been integrated.
When you run your config step, does the generated linker.cmd file include a
library from the ti/sdo/ce/image1 package? Maybe you either 1) forgot to run
the config step after changing your .cfg script or 2) aren't passing the newly
generated linker.cmd into your linker?
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Tivy, Robert
Sent: Monday, December 15, 2008 5:42 PM
To: Neerav Patel; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: undefined reference to 'IMGENC1_create' error
Either the application .cfg file or some included package would need to do:
xdc.useModule('ti.sdo.ce.image1.IIMGENC1');
to bring in the library containing IMGENC1_create().
I'm not familiar with the details of the ti.sdo.codecs.jpegenc.dm355.ce.JPEGENC
module so I can't check that out, but perhaps you need to manually invoke the
above statement in your cfg.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Neerav Patel
Sent: Monday, December 15, 2008 12:44 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: undefined reference to 'IMGENC1_create' error
Hi,
I am getting an error of undefined reference to 'IMGENC1_create' I have added
the appropriate header file #include ti/sdo/ce/image1/imgenc1.h to the code,
I suspect that something in the cfg file may be not correct to make it not link
to the proper libraries?
This is my cfg file I am using! Thank in advance
/*
* Copyright (c) Texas Instruments Incorporated 2007
*
* Use of this software is controlled by the terms and conditions found in the
* license agreement under which this software has been supplied or provided.
*
*/
var osalGlobal = xdc.useModule( 'ti.sdo.ce.osal.Global' );
osalGlobal.runtimeEnv = osalGlobal.LINUX;
//var MPEG4ENC = xdc.useModule('ti.sdo.codecs.mpeg4enc.dm355.ce.MPEG4ENC');
//var MPEG4DEC = xdc.useModule('ti.sdo.codecs.mpeg4dec.dm355.ce.MPEG4DEC');
var JPEGENC = xdc.useModule('ti.sdo.codecs.jpegenc.dm355.ce.JPEGENC');
/*
* Engine Configuration
*/
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var demoEngine = Engine.create(securitycamera, [
//{name: mpeg4enc, mod: MPEG4ENC, local: true, groupId: 1},
//{name: mpeg4dec, mod: MPEG4DEC, local: true, groupId: 1},
{name: jpegenc, mod: JPEGENC, local: true, groupId: 1},
]);
/*
* DMAN3 Configuration
*/
var DMAN3 = xdc.useModule('ti.sdo.fc.dman3.DMAN3');
/* give DMAN3 all TCCs except those hard-coded by The JPEG MPEG Enc Decs */
/*
* For the 32-63 range, configure tccAllocationMaskH to exclude used channels
* JPEG Dec: {33-47, 52-57}
* JPEG Enc: {34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49}
* MPEG Dec: {32-63}
* MPEG Enc: {12, 13, 34, 35, 40,41,42,43,44,45,46,47,48,49,50,52,53,
* 54,55,56,57,63}
*/
DMAN3.tccAllocationMaskH = 0x0; /* everthing 32-63 hardcoded and unavailable */
/* Give DMAN3 all lower TCCs except what's taken by Linux kernel and a Codec:
* Based on the info from montavista: {2, 3, 8, 9, 26, 27, 30, 31}
* and MPEG Enc taking up:{12, 13}
*/
DMAN3.tccAllocationMaskL = 0x33ffccf3;
/* Following assignments will give DMAN3 control of PaRAMs above 78: */
DMAN3.paRamBaseIndex = 64;
DMAN3.numPaRamEntries = 48;
DMAN3.nullPaRamIndex = 127;
/* Configure Scratch Group's DMAN3 resources */
DMAN3.numTccGroup[1] = 0;
DMAN3.numPaRamGroup[1] = 32;
DMAN3.qdmaChannels = [0, 1, 2, 3, 4, 5, 6, 7];
DMAN3.maxQdmaChannels = 8;
DMAN3.numQdmaChannels = 8;
DMAN3.maxTCs = 2;
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Can Engine_open() open 2 different Engine?
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 Behalf Of zhenfeng ren Sent: Wednesday, January 14, 2009 4:54 AM To: Davinci-linux-open-source@linux.davincidsp.com Subject: Can Engine_open() open 2 different Engine? Hi, If I have a file : h264 video and mp3 audio, can 2 different Engines run in DSP? -- Thanks, Zhenfeng Ren ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Error build codec servers in DM6446: incompatible use of taget
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: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jon Arróspide Sent: Wednesday, February 11, 2009 7:28 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Error build codec servers in DM6446: incompatible use of taget Hello all, I'm trying to build a codec server in DM6446. However, even if I try to build an example server (video_copy) I'm getting the following error: js: /opt/dvevm_1_10/xdctools_1_21/packages/xdc/cfg/cfg.js, line 143: exception from uncaught _javascript_ throw: Error: incompatible use of the target 'ti.targets.C64P', imported version [], ti.targets.rts6000 was built using version [1,0,5.2,0,4], ti.sdo.ce.trace was built using version [1,0,6.0,3], ti.sdo.ce.osal.alg was built using version [1,0,6.0,3], ti.bios.utils was built using version [1,0,6.0,3], ti.bios was built using version [1,0,6.0,3], ti.rtdx was built using version [1,0,6.0,3], ti.sdo.ce.osal was built using version [1,0,6.0,3], ti.sdo.fc.dskt2 was built using version [1,0,6.0,3], ti.sdo.fc.dman3 was built using version [1,0,6.0,3], ti.sdo.fc.acpy3 was built using version [1,0,6.0,3], ti.sdo.ce.bioslog was built using version [1,0,6.0,3], ti.sdo.ce.node was built using version [1,0,6.0,3], ti.sdo.ce was built using version [1,0,6.0,3], ti.sdo.ce.video was built using version [1,0,6.0,3], codecs.viddec_copy was built using version [1,0,6.0,3], codecs.videnc_copy was built using version [1,0,6.0,3] gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Error 1 gmake: *** Deleting file `package/cfg/video_copy_x64Pcfg_c.c' gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file `package/cfg/video_copy_x64Pcfg.cmd' gmake: *** [package/cfg/video_copy_x64Pcfg_c.c] Deleting file `package/cfg/video_copy_x64Pcfg.s62' make: *** [all] Error 2 Has anybody encountered this problem? Do I need to download some upgraded (or downgraded) version of a library/file? Thank you in advance, Jon ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: using extended params for MPEG4 encoding
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 _remote_ codecs, like
DM644x/OMAP3), these structs are copied (based on the .size field) out of the
user-provided struct into a DSP Link-based MSGQ and sent to the remote
processor - all in the context of the VISA_create() call.
From the sources (and you can see this call stack via CE_DEBUG trace as
well), this happens in
VIDENC1_create()-VISA_create()-VISA_create2()-Engine_createNode2() - here's
the code with the memcpy(), where the user-supplied params ptr is named
nodeAttrs and the .size field is in nodeAttrsSize:
Engine_createNode2(...)
{
...
if (nodeAttrs == NULL) {
msg-cmdBuf.data.createNodeIn.argLength = 0;
}
else {
assert(nodeAttrsSize = (sizeof (RMS_Word) * RMS_MAXARGSLENGTH));
msg-cmdBuf.data.createNodeIn.argLength = nodeAttrsSize;
memcpy(msg-cmdBuf.data.createNodeIn.argBuffer, nodeAttrs,
nodeAttrsSize);
}
...
}
You can see that the data is _copied_ into the MSGQ before it's sent to the
remote DSP.
One final notable - the algorithm/codec should also make a copy of these
params(!) for its internal use, if it needs to them later. It's true that,
after the codec is created/initialized, the MSGQ-based memory holding these
params will be re-used. If the _codec_ is [incorrectly] just keeping a
reference to these params - rather than [correctly] making a copy of them - I
can see that the reference would go out of scope and the codec would get in
trouble.
Chris
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of eric Debief
Sent: Thursday, February 26, 2009 8:35 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: using extended params for MPEG4 encoding
Hi,
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.
Hope this help.
Sorry if I 've missed the target, but i'm very very loaded this times.
Eric.
Le Thursday 26 February 2009 15:47:22 Stephen Berry, vous avez écrit :
Vladimir Pantelic wrote:
Stephen Berry wrote:
Vladimir Pantelic wrote:
Stephen Berry wrote:
the routine follows. The call to VIDENC1_control is
the routine that
segfaults. I'm not using the ividEncfxns-algControl call...
#if 1
ext_params.videncParams.size = sizeof(IMP4VENC_Params);
hEncode = (VIDENC1_Handle) ALG_create(1, (IALG_Fxns *)
MP4VENC_TI_IMP4VENC,
(IALG_Handle) NULL,
(IALG_Params *)
ext_params);
can you tell me why you use ALG_create and not VIDENC1_create()?
because that is what the example did in the sdk. Is
there another way?
yes, but your own code has VIDENC1_create() just below in
the #else
section,
so I was wondering why you did not use it. Actually, I
have no idea
what ALG_create actually does,
all I ever used where the VIDEENC_xyz functions.
Also, all the CE exmaple I saw so did not use ALG_create etc..
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.
The code that Ti supplies in the demo uses VIDENC1_create, and that
works just fine - its only when I use the ALG_create that
things go bad...
There are several examples in the SDK that use the
ALG_create method,
but they are so different from what I do now that it will take some
effort to figure out what I need to change... and I need to get this
unit out to a customer.
Steve
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: using extended params for MPEG4 encoding
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 first .size field is correctly set, the VISA APIs (e.g. VIDENC1_create()) _do_ support extended create param structs. This is described a little bit here, though the focus is on extending process() and control(): http://wiki.davincidsp.com/index.php?title=Extending_data_structures_in_xDM Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Stephen Berry Sent: Thursday, February 26, 2009 6:47 AM Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: using extended params for MPEG4 encoding Vladimir Pantelic wrote: Stephen Berry wrote: Vladimir Pantelic wrote: Stephen Berry wrote: the routine follows. The call to VIDENC1_control is the routine that segfaults. I'm not using the ividEncfxns-algControl call... #if 1 ext_params.videncParams.size = sizeof(IMP4VENC_Params); hEncode = (VIDENC1_Handle) ALG_create(1, (IALG_Fxns *) MP4VENC_TI_IMP4VENC, (IALG_Handle) NULL, (IALG_Params *) ext_params); can you tell me why you use ALG_create and not VIDENC1_create()? because that is what the example did in the sdk. Is there another way? yes, but your own code has VIDENC1_create() just below in the #else section, so I was wondering why you did not use it. Actually, I have no idea what ALG_create actually does, all I ever used where the VIDEENC_xyz functions. Also, all the CE exmaple I saw so did not use ALG_create etc.. 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. The code that Ti supplies in the demo uses VIDENC1_create, and that works just fine - its only when I use the ALG_create that things go bad... There are several examples in the SDK that use the ALG_create method, but they are so different from what I do now that it will take some effort to figure out what I need to change... and I need to get this unit out to a customer. Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: using extended params for MPEG4 encoding
Thanks for this feedback. I'll see what we can do with the docs. We do document that the structs are extensible to some degree, but obviously it's not clear enough. For example: https://www-a.ti.com/downloads/sds_support/targetcontent/CE/ce_1_20/codec_engine_1_20/docs/html/struct_i_v_i_d_e_n_c1___params.html ... includes the following description of the IVIDENC1_Params data type: This structure may be extended by individual codec implementations allowing customization with vendor specific parameters. The presence of vendor specific extensions will be detected by the value 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... 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 first .size field is correctly set, the VISA APIs (e.g. VIDENC1_create()) _do_ support extended create param structs. This is described a little bit here, though the focus is on extending process() and control(): http://wiki.davincidsp.com/index.php?title=Extending_data_structures_in_xDM Chris Silly me - I was reading the header files for the VIDENC1_create proto - it never mentioned you could pass it any other structure type. Anyway - I passed it the extended params and remarkably it didn't blow up! Now I have more knobs to tweek. Thanks! Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CE ( or DSPLINK? ) Remote Node Creation Error 0x80008018
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 arguments in the skeletons. In short, the version of Codec Engine built into the DSP-side doesn't match the version built into the ARM-side. During startup, when CE_DEBUG=2 is set, the versions of components in the system should be displayed, so you should be able to compare which versions were used on each side. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Yusuf Caglar AKYUZ Sent: Saturday, March 07, 2009 2:12 PM To: davinci-linux-open-sou...@linux. Subject: CE ( or DSPLINK? ) Remote Node Creation Error 0x80008018 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying DVSDK 2.0 combos with dm6446 but I'm getting error message: ...Engine_createNode Remote node creation FAILED (0x80008018). When I try CE_DEBUG=2, I do not see any other error/warning messages before this line. Both my (own)servers and dvsdk servers throw this error. I've built my own CMEM(2.21) and DSPLINK(1.6). To track down the issue, I run dsplink and codec engine samples/examples and they are running fine in my setup. However, I still suspect there is something wrong with my kernel modules. Any help would be invaluable given that I've run out of ideas here. Thanks in advance, Caglar -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkmy8UsACgkQ/nL+S5dojeha2ACdHw6uieWtqIZsAqqPDr74GPV/ 7noAnjftJ1iWuEbPTqd5s6GwUC8KHDfM =1o5E -END PGP SIGNATURE- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: LAD usage
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 and App2 at the same time, you'll need to build a single server that can accommodate both. Then configure both apps to 1) use LAD, and 2) use the same server config. Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sriraja Yagneswaran Sent: Monday, March 23, 2009 4:20 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: LAD usage Hello, I have a couple of CE-based applications/processes that I wish to run in parallel. Both have different DSP server engines. App1: App1.x64P App2: App2.x64P I follow the procedure listed on the wiki page and add the necessary lines to the CE configuration script of both applications and get the individual applications and servers. I then start the LAD as a separate process as: ./lad.x470MV log.txt Now I start to run my applications, the first application that I start runs ok, but the second one fails citing CEapp- ERROR: can't open engine. Using CE_DEBUG=2, I find that the LAD_startupDsp() gives out an error code of 3. Please advice. I have CE 2.10.02 and DSPLINK 1.50 Regards Sriraja http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Suspend MPEG and do JPEG and vice versa on the fly
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.
It may be that the first codec consumes a scarce resource (like the MJCP) and
therefore, when creating the second codec that wants it, that resource is not
available.
To get a better look at what's going on, you could set CE_DEBUG=2 during your
second codec create, and you should get more details about what failed.
http://tiexpressdsp.com/index.php?title=CE_DEBUG
To see if it's _really_ a resource issue, you may have to configure RMAN.trace
= true; in your app's .cfg script. Something like this:
RMAN = xdc.useModule('ti.sdo.fc.rman.RMAN');
RMAN.trace = true;
RMAN is the Resource Manager for many of the codec resources. By enabling
the RMAN trace, and especially running at CE_DEBUG=2 or =3, you can get further
insight into what resources each codec is asking for, and whether it's
persistent (non-shareable) or scratch (shareable, but with a context
save/restore overhead).
Chris
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of Deepak Shankar-TLS,Chennai.
Sent: Friday, March 27, 2009 5:56 AM
To: Vladimir Pantelic; davinci-linux-open-source@linux.davincidsp.com
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Suspend MPEG and do JPEG and vice versa on the fly
Hi,
Thanks a lot for the inputs.
I think the codecs are running in the same server - for if I
dynamically
kill the MPEG application and do a JPEG its working very
well. Just that
I'm trying to do it in parallel. However is it possible to
program where
the codec should run- by server I was thinking the MJCP can
work only as
a single server(DSP server??) in the DM355 for the ARM. Or is there a
mechanism I could run 2 servers on the same DSP... Please provide you
inputs.
Is there any other option in the DM355 to make it work in parallel.
Further Could you please suggest me a point to dig in the
DVSDK/(documentation or code) if its ever possible to make
the JPEG and
MPEG run in parallel or is it a HW limitation?
Thank you
Cheers,
Deepak Shankar V
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of Vladimir Pantelic
Sent: Friday, March 27, 2009 12:36 PM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Suspend MPEG and do JPEG and vice versa on the fly
Deepak Shankar-TLS,Chennai. wrote:
Hello all,
I'm using the dm355-DVSDK, Montavista Linux and trying the demos -
encode and JPEG. All those are working very well when run
as separate
processes.
However, Now I'm trying to build a custom application which
can do a
MPEG or JPEG based on some external events.
Something like when the GPIO is high dump an MPEG file.
When it is low
capture a jpeg image every 1 second.
The problem is I'm not able to use both the JPEG and the
MPEG codecs
simultaneously. When the MPEG compression is in progress, a call to
the 'IMGENC1_create(ce, encoderName, encParams)' is
failing. Is this
a inherent nature of MJCP. Should I have to deinit the MPEG
resources
when I want to do a JPEG, or is there a better way to do that.
are the two codecs in the same server? if not, it cannot
work. you will
have to unload one to load the other I think. Even if they
are in the
same server, there could be system resources that cannot be
shared, so a
gain they would not work in parallel.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DISCLAIMER:
--
-
The contents of this e-mail and any attachment(s) are
confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or
its affiliates. Any views or opinions presented in
this email are solely those of the author and may not
necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of
this message without the prior written consent of the author
of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the
sender immediately. Before opening any mail and
attachments please check them for viruses
RE: Codec compilation error
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 library for the ARM-side of the DM644x device - is this really an ARM-side codec? (Probably not) If the codec is really a DSP-side codec, you may want to see some of the questions in this FAQ: http://tiexpressdsp.com/index.php?title=Codec_Engine_FAQ#Why_does_the_ARM_application_require_.22DSP.22_codec_packages.3F You may need to hack up the codec's package.xs getLibs() fxn as described in the FAQ to _not_ provide a library for the ARM side (assuming it's a DSP-side codec). To resolve the root cause of this, you may need to contact the codec producer (of the codecs.decode_slice package). It's hard to tell who that is by the [poor] package name - we recommend that the codec vendor name be included in the package name so that 1) it's clear who to contact(!) and 2) it's globally unique so we avoid name collisions. Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Mohamed AbdElwahed Sent: Monday, April 13, 2009 8:47 AM To: Davinci Mailing list Subject: Codec compilation error hi all, i was using old compilation tools v1.2 and when i moved to v2.0 i can not compile with the following error -- --- making package.mak (because of package.bld) ... generating interfaces for package ceapp (because package/package.xdc.inc is older than package.xdc) ... configuring ceapp.x470MV from package/cfg/ceapp_x470MV.cfg ... Info: Configuring engine named 'decode_slice_server' from the info file for DSP server './decode_slice_server.x64P', located in package 'servers.decode_slice_server.evmDM6446': Target app will look for the DSP server image 'decode_slice_server.x64P' in its current directory. Adding codec 'decode_slice' (codecs.decode_slice.DECODE_SLICE), scratch groupId=0 Info: Reading DSP memory map from the info file for DSP server './decode_slice_server.x64P', located in package 'servers.decode_slice_server.evmDM6446': will link with ti.sdo.ce.utils.trace:lib/release/TraceUtil.av5T will link with ti.sdo.ce.bioslog:lib/release/bioslog.av5T will link with codecs.decode_slice:lib/decode_slice.a470MV js: /opt/xdc_3_00_02/packages/xdc/cfg/Main.xs, line 28: XDC runtime error: can't find the library 'lib/decode_slice.a470MV' specified by package codecs.decode_slice. It wasn't found along the path '/ESDU/Wasiem/filesys/ffmpeg-porting/esdu_decode_slice;/opt/dvsdk_1_30_01_41/codec_engine_2_00_01/packages;/opt/dvsdk_1_30_01_41/xdais_6_00_01/packages;/opt/dvsdk_1_30_01_41/dsplink-1_60-prebuilt/packages;/opt/framework_components_2_22_01/fctools/packages;/opt/dvsdk_1_30_01_41/framework_components_2_00_01/packages;/opt/dvsdk_1_30_01_41/biosutils_1_00_02/packages;/opt/bios_5_31_08/packages;/opt/xdc_3_00_02/packages;/opt/xdc_3_00_02/packages;..;'. gmake: *** [package/cfg/ceapp_x470MV.c] Error 1 gmake: *** Deleting file `package/cfg/ceapp_x470MV.c' gmake: *** [package/cfg/ceapp_x470MV.c] Deleting file `package/cfg/ceapp_x470MV.xdl' gmake: *** [package/cfg/ceapp_x470MV.c] Deleting file `package/cfg/ceapp_x470MV.h' js: /opt/xdc_3_00_02/packages/xdc/tools/Cmdr.xs, line 40: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted. make[3]: *** [ceapp] Error 1 --- i found this lib decode_slice.a470MV generated in another place other than mentioned paths and i copied this lib to the above searched paths but it also fail and i do not thing this is right way to fix above error any help is highly appreciated --- --- Mohamed AbdElwahed Ibrahim [http://graphics.hotmail.com/i.p.emthup.gif] See all the ways you can stay connected to friends and familyhttp://www.microsoft.com/windows/windowslive/default.aspx ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
It may not have been clear, there's sort of a 2 phase resource management: 1. At build/config time where the resources are statically partitioned - some for ARM, some for DSP - and given to their respective CPU-specific resource managers. I think originally we simply cut the DMA resources in half and gave half to each CPU. 2. At run time where SW on each CPU (e.g. drivers/codecs) asks the CPU-specific resource manager for resources from their CPU-specific partition. There's no current support for the DSP resource manager stealing resources from Linux or vice-versa. The initial partitioning takes place once up front (in unfortunately 2 different you-can-easily-introduce-collisions ways). I guess my comment was just cautioning us against stuff like this... Reserve channels 0,1,12,13 and slots 78-109 for dsp use on dm644x. ... because it's going to change from user to user and we'll never get it right all the time. I think we just need to make sure it's easy enough to change the config (on both sides!) and over-document it. Chris -Original Message- From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, April 17, 2009 3:17 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, Chris wrote: It's a bit too much info, but please review the Overview section here: http://tiexpressdsp.com/index.php?title=Dma_overview It attempts to describe challenges in hard-coding DMA resources on systems with multiple cores that must cooperate. Fortunately the DMA resource managers are typically flexible - so long as the users of the resources behave (e.g. codecs ask for resources from FC resource managers rather than hard-code channels). I agree with Kevin, no one should be hard-coding resources, Linux-side/BIOS-side or otherwise, unless perhaps it's a completely closed system. Finally, a detail, DSP Link doesn't manage DSP-side DMA resources - Framework Components and the EDMA3LLD (LLD == Low-Level Driver) do. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Kevin Hilman Sent: Friday, April 17, 2009 5:02 AM To: Troy Kisky Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage Troy Kisky troy.ki...@boundarydevices.com writes: Reserve channels 0,1,12,13 and slots 78-109 for dsp use on dm644x. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com I've only verified that channels 0, and 78-101 need reserved, but reserving a little extra seems like a good idea. I'm not crazy about this hard-coded reservation. The DSP code has a kernel-side driver (dsplinkk.) That driver should be doing the channel reservations. Kevin Very interesting Chris. So, the plan is for the dsp to ask for resources as needed? Or to request all upfront? Thanks Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Why does this patch get your mpeg4 codec to work - b/c the codec has a hard-coded channel 0 it needs (so your patch keeps channel 0 out of Linux's partition)? If so, IMHO, that change doesn't belong in the mainline tree - that's a customer-specific integration issue. FWIW, the architecturally 'right' thing to do would be for the codec to get this resource via DSP-side DMAN3 or RMAN rather than hard-code it. Is TI looking into this? Is TI looking into what - dynamically repartitioning DMA resources across CPUs at runtime? I don't think so, though I'm personally not at all against 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, Chris wrote: It may not have been clear, there's sort of a 2 phase resource management: 1. At build/config time where the resources are statically partitioned - some for ARM, some for DSP - and given to their respective CPU-specific resource managers. I think originally we simply cut the DMA resources in half and gave half to each CPU. This is what will need changed eventually. The sooner the better. My patch at least gets the our mpeg4 codec running again. But I agree will Kevin that this is not a long term solution. Is TI looking into this? 2. At run time where SW on each CPU (e.g. drivers/codecs) asks the CPU-specific resource manager for resources from their CPU-specific partition. There's no current support for the DSP resource manager stealing resources from Linux or vice-versa. The initial partitioning takes place once up front (in unfortunately 2 different you-can-easily-introduce-collisions ways). I guess my comment was just cautioning us against stuff like this... Thanks for the info Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: RE: Problem about DSP server config of DM6446
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 the DSP.
Finally, note that you could also run out of other resources - e.g. DMA, HW
accelerators, etc. So it's not just out of memory that can cause a codec
create to fail.
Chris
From: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On
Behalf Of chensu.main
Sent: Tuesday, April 28, 2009 1:42 AM
To: Tivy, Robert
Cc: davinci-linux-open-source
Subject: Re: RE: Problem about DSP server config of DM6446
Hi , Robert
I wonder is it a limitation of RMS(Resource Manager Server) or DSP/BIOS ? I
will modify my code now.
Thanks a lot.
2009-04-28
chensu.main
发件人： Tivy, Robert
发送时间： 2009-04-28 06:38:15
收件人： chensu.main; davinci-linux-open-source
抄送：
主题： RE: Problem about DSP server config of DM6446
I'm not sure about a document, but the number of algorithm objects that you can
create depends on the size of the memory block from which the stacks are
allocated. As you've seen, cutting the stack size down allows you to create
more. You might be able to find a formula, but the real answer is as many as
you have memory for.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
chensu.main
Sent: Monday, April 27, 2009 8:03 AM
To: davinci-linux-open-source
Subject: Problem about DSP server config of DM6446
Hi all ,
In my application , I have to create one algorithm many times .
Fistly I config DSP server's CFG file and set stack size to 16384 in
Server.algs {} , but app can only create 7 instances of my algorithm . Then I
fix stack to 4096 and I can create more .
My question is How many algorithm objects can I create . Which document
describe it indetail ?
2009-04-27
chensu.main
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Remote node creation FAILED
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 inlined with the ARM-side API calls.
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
avincidsp.com] On Behalf Of bhushan
Sent: Thursday, April 30, 2009 8:23 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Remote node creation FAILED
Hi all,
I am developing an application based on the scale example in the
codec_engine_1_10_01 package. The changes made are essentially adding
elements to the ISCALE_Params struct in the codecs/iscale.h file.
When I run the application it gives remote node creation failure. The
logs obtained are as follows:
Calling SCALE main()
TraceUtil Warning: Failed to open local log file
trace/cearmlog.txt, using stdout
TraceUtil Warning: Failed to open dsp CE log file
trace/cedsp0log.txt, using stdout
TraceUtil Warning: Failed to open dsp/bios log file
trace/bioslog.dat, disabling log
@0x00046a28:[T:0x4000] ZZ - main Welcome to app's main().
App- Application started.
@0x00046c68:[T:0x4000] OM - Memory_contigAlloc
Enter(size=1024, align=-1)
@0x00046e53:[T:0x4000] OM - Memory_contigAlloc CMEM_alloc(1024) =
0x40018000.
@0x00046f58:[T:0x4000] OM - Memory_contigAlloc
CMEM_getPhys(0x40018000) = 0x84133000.
@0x0004701c:[T:0x4000] OM - Memory__addContigBuf
Enter(virtAddr=0x40018000, size=1024, physAddr=0x84133000)
@0x000470e4:[T:0x4000] OM - Memory__addContigBuf creating new
contigBuf object
@0x000471ac:[T:0x4000] OM - Memory__addContigBuf returning:
cb-phys=0x84133000, cb-size=1024, cb-virt=0x40018000
@0x00047285:[T:0x4000] OM - Memory_contigAlloc return
(0x40018000)
@0x00047328:[T:0x4000] OM - Memory_contigAlloc
Enter(size=1024, align=-1)
@0x00047445:[T:0x4000] OM - Memory_contigAlloc CMEM_alloc(1024) =
0x4001b000.
@0x00047523:[T:0x4000] OM - Memory_contigAlloc
CMEM_getPhys(0x4001b000) = 0x8413.
@0x000475e2:[T:0x4000] OM - Memory__addContigBuf
Enter(virtAddr=0x4001b000, size=1024, physAddr=0x8413)
@0x000476b0:[T:0x4000] OM - Memory__addContigBuf creating new
contigBuf object
@0x00047785:[T:0x4000] OM - Memory__addContigBuf returning:
cb-phys=0x8413, cb-size=1024, cb-virt=0x4001b000
@0x00047864:[T:0x4000] OM - Memory_contigAlloc return
(0x4001b000)
After memory allocation
After opening files
@0x0004834b:[T:0x4002] OP - daemon thread created.
@0x00048483:[T:0x4000] CE - Engine_open('scale', 0x0, 0xbefffaec)
@0x0004856c:[T:0x4000] CE - rserverOpen('./all.x64P'), count = 0
@0x00048634:[T:0x4000] OP - Process_create
Enter(imageName='./all.x64P', attrs=0xbefffaf0)
@0x00048fc9:[T:0x4002] OP - Process_create_d Enter(proc=0x49640)
@0x000490c0:[T:0x4002] OP - Process_create_d
Initializing DSP PROC...
@0x000495d2:[T:0x4002] OP - Process_create_d Attaching
to DSP PROC...
@0x0004ad60:[T:0x4002] OP - Process_create_d Opening MSGQ pool...
@0x0004afcf:[T:0x4002] OP - Process_create_d Loading ./all.x64P
on DSP (2 args)...
@0x0005bc65:[T:0x4002] OP - Process_create_d Starting DSP PROC...
@0x0005c21a:[T:0x4002] OP - Process_create_d Opening
remote transport...
@0x0005c3fc:[T:0x4002] OP - Process_create_d return (1)
@0x0005c5c3:[T:0x4000] OP - Process_create return (0x49640)
@0x0005c69a:[T:0x4000] CE - rserverOpen('./all.x64P'):
0x42234 done.
@0x0005c758:[T:0x4000] OC - Comm_create Enter(queueName='scale',
queue=0x49620, attrs=0x0)
@0x0005c921:[T:0x4000] OC - Comm_create return (0x49678)
@0x0005ca27:[T:0x4000] OC - Comm_alloc Enter(poolId=0x0,
msg=0x4962c, size=576)
@0x0005cb1d:[T:0x4000] OC - Comm_alloc msg=0x4032a900,
returning (0)
@0x0005cbd7:[T:0x4000] OC - Comm_locate Enter(queueName='rmsq',
queue=0x4961c)
@0x0005e614:[T:0x4000] OC - Comm_locate return (0)
@0x0005e6f9:[T:0x4000] CE - checkServer(0x49610)
@0x0005e7bd:[T:0x4000] OC - Comm_put Enter(queue=0x0,
msg=0x4032a900)
@0x0005e8a9:[T:0x4000] OC - Comm_put return (0)
@0x0005e99a:[T:0x4000] OC - Comm_get Enter(queue=0x1,
msg=0xbefffae8, timeout=-1)
@0x0005ea82:[T:0x4000] OC - Comm_get return (0)
After opening engine
@0x0005ebb2:[T:0x4000] extensions.scale.SCALE - SCALE_create
Enter (server=0x49610, name='scale', params=0xbefffb48)
@0x0005ecba:[T:0x4000] CV - VISA_create(0x49610, 'scale',
0xbefffb48, 0x804, 'extensions.scale.ISCALE')
@0x0005eda9:[T:0x4000] CE - Engine_createNode(0x49610, 'scale',
804, 0xbefffb48)
@0x0005ee78:[T:0x4000] OC - Comm_create
Enter(queueName='gppfromnode', queue=0x49700, attrs=0x0)
RE: Codec engine hangs when during TraceUtil_start function
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 [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of bhushan Sent: Monday, May 04, 2009 11:17 PM To: Balagopalakrishnan, Anand Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Codec engine hangs when during TraceUtil_start function Hello Anand, I set the CE_DEBUG parametr to 2 and 3 value which must basically enable all the traces from teh ARM and DSP side. Still I am unable to see the DSP side traces. Bhushan On Tue, May 5, 2009 at 11:02 AM, Balagopalakrishnan, Anand ana...@ti.com wrote: What are the attributes configured for TraceUtil in the XDC cfg file? By default, the CE traces will be redirected to /tmp/cearmlog.txt. It looks like you have set the environment variables CE_TRACEFILE so it gets redirected to trace/cearmlog.txt. If the directory trace doesn't exist, there would be errors. If you don't *need* TraceUtil specifically - if you just want to observe the DSP side traces for debugging, a better (and easier) option would be to use CE_DEBUG: http://tiexpressdsp.com/index.php?title=CE_DEBUG When using CE_DEBUG, the traces will automatically come to the console. There is no need to change the ARM application code. Best Regards, Anand Balagopalakrishnan Texas Instruments India -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of bhushan Sent: Monday, May 04, 2009 5:07 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Codec engine hangs when during TraceUtil_start function Hi, I am developing an application based on the codec_engine. For the same I want to see the DSP side traces for the various codecs used. So I have added TraceUtil_start(EngineName) function after Engine_open api. But the application hangs because of TraceUtil_start. Following are the logs: # ./vs_appd -f ../test_vectors/ws_uyvy.yuv # TraceUtil Warning: Failed to open local log file trace/cearmlog.txt, using stdout TraceUtil Warning: Failed to open dsp CE log file trace/cedsp0log.txt, using stdout TraceUtil Warning: Failed to open dsp/bios log file trace/bioslog.dat, disabling log @0x0002c12e:[T:0x4002] OP - daemon thread created. @0x000447be:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40556000) @0x000448ee:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40556000, size=1) @0x000449e4:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x00044aad:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280) @0x0004ae67:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40655000) @0x0004af56:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40655000, size=1) @0x0004b01c:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0004b0db:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000) @0x000514b1:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40754000) @0x0005159c:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40754000, size=1) @0x00051662:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0005173e:[T:0x8003] OM - Memory_getPhysicalAddress return (0x829fe000) 7792:junk2009 NT:No passwd file available, taking factory passwd REQCFG REQCFG 7792:junk2009 NT:No passwd file available, taking factory passwd SETCFG SETCFG Rszcopy Debug: Configuring resizer job to copy image of resolution 320x240 @0x00595d34:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x408ed000) @0x00595e64:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x408ed000, size=1) @0x00595f56:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x00596023:[T:0x8003] OM - Memory_getPhysicalAddress return (0x8280) @0x0059c413:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x409ec000) @0x0059c4fd:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x409ec000, size=1) @0x0059c5bd:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x0059c677:[T:0x8003] OM - Memory_getPhysicalAddress return (0x828ff000) @0x005a2a2a:[T:0x8003] OM - Memory_getPhysicalAddress Enter(virtAddr=0x40aeb000) @0x005a2b14:[T:0x8003] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40aeb000, size=1) @0x005a2bd7:[T:0x8003] OM - Memory__getPhysicalAddress returning physAddr=0x0 @0x005a2caa:[T:0x8003] OM - Memory_getPhysicalAddress return (0x829fe000)
RE: difficulty in VDEC2 interface in dm6467
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 Engine.createFromServer() to create the Engine in your app's .cfg script? Another common mistake, if the _name_ is a match, is that the _type_ of the codec doesn't match. E.g., if your codec doesn't correctly identify itself as a IVIDDEC2 type (via it's CODEC.xdc file), attempts to VIDDEC2_create() it will fail. Chris From: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On Behalf Of JayaKumar, PremKumar Sent: Monday, May 04, 2009 11:06 PM To: kirthika varadarajan; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: difficulty in VDEC2 interface in dm6467 Unable to locate alg error might be due to a mismatch between the names defined in multiple places. Check out consistency of the alg names used: 1. Algorithm module name (+package path) matches with the algorithm module path mentioned in useModules( ) in the server's cfg file. 2. Algorithm name defined under the Server.algs in the server's cfg file matches with the name defined in the server creation call in the app's cfg file. Regards, Prem Texas Instruments India From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of kirthika varadarajan Sent: Monday, May 04, 2009 6:39 PM To: Davinci-linux-open-source@linux.davincidsp.com Subject: difficulty in VDEC2 interface in dm6467 I used VDEC2 interface for our own decoder. But somehow i am not able to open the VDEC2 interface But the decode demo that comes along with TI works with VDEC2 interface, here with i am sending the debug message which i get when i use the vdec2 interface. Suggest me what is the problem with VDEC2 interface with our decoder implementation Decode demo started. @0,734,311us: [+4 T:0x40018528] OG - Global_init This program was built with the following packages: @0,734,667us: [+4 T:0x40018528] OG - package gnu.targets.rts470MV (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/gnu/targets/rts470MV/) [1,0,0,0,1203621000516] @0,734,823us: [+4 T:0x40018528] OG - package ti.xdais.dmhttp://ti.xdais.dm (/home/Vina/dvsdk_1_40_00_28/xdais_6_10_01/packages/ti/xdais/dm/) [1,0,4,1210262746529] @0,734,902us: [+4 T:0x40018528] OG - package ti.xdais (/home/Vina/dvsdk_1_40_00_28/xdais_6_10_01/packages/ti/xdais/) [1,2,1,1210262742149] @0,734,971us: [+4 T:0x40018528] OG - package ti.sdo.utils.trace (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/utils/trace/) [1,0,0,1210378728605] @0,735,041us: [+4 T:0x40018528] OG - package ti.sdo.ce.utils.xdm (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1210912978675] @0,735,167us: [+4 T:0x40018528] OG - package ti.sdo.fc.dman3 (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/fc/dman3/) [1,0,3,1210378548029] @0,735,238us: [+4 T:0x40018528] OG - package ti.sdo.fc.acpy3 (/home/Vina/dvsdk_1_40_00_28/framework_components_2_10_01/packages/ti/sdo/fc/acpy3/) [1,0,2,1210378523580] @0,735,308us: [+4 T:0x40018528] OG - package dsplink.gpp (/home/Vina/dvsdk_1_40_00_28/dsplink-davinci-v1.50-prebuilt/packages/dsplink/gpp/) [3,0,0] @0,735,520us: [+4 T:0x40018528] OG - package ti.sdo.linuxutils.cmem (/home/Vina/dvsdk_1_40_00_28/cmem_2_10/packages/ti/sdo/linuxutils/cmem/) [2,0,1,1204929560755] @0,735,598us: [+4 T:0x40018528] OG - package ti.catalog.c470 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/catalog/c470/) [1,0,1,0,1203561761475] @0,735,670us: [+4 T:0x40018528] OG - package ti.catalog.c6000 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/catalog/c6000/) [1,0,0,0,1203561781695] @0,735,738us: [+4 T:0x40018528] OG - package ti.platforms.evmDM6467 (/home/Vina/dvsdk_1_40_00_28/xdc_3_00_06/packages/ti/platforms/evmDM6467/) [1,0,0,0,1203562062227] @0,735,806us: [+4 T:0x40018528] OG - package ti.sdo.ce.osal (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/osal/) [2,0,2,1210912758604] @0,735,874us: [+4 T:0x40018528] OG - package ti.sdo.ce.ipc (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/ipc/) [2,0,1,1210912707081] @0,735,940us: [+4 T:0x40018528] OG - package ti.sdo.ce.osal.linux (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/osal/linux/) [2,0,1,1210912772730] @0,736,008us: [+4 T:0x40018528] OG - package ti.sdo.ce.ipc.dsplink (/home/Vina/dvsdk_1_40_00_28/codec_engine_2_10_01/packages/ti/sdo/ce/ipc/dsplink/) [2,0,1,1210912721394] @0,736,077us: [+4 T:0x40018528] OG
RE: Remote node creation failure(0x80008008)
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: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On Behalf Of gunnasanthosh kumar Sent: Monday, May 11, 2009 3:19 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Remote node creation failure(0x80008008) Hello, I am getting an error message Remote node creation failure(0x80008008) during algorithm create time for h264 decoder unit server on DVTB. What could be the likely reason for this error ? How to fix it? Thanks, Santhosh ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Re: Can JPEG and MPEG4 run on DM355 simultaneity
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 codecs don't
run at the same time.
As this is DM365-based, the codecs are 'local'. Refer to the
Engine.algs[].groupId section here:
http://tiexpressdsp.com/index.php?title=Codec_Engine_GroupIds
Chris
From: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On
Behalf Of zuowenping
Sent: Wednesday, May 13, 2009 7:28 PM
To: Liu Yebo; davinci-linux-open-sou...@linux.; Vladimir Pantelic
Cc: davinci-linux-open-source
Subject: Re: Re: Can JPEG and MPEG4 run on DM355 simultaneity
you can use the same codec engine! I am rum them simultaneity,they are ok!
2009-05-14
zuowenping
发件人： Liu Yebo
发送时间： 2009-05-14 10:15:11
收件人： davinci-linux-open-source@linux.davincidsp.com; Vladimir Pantelic
抄送： davinci-linux-open-source
主题： Re: Can JPEG and MPEG4 run on DM355 simultaneity
Hi,
I have made jpeg code in demos, and It seams that JPEG and MPEG4 encoder on
our board works fine at the same time.
Following is my JPEG code , you can add them into encode demos.
/* jpeg.h*/
#include xdc/std.h
#include ti/sdo/ce/Engine.h
#include ti/sdo/ce/image1/imgenc1.h
#include rendezvous.h
#include fifoutil.h
#include pause.h
#include encode.h
#ifndef __JPEG_H__
#define __JPEG_H__
int jpegEncodeAlgCreate(Engine_Handle hEngine, IMGENC1_Handle *hEncodePtr,
int width, int height, int num, XDAS_Int32
*imageBufSize);
void jpegencode(IMGENC1_Handle enc, unsigned char *inBuf, unsigned int
inBufSize,
unsigned char *encodedBuf, unsigned int * encodedBufSize);
typedef struct ImageEnv {
Rendezvous_Handle hRendezvousInit;
Rendezvous_Handle hRendezvousCleanup;
Pause_Handle hPause;
FifoUtil_Obj inFifo;
FifoUtil_Obj outFifo;
int imageWidth;
int imageHeight;
int chcnt;
} ImageEnv;
void * imageThrFxn(void *arg);
#endif /* __JPEG_H__ */
/*jpeg.c*/
/* Standard Linux headers */
#include stdio.h
#include fcntl.h
#include errno.h
#include stdlib.h
#include string.h
#include unistd.h
#include pthread.h
#include sys/mman.h
#include sys/ioctl.h
#include asm/types.h
/* Codec Engine headers */
#include xdc/std.h
#include ti/sdo/ce/Engine.h
#include ti/sdo/ce/osal/Memory.h
#include encode.h
#include jpeg.h
#include capture.h
#include recorder.h
static char *jpegenc_name[MAXCHNUM] = {jpegenc, jpegenc:1, jpegenc:2,
jpegenc:3};
int jpegEncodeAlgCreate(Engine_Handle hEngine, IMGENC1_Handle *hEncodePtr,
int width, int height, int num, XDAS_Int32
*imageBufSize)
{
IMGENC1_Params image_encParams;
IMGENC1_DynamicParams image_dynParams;
IMGENC1_Status image_imgStatus;
IMGENC1_Handle hEncode;
#define SCANS 4
#define QVALUE 73
image_encParams.size = sizeof(IMGENC1_Params);
image_encParams.maxWidth = width;
image_encParams.maxHeight = height;
image_encParams.maxScans = SCANS;
image_encParams.dataEndianness = XDM_DEFAULT;
image_encParams.forceChromaFormat = XDM_YUV_422ILE;
hEncode = IMGENC1_create(hEngine, jpegenc_name[num], image_encParams);
if (NULL == hEncode)
{
fprintf(stderr, error: can't open codec jpegenc\n);
seterrdev(ERR_IMGENCCREAT);
return FAILURE;
}
/* set the parameters for encoding */
image_dynParams.size = sizeof(IMGENC1_DynamicParams);
image_dynParams.numAU = XDM_DEFAULT;
image_dynParams.inputChromaFormat = XDM_YUV_422ILE;
image_dynParams.inputWidth = width;
image_dynParams.inputHeight = height;
image_dynParams.captureWidth = 0;
image_dynParams.generateHeader = XDM_ENCODE_AU;
image_dynParams.qValue = QVALUE;
image_imgStatus.size = sizeof(image_imgStatus);
if (IMGENC1_control(hEncode, XDM_SETPARAMS, image_dynParams,
image_imgStatus) ==
XDM_EFAIL) {
fprintf(stderr, error: could not set PARAMS: 0x%x\n, XDM_SETPARAMS);
seterrdev(ERR_IMGENCCREAT);
return FAILURE;
}
/* ask the codec for buffer sizes - these are typically conservative */
if (IMGENC1_control(hEncode, XDM_GETBUFINFO, image_dynParams,
image_imgStatus) ==
XDM_EFAIL) {
fprintf(stderr, error: could not get BUFINFO: 0x%x\n, XDM_GETBUFINFO);
seterrdev(ERR_IMGENCCREAT);
return FAILURE;
}
*imageBufSize = image_imgStatus.bufInfo.minOutBufSize[0];
*hEncodePtr = hEncode;
return SUCCESS;
}
void jpegencode(IMGENC1_Handle enc, unsigned char *inBuf, unsigned int
inBufSize,
unsigned char *encodedBuf, unsigned
RE: [PATCH 3/3] davinci: add SRAM allocator
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 manage (via its insmod params) and the codecs indirectly allocate from CMEM. If you're unfamiliar with CMEM, there is an overview here: http://tiexpressdsp.com/index.php?title=CMEM_Overview I'm not the expert, I only want to encourage further discussion! But I'm a little concerned about a resource collision if this SRAM allocator gets pushed, and more than one client thinks they own that resource. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Kevin Hilman Sent: Thursday, May 21, 2009 2:47 PM To: linux-arm-ker...@lists.arm.linux.org.uk Cc: davinci-linux-open-source@linux.davincidsp.com; David Brownell Subject: [PATCH 3/3] davinci: add SRAM allocator From: David Brownell dbrown...@users.sourceforge.net Provide a generic SRAM allocator using genalloc, and vaguely modeled after what AVR32 uses. This builds on top of the static CPU mapping set up in the previous patch, and returns DMA mappings as requested (if possible). Compared to its OMAP cousin, there's no current support for (currently non-existent) DaVinci power management code running in SRAM; and this has ways to deallocate, instead of being allocate-only. The initial user of this should probably be the audio code, because EDMA from DDR is subject to various dropouts on at least DM355 and DM6446 chips. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/Kconfig |1 + arch/arm/mach-davinci/Makefile|2 +- arch/arm/mach-davinci/include/mach/sram.h | 27 ++ arch/arm/mach-davinci/sram.c | 74 + 4 files changed, 103 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-davinci/include/mach/sram.h create mode 100644 arch/arm/mach-davinci/sram.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e60ec54..ffa8427 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -586,6 +586,7 @@ config ARCH_DAVINCI select ZONE_DMA select HAVE_IDE select COMMON_CLKDEV + select GENERIC_ALLOCATOR help Support for TI's DaVinci platform. diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index 5b62d8a..059ab78 100644 --- a/arch/arm/mach-davinci/Makefile +++ b/arch/arm/mach-davinci/Makefile @@ -5,7 +5,7 @@ # Common objects obj-y:= time.o clock.o serial.o io.o psc.o \ -gpio.o devices.o dma.o usb.o common.o +gpio.o devices.o dma.o usb.o common.o sram.o obj-$(CONFIG_DAVINCI_MUX)+= mux.o diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h new file mode 100644 index 000..111f7cc --- /dev/null +++ b/arch/arm/mach-davinci/include/mach/sram.h @@ -0,0 +1,27 @@ +/* + * mach/sram.h - DaVinci simple SRAM allocator + * + * Copyright (C) 2009 David Brownell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __MACH_SRAM_H +#define __MACH_SRAM_H + +/* ARBITRARY: SRAM allocations are multiples of this 2^N size */ +#define SRAM_GRANULARITY 512 + +/* + * SRAM allocations return a CPU virtual address, or NULL on error. + * If a DMA address is requested and the SRAM supports DMA, its + * mapped address is also returned. + * + * Errors include SRAM memory not being available, and requesting + * DMA mapped SRAM on systems which don't allow that. + */ +extern void *sram_alloc(size_t len, dma_addr_t *dma); +extern void sram_free(void *addr, size_t len); + +#endif /* __MACH_SRAM_H */ diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c new file mode 100644 index 000..0309e72 --- /dev/null +++ b/arch/arm/mach-davinci/sram.c @@ -0,0 +1,74 @@ +/* + * mach-davinci/sram.c - DaVinci simple SRAM allocator + * + * Copyright (C) 2009 David Brownell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ +#include linux/module.h +#include linux/kernel.h +#include linux/init.h +#include linux/genalloc.h + +#include mach/common.h +#include mach/memory.h +#include
RE: [PATCH 3/3] davinci: add SRAM allocator
-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. If no one else is using it, the codecs should feel free to. The system integrator should be able to decide who should have it rather than hard-coding codecs/audio drivers/etc to require it. If it's not available, the codecs will get the memory from somewhere else and simply(?) suffer a performance cost. But some systems may decide using this memory to improve codec performance is more important than giving it to someone else. And vice-versa. Chris___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: add SRAM allocator
-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 whether or not this allocator should go upstream. Even with this allocator upstream, the system integrator is free not to use it and replace it with something else. Let's not bog down the merging of a feature just because some users may not use it. Peace. Speaking just for me (not necessarily TI), I'm ok with that. I like Rob/David's suggestion of adding request_mem_region()/release_mem_region() calls. CMEM added this recently too, so at least we'd get a nice error msg rather than have them stomp on each other. Assuming this SRAM allocator gets pushed then, can we talk through what happens when the audio driver (or any other driver!) requests this SRAM and either no SRAM is available, or this SRAM allocator isn't configured into the kernel? Do we lose the audio driver support? Does the audio driver need to plan ahead and have a mode where it doesn't use this SRAM? Chris___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
SRAM allocator(s!)
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 rather than have them stomp on each other. Assuming the SRAM allocator is pushed, can we talk through what happens when the audio driver (or any other driver!) requests this SRAM and either no SRAM is available, or this SRAM allocator isn't configured into the kernel? Do we lose the audio driver support? Does the audio driver need to plan ahead and have a mode where it doesn't use this SRAM? Chris___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Add input arguments to codec_engine scale example
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 extensions/scale directory - then the DSP
Server - then the ARM-side application so the new stubs/skels know about the
new size of that struct.
One better - if you're using a new release of Codec Engine, I'd recommend the
IUNIVERSAL interface for algs that don't match one of the existing interfaces,
rather than the 'scale' approach:
http://tiexpressdsp.com/index.php?title=Getting_started_with_IUNIVERSAL
Chris
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
José María Cubero Muñoz
Sent: Tuesday, May 26, 2009 12:48 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Add input arguments to codec_engine scale example
Hi all.
I would like to add an input parameter to the ISCALE_InArgs structure in
codec_engine's scale example.
I just added a:
XDAS_Int32 newArg
to the structure:
typedef struct ISCALE_InArgs {
XDAS_Int32 inBufSize;
XDAS_Int32 outBufSize;
XDAS_Int32 inBufValidBytes;
XDAS_Int32 newArg ;
} ISCALE_InArgs;
in the iscale.h file. But it only works when I do not put it in the last place
of the member list in the structure.
Does it only works with 3 args? I think I'm missing something simple... Some
place to define the number of arguments to be passed or the maximum size of the
memory used in the message to the DSP, maybe?
Thanks in advance.
Best regards.
José
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Crashing on ARM side while codec engine is running.
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 without memory protection (e.g. DM644x) scribbles over critical ARM-side memory (e.g. writing over Linux kernel structs). So as a general statement, we say the DSP must not crash, and if it does, to ensure system integrity you gotta reboot the device. Typically during development, a DSP-side crash does no 'real' damage, and the drivers should clean up after themselves so you can run the app again without a reboot. Older releases aren't very good about that, but they're getting better. Might try something newer(?). 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 avincidsp.com] On Behalf Of Stephane St-Hilaire Sent: Thursday, June 04, 2009 10:22 AM To: Joshua Hintze; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Crashing on ARM side while codec engine is running. I'm new to this mailing list and I'm not clear on how much this has been discussed before, but is there a way to recover from an application crash without having to reboot the system? I have this daemon that interfaces with the codec engine for the audio processing and even though I'd like to think that my code is 100% bug free (...), on the rare occasion where it would crash, I would at least like to be able to just restart it to recover. However most often than not I will either get a failed return code I believe when creating the audio encoder instance, or worst my thread will hang FOREVER on the call to Engine_open which never returns. Is there a way upon application restart to re-initialize things properly in order to avoid the reboot? Steph -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Joshua Hintze Sent: Thursday, June 04, 2009 1:13 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Crashing on ARM side while codec engine is running. Lately I've been trying to track down a bug on some of my arm code running on the davinci. As most programmers know there can be plenty of sigfaults. The problem is that the codec engine is running when I sigfault so it doesn't get closed down properly. This means the next time I try to launch my application I get this error: @0x0007f980:[T:0x4194db60] OP - Processor_create_d Loading and starting DSP server 'algo.x64P' FAILED, status=[0x8000800b] (look for error code 'DSP_EBASE + 0xb' in dsplink*/packages/dsplink/gpp/inc/errbase.h) @0x0007fbe0:[T:0x4194db60] OP - Processor_delete_d Closing remote transport FAILED, status=0x80008002. @0x0007fd08:[T:0x4194db60] OP - Processor_delete_d Stopping DSP FAILED, status=0x80008000 @0x0007fe0a:[T:0x4194db60] OP - Processor_delete_d Closing pool FAILED, status=0x80008000 @0x0007fedf:[T:0x4194db60] OP - Processor_delete_d Detaching from DSP FAILED, status=0x80008000 @0x00080948:[T:0x4214db60] CE - rserverOpen: can't start 'SARalgo.x64P'; Processor_create failed TraceUtil Error: Failed to open codec engine algo I looked in errbase.h and I see this. /* An invalid argument was specified. */ #define DSP_EINVALIDARG (DSP_EBASE + 0xBl) I don't think it's an invalid argument problem because it runs just fine if I comment out the ARM code that is causing the segfault. The only way to get it to launch the codec engine again is a full system restart. I've tried rmmod dsplinkk and cmemk and re-inserting them but that doesn't work. Just the reboot does. Any suggestions? Thanks, Josh ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: ARM application build issue
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 configuring the OSAL correctly. For a
multicore device like DM6467, it should be something like:
=
/*
* Example .cfg snippet for ARM-side Linux app with remote algs
* (OSAL = Linux, IPC = Link)
*/
var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
=
http://tiexpressdsp.com/index.php?title=CE_Config_Updates#Configuration_the_Operating_System_adaption_layer_.28OSAL.29_and_Inter_Processor_Communication_.28IPC.29_layer
Chris
-Original Message-
From:
davinci-linux-open-source-bounces+cring=ti@linux.davincids
p.com [mailto:davinci-linux-open-source-
bounces+cring=ti@linux.davincidsp.com] On Behalf Of Jaya krishnan
Sent: Tuesday, June 09, 2009 2:56 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: ARM application build issue
Hi,
I get the following errors while building my ARM application
Initially I used codec_engine_2_10_00_08
Later I changed to codec_engine_2_10_02. but still the
problem persists.
Any clues?
--
---
--
-
configuring service.x64P from package/cfg/service_x64P.cfg ...
ti.xdais.dm.examples.stwenc1.close() ...
js:
/home/jayan/devel/dm6467/dvsdk_2_10_00_08/codec_engine_2_10_0
2/packages/ti/sdo/ce/osal/bios/package.xs, line 25: exception from uncaught
JavaScript throw: TypeError: Cannot call method
instances of undefined
(/home/jayan/devel/dm6467/dvsdk_2_10_00_08/codec_engine_2_10_0
2/packages/ti/sdo/ce/osal/bios/package.xs#25)
/home/jayan/devel/dm6467/dvsdk_2_10_00_08/xdc_3_00/packages/x
dc/cfg/Main.xs, line 248
/home/jayan/devel/dm6467/dvsdk_2_10_00_08/xdc_3_00/packages/x
dc/cfg/Main.xs, line 154
/home/jayan/devel/dm6467/dvsdk_2_10_00_08/xdc_3_00/packages/x
dc/xs.js, line 137
gmake[1]: *** [package/cfg/service_x64P.xdl] Error 1
gmake: *** [/home/jayan/nftf.src/src/core,.executables] Error 2
make: *** [all] Error 2
Regards
Jayakrishnan
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Regarding build example on DM6446.
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 [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Wednesday, June 10, 2009 6:27 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: Sandeep Yedire Subject: Regarding build example on DM6446. Hello Every one, I am newbie on DM6446 EVM. I am currently working on Codec Engine examples and trying to build it. I have downloaded DVEVM 1_30_01_41 version from ti website. I have gone thru the build instructions.html and modified the two files in the example directory.. xdcpaths.mak and user.bld. I have attached these two files. When I do gmake clean in viddec_copy directory, I get this error message I have double checked the path, but i still get error message. -- [sand...@davinci codecs]$ gmake clean gmake -C viddec1_copy clean gmake[1]: Entering directory `/home/sandeep/workdir_4.0.1/ filesys/opt/ce_examples/ti/sdo/ce/examples/codecs/viddec1_copy' /home/sandeep/dvsdk_1_30_01_41/xdc_3_00_02 /xdc XDCPATH=/home/sandeep/workdir_4.0.1/filesys/opt/ce_examples/ti/sdo/ce/examples/codecs/viddec1_copy/../../../../../..;/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01 /packages;/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01 /cetools/packages \ XDCOPTIONS=v clean -PD . /bin/sh: /home/sandeep/dvsdk_1_30_01_41/xdc_3_00_02: is a directory gmake[1]: *** [clean] Error 126 gmake[1]: Leaving directory `/home/sandeep/workdir_4.0.1/filesys/opt/ce_examples/ti/sdo/ce/examples/codecs/viddec1_copy' gmake: *** [clean] Error 2 --- Please suggest where I am wrong. Best Wishes, Sandeep.Yedire Many Thanks, Sandeep.Yedire Cricket on your mind? Visit the ultimate cricket website. Enter now!http://in.rd.yahoo.com/tagline_cricket_1/*http://beta.cricket.yahoo.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: ARM application build issue
It still looks like you're building a DSP-side executable/server. configuring
service.x64P - a *.x64P is a DSP-side server.
Maybe sending the entire build log would help. When you say you only have
server.x64P, do you mean service.x64P?
Is your ARM-side cfg script using Engine.createFromServer()? If so, you'll
need the Server _package_, not just the .x64P file. The Server package has
details buried in it (like DSP-side memory map, codecs in the server and their
names, etc.) that the ARM-side's Engine.createFromServer() will need.
Chris
-Original Message-
From: Jaya 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 mentioned
the app.cfg filewas wrongly configured as
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_BIOS; So I
changed it to
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
But now the following error occurs
..
...
..
configuring service.x64P from package/cfg/service_x64P.cfg ...
OSAL- Warning: DSKT2 NOT CONFIGURED BY THE APPLICATION!
Using default segment ('null') for all IALG segments
ti.xdais.dm.examples.stwenc1.close() ...
ti.sdo.ce.osal.close() ...
ti.sdo.ce.osal.validate() ...
prog.build.platform is undefined
will link with core:null
will link with ti.sdo.ce.video1:lib/viddec1.a64P;lib/videnc1.a64P
will link with ti.sdo.ce:lib/ce.a64P
will link with ti.sdo.ce.alg:lib/Algorithm_BIOS.a64P
js:
/home/jayan/devel/dm6446/dvsdk_2_00/codec_engine_2_00/package
s/ti/sdo/ce/osal/package.xs, line 365: exception from
uncaught JavaScript throw: Error: ti.sdo.ce.osal does not
support target ti.targets.C64P with Global.runtimeEnv set to
4 (lib lib/osal_dsplink_linux.a64P not found)
/home/jayan/devel/dm6446/dvsdk_2_00/xdc_3_00_02/packages/xdc/
cfg/Main.xs, line 27
/home/jayan/devel/dm6446/dvsdk_2_00/xdc_3_00_02/packages/xdc/
cfg/Main.xs, line 173
/home/jayan/devel/dm6446/dvsdk_2_00/xdc_3_00_02/packages/xdc/
xs.js, line 144
gmake[1]: *** [package/cfg/service_x64P.xdl] Error 1
gmake[1]: *** Deleting file `package/cfg/service_x64P.xdl'
gmake[1]: *** [package/cfg/service_x64P.xdl] Deleting file
`package/cfg/service_x64P.h'
gmake[1]: *** [package/cfg/service_x64P.xdl] Deleting file
`package/cfg/service_x64P.c'
gmake: *** [/home/jayan/nftf.src/src/core,.executables] Error 2
make: *** [all] Error 2
I have access to server.x64P only, but no server package.
Regards
Jayakrishnan
--- Original Message ---
Sender : Ring, Chriscr...@ti.com
Date : Jun 10, 2009 01:36 (GMT+09:00)
Title : RE: ARM application build issue
You mention you#39;re building an ARM application, but the
build looks like it#39;s building a DSP-side server.
If you _are_ building an ARM app, it#39;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#39;s
config script is configuring the OSAL correctly. For a
multicore device like DM6467, it should be something like:
=
/*
* Example .cfg snippet for ARM-side Linux app with remote algs
* (OSAL = Linux, IPC = Link)
*/
var osalGlobal = xdc.useModule(#39;ti.sdo.ce.osal.Global#39;);
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
=
http://tiexpressdsp.com/index.php?title=CE_Config_Updates#35;
Configuration_the_Operating_System_adaption_layer_.28OSAL.29
_and_Inter_Processor_Communication_.28IPC.29_layer
Chris
-Original Message-
From:
davinci-linux-open-source-bounces+cring=ti@linux.davincids
p.com [mailto:davinci-linux-open-source-
bounces+cring=ti@linux.davincidsp.com] On Behalf Of Jaya krishnan
Sent: Tuesday, June 09, 2009 2:56 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: ARM application build issue
Hi,
I get the following errors while building my ARM application
Initially I used codec_engine_2_10_00_08
Later I changed to codec_engine_2_10_02. but still the
problem persists.
Any clues?
--
---
--
-
configuring service.x64P from package/cfg/service_x64P.cfg ...
ti.xdais.dm.examples.stwenc1.close() ...
js:
/home/jayan/devel/dm6467/dvsdk_2_10_00_08/codec_engine_2_10_0
2/packages/ti/sdo/ce/osal/bios/package.xs, line 25:
exception from uncaught JavaScript throw: TypeError: Cannot
call method
instances
RE: Instructions for making library file for C64 on evmDM6446 using xdc tools
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: http://tiexpressdsp.com/index.php?title=Codec_Engine_Roles It defines the 4 roles Codec Engine users play, the inputs/outputs each role incorporates/generates, and tools/docs which further describe the steps required. The Codec Engine examples are shaped by these 4 roles, too, as described here: http://tiexpressdsp.com/index.php?title=Codec_Engine_Examples#Physical_Layout Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Tuesday, June 16, 2009 4:44 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: Sandeep Yedire Subject: Instructions for making library file for C64 on evmDM6446 using xdc tools Hi, I am new user on evmDM6446. I am able to build and run your examples on target. My current task to to port our codec on evmDM6446. From your documents, XDC User guide.pdf, I am able to get hello.out binary file. From mail previous discussions, I understand that I need a library file which is genarated from CCS v3.3 I do not have CCS v3.3 simulator. Can I make library file with XDC tools? If so, Please give me instructions Is CCS v3.3 FET any use for me? I understand and read wiki.davincidsp.com, that after I get library file .a64P I can use RTSC wizard to create server and .x64P. Can you please provide any link for basic instructions without using CCS v3.3. I have read the document on Xdc_Userguide-Part1.pdf. It mentions about CCS v3.3 pjt. Many Thanks, Sandeep.Yedire Bring your gang together. Do your thing. Find your favourite Yahoo! Group.http://in.rd.yahoo.com/tagline_groups_9/*http://in.promos.yahoo.com/groups/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: problem including xdc/std.h
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 xdc_target__ will be defined for you. If you're building an _executable_, you should run the config step prior to building your application. * If you're not using package.bld to build your app, you'll use configuro to configure your app - which will generate a compiler.opt file you should 'cat' into your CFLAGS (this will include the -Dxdc_target__=something define). (The CE Examples include a configuro example makefile which does this - likely in examples/ti/sdo/ce/examples/video_copy/*, but may vary based on your CE version.) * If you're using package.bld, similar to the lib build, this happens for free. This all stems from xdc/std.h's extensibility support; the late binding to a 'target' via the -D option lets both your .c code and xdc/std.h remain unchanged, and yet system integrators can integrate new 'targets' that neither your .c files nor xdc/std.h have seen into the system. Some more background docs: * http://rtsc.eclipse.org/docs-tip/Consuming_Configurable_Content * http://wiki.davincidsp.com/index.php/StdDotH 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 avincidsp.com] On Behalf Of Ottavio Campana Sent: Tuesday, June 16, 2009 1:01 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: problem including xdc/std.h I am following the codec engine application developer user's guide to develop a custom application using TI h264 HD encoder. The first required step is to #include xdc/std.h But when I do it and try to compile I get ../../xdc/std.h:128: error: expected specifier-qualifier-list before 'xdc_IArg' ../../xdc/std.h:131: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xdc_floatToArg' ../../xdc/std.h:139: error: expected ')' before 'a' ../../xdc/std.h:181: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'IArg' ../../xdc/std.h:182: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'UArg' ../../xdc/std.h:184: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Int8' ../../xdc/std.h:185: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Int16' ../../xdc/std.h:186: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Int32' ../../xdc/std.h:191: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'UInt8' ../../xdc/std.h:192: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'UInt16' ../../xdc/std.h:193: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'UInt32' ../../xdc/std.h:204: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint8' ../../xdc/std.h:205: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint16' ../../xdc/std.h:206: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Uint32' By reading xdc/std.h, it seems that the file is wrong because the order of declarations is incorrect. There must be something really stupid that I'm missing, but I cannot find it. -- Non c'è più forza nella normalità, c'è solo monotonia. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: have you ever seen this error?
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 DSP Link Linux version */
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
==
If it's [incorrectly] set to osalGlobal.LINUX, you may get that error.
Chris
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of Ottavio Campana
Sent: Thursday, June 18, 2009 2:19 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: have you ever seen this error?
On Thu, Jun 18, 2009 at 10:53:15AM +0200, Vladimir Pantelic wrote:
Ottavio Campana wrote:
I'm trying to develop my application based on encodeCombo
on a dm6446.
When I try to open codec engine I get this error:
Processor_create: execv failed: Permission denied
Comm_locate:msgget: No such file or directory
error: could not open engine encode : Unable to locate the
server on the
DSP
well, where is your DSP file? CE tries to find the DSP
server file and
fails.
most demo setups expect it in the same folder as the app, so check.
I do have encodeCombo.x64P in the same directory. While
looking in
google, I found how to get more debug information, so,
by setting
CE_DEBUG=2 here is what I get:
@0,560,910us: [+6 T:0x4001eb80] CE - Engine_init CE
debugging on (CE_DEBUG=2; allowed CE_DEBUG levels: 1=min,
2=good, 3=max)
@0,561,232us: [+0 T:0x4001eb80] CS - Server_init()
@0,561,382us: [+0 T:0x4001eb80] CS - Server_init
Global_useLinkArbiter = 0
@0,561,767us: [+0 T:0x4001eb80] CE - Engine_open
Enter('encode', 0x0, 0xbe81fb8c)
@0,562,047us: [+0 T:0x4001eb80] CE -
rserverOpen('encodeCombo.x64P'), count = 0
@0,562,207us: [+0 T:0x4001eb80] OP - Processor_create
Enter(imageName='encodeCombo.x64P', attrs=0xbe81fb40)
@0,565,950us: [+0 T:0x4001eb80] OP - Processor_create return
(0x37c50)
@0,566,243us: [+0 T:0x4001eb80] CE -
rserverOpen('encodeCombo.x64P'): 0x2da78 done.
Processor_create: execv failed: Permission denied
@0,571,824us: [+0 T:0x4001eb80] OP - Processor_create return
(0x37c50)
@0,573,300us: [+0 T:0x4001eb80] CE -
rserverOpen('encodeCombo.x64P'): 0x2da78 done.
Comm_locate:msgget: No such file or directory
@10,569,223us: [+0 T:0x4001eb80] CE - Engine_close(0x37d48)
Comm_put: Invalid argument
@10,571,436us: [+0 T:0x4001eb80] CE - rserverClose(0x2da78), count = 1
@10,571,624us: [+0 T:0x4001eb80] OP - Processor_delete
Enter(proc=0x37c50)
@10,571,880us: [+1 T:0x4001eb80] OP -
Processor_delete(0x37c50) freeing object ...
@10,572,052us: [+0 T:0x4001eb80] OP - Processor_delete return.
@10,572,184us: [+0 T:0x4001eb80] CE - rserverClose(0x2da78) done.
@10,572,318us: [+0 T:0x4001eb80] CE - Engine_open return(0)
error: could not open engine encode : Unable to locate the
server on the DSP
So, rserverOpen('encodeCombo.x64P'): 0x2da78 done
gives me the
idea that it works correctly. But immediately after
that I get
Processor_create: execv failed: Permission denied
What can it be? Anything DSP related?
--
Non c'è più forza nella normalità, c'è solo monotonia.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: have you ever seen this error?
Which version of CE are you using? I want to cross-check your trace output
below against the actual sources.
Your .cfg script below looks right, but the trace output [way] below indicates
that the wrong .runtimeEnv is being pulled in. Namely, the trace indicates
that the LINUX runtimeEnv rather than the DSPLINK_LINUX runtimeEnv is being
used. Hmmm...
Maybe your build is broken - can you provide a dump of your build log (should
include a bunch of will link with package_name:lib_name(s) output - I'm
curious to see which libs are getting linked in.
Chris
-Original Message-
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 as
destination).
It seems to be correct, I'll paste it so that you can check,
do you have
any other idea?
var osalGlobal = xdc.useModule( 'ti.sdo.ce.osal.Global' );
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
var TraceUtil = xdc.useModule('ti.sdo.ce.utils.trace.TraceUtil');
TraceUtil.attrs = TraceUtil.FULL_TRACING;
xdc.loadPackage(ti.sdo.ce.video2);
xdc.loadPackage(ti.sdo.ce.video1);
xdc.loadPackage(ti.sdo.ce.video);
xdc.loadPackage(ti.sdo.ce.image1);
xdc.loadPackage(ti.sdo.ce.audio1);
xdc.loadPackage(ti.sdo.ce.audio);
xdc.loadPackage(ti.sdo.ce.speech1);
xdc.loadPackage(ti.sdo.ce.speech);
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var encode = Engine.createFromServer(
encode,
./encodeCombo.x64P,
ti.sdo.servers.encode
);
On Thu, Jun 18, 2009 at 08:04:55AM -0500, Ring, Chris wrote:
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 DSP Link Linux version */
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
==
If it's [incorrectly] set to osalGlobal.LINUX, you may
get that error.
Chris
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of Ottavio Campana
Sent: Thursday, June 18, 2009 2:19 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: have you ever seen this error?
On Thu, Jun 18, 2009 at 10:53:15AM +0200, Vladimir Pantelic wrote:
Ottavio Campana wrote:
I'm trying to develop my application based on encodeCombo
on a dm6446.
When I try to open codec engine I get this error:
Processor_create: execv failed: Permission denied
Comm_locate:msgget: No such file or directory
error: could not open engine encode : Unable to locate the
server on the
DSP
well, where is your DSP file? CE tries to find the DSP
server file and
fails.
most demo setups expect it in the same folder as the
app, so check.
I do have encodeCombo.x64P in the same directory. While
looking in
google, I found how to get more debug information, so,
by setting
CE_DEBUG=2 here is what I get:
@0,560,910us: [+6 T:0x4001eb80] CE - Engine_init CE
debugging on (CE_DEBUG=2; allowed CE_DEBUG levels: 1=min,
2=good, 3=max)
@0,561,232us: [+0 T:0x4001eb80] CS - Server_init()
@0,561,382us: [+0 T:0x4001eb80] CS - Server_init
Global_useLinkArbiter = 0
@0,561,767us: [+0 T:0x4001eb80] CE - Engine_open
Enter('encode', 0x0, 0xbe81fb8c)
@0,562,047us: [+0 T:0x4001eb80] CE -
rserverOpen('encodeCombo.x64P'), count = 0
@0,562,207us: [+0 T:0x4001eb80] OP - Processor_create
Enter(imageName='encodeCombo.x64P', attrs=0xbe81fb40)
@0,565,950us: [+0 T:0x4001eb80] OP - Processor_create return
(0x37c50)
@0,566,243us: [+0 T:0x4001eb80] CE -
rserverOpen('encodeCombo.x64P'): 0x2da78 done.
Processor_create: execv failed: Permission denied
@0,571,824us: [+0 T:0x4001eb80] OP - Processor_create return
(0x37c50)
@0,573,300us: [+0 T:0x4001eb80] CE -
rserverOpen('encodeCombo.x64P'): 0x2da78 done.
Comm_locate:msgget: No such file or directory
@10,569,223us: [+0 T:0x4001eb80] CE - Engine_close(0x37d48)
Comm_put: Invalid argument
@10,571,436us: [+0 T:0x4001eb80] CE -
rserverClose(0x2da78), count = 1
@10,571,624us: [+0 T:0x4001eb80] OP - Processor_delete
Enter(proc=0x37c50)
@10,571,880us: [+1 T:0x4001eb80] OP -
Processor_delete(0x37c50) freeing object ...
@10,572,052us: [+0 T:0x4001eb80] OP - Processor_delete return.
@10,572,184us: [+0 T:0x4001eb80] CE - rserverClose(0x2da78) done.
@10,572,318us: [+0 T:0x4001eb80] CE - Engine_open return(0)
error: could not open engine
RE: Codec Engine 2_23_01 Failure to load Server
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 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Brian Rhodes Sent: Tuesday, June 23, 2009 12:18 PM To: Brian Rhodes Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Codec Engine 2_23_01 Failure to load Server Brian Rhodes wrote: MV Pro 5.0 toolchain Codec Engine 2.23.01 DSP/BIOS 5.33.05 XDCTOOLS 3.15.00.50 Framework Components 2.23.01 XDAIS 6.23 DSPLINK 1.61.03 CMEM (linuxutils) 2.23.01 The error message @0,123,595us: [+7 T:0x44643490 S:0x44642d74] OP - Processor_create_d Loading and starting DSP server 'mpeg2_dec_server.x64P' FAILED, status=[0x80008009] (look for error code 'DSP_EBASE + 0x9' in dsplink*/packages/dsplink/gpp/inc/usr/errbase.h) says... /* The specified executable file could not be found. */ #define DSP_EFILE (DSP_EBASE + 0x9l) Previously I had simply located the DSP binary in the CWD, but surely I've missed something in the documentation and this is now incorrect. Is there a different way of configuring the path? I recall something from a much older version of CE where you could specify the absolute path in the engine creation call. I found that I had a conditional including an incorrect config for my server which was using DSP/BIOS 5_33_02 and that was causing the problem loading the server. I am now having an issue with my memory map (I think). I am getting an error when starting up the first server on the dsp (from dsplink). cmem initialized 9 pools between 0x8780 and 0x8800 DSPLINK Module (1.61.03) created on Date: Jun 23 2009 Time: 13:56:46 Assertion failed (cBytes != 0). File : /home/bgr/projects/cerberus/support/code1 Assertion failed (PMGR_MSGQ_IsInitialized == TRUE). File : /home/bgr/projects/c3 Unable to handle kernel NULL pointer dereference at virtual address I think it is using the wrong memory area since the real failure here appears to be incorrect data in the memory table. One of the sizes appears as 0 causing the setup to fail, which then causes an Oops on shutdown freeing a NULL ptr. I tried specifying the memory map in the application config as well. @0,432,351us: [+2 T:0x40b02490 S:0x40b01d74] OP - Processor_create_d Adding DSP segment #0 to Link configuration: name='DDR2', startAddress=0x8fa0, sizeInBytes=0x40, shared=1, syncd=0 @0,432,595us: [+2 T:0x40b02490 S:0x40b01d74] OP - Processor_create_d Adding DSP segment #1 to Link configuration: name='DSPLINKMEM', startAddress=0x8fe0, sizeInBytes=0x3, shared=1, syncd=0 @0,432,803us: [+2 T:0x40b02490 S:0x40b01d74] OP - Processor_create_d Adding DSP segment #2 to Link configuration: name='RESET_VECTOR', startAddress=0x8ff0, sizeInBytes=0x80, shared=1, syncd=0 @0,433,007us: [+2 T:0x40b02490 S:0x40b01d74] OP - Processor_create_d Adding DSP segment #3 to Link configuration: name='POOLMEM', startAddress=0x8fe3, sizeInBytes=0xd, shared=1, syncd=0 @0,433,210us: [+2 T:0x40b02490 S:0x40b01d74] OP - Processor_create_d Adding DSP segment #4 to Link configuration: name='DDRALGHEAP', startAddress=0x8800, sizeInBytes=0x400, shared=0, syncd=0 @0,433,405us: [+2 T:0x40b02490 S:0x40b01d74] OP - Processor_create_d DODSPCTRL was=1; now=0 @0,435,559us: [+0 T:0x4001fbc0 S:0xbedd298c] ti.sdo.ce.osal.Sem - Leaving Sem_post sem[0x441c0] @0,435,874us: [+0 T:0x4001fbc0 S:0xbedd296c] ti.sdo.ce.osal.Sem - Entered Sem_pend sem[0x441d8] timeout[0x] Anyone had success with this version of dsplink on dm6446? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Using buildinstructions fatal error #5: could not open source file ti/xdais/dm/ividdec.h
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 Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Wednesday, June 24, 2009 3:37 AM To: JayaKumar, PremKumar; davinci-linux-open-source@linux.davincidsp.com Cc: bmi...@acmet.com; Sandeep Yedire Subject: Re: Using buildinstructions fatal error #5: could not open source file ti/xdais/dm/ividdec.h Thanks. seems working. This seems buggy as I dont have cetools folder. so it shud take it as zero. Many Thanks, Sandeep.Yedire From: JayaKumar, PremKumar premkuma...@ti.com To: Sandeep YEDIRE sandee...@yahoo.co.in; davinci-linux-open-source@linux.davincidsp.com davinci-linux-open-source@linux.davincidsp.com Cc: bmi...@acmet.com bmi...@acmet.com; Sandeep Yedire sande...@acmet.com Sent: Wednesday, 24 June, 2009 3:42:42 PM Subject: RE: Using buildinstructions fatal error #5: could not open source file ti/xdais/dm/ividdec.h From the error message you can see that the xdais path is tried to be picked from the cetools. Try setting USE_CETOOLS_IF_EXISTS = 0 in the xdcpaths.mak so that the path which you want to be set as xdais path in the XDCPATH will take effect. Regards, Prem From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Wednesday, June 24, 2009 3:17 PM To: davinci-linux-open-source@linux.davincidsp.com Cc: bmi...@acmet.com; Sandeep Yedire Subject: Using buildinstructions fatal error #5: could not open source file ti/xdais/dm/ividdec.h Hello there, i have been working on DM6446 for about a week now but not able to set-up properly. I followed instructions given in sprue66d.pdf for installation on my RHEL -4 pc. I did this twice as I got strange error message when working with one of examples. Which I already posted with subject :xdc.loadPackage: can't find package 'ti.sdo.ce' when building viddec_copy examples date:22/06/09. I could not find casue for this error and try to set-up everything again. When I finished with setting up everything, With refering to build instruction in codec_engine/examples/, I mdofied changes in xdcpath.mak and user.bld file accordingly. I have copied both the files below. When I did gmake in dir ~/work/examples/ti/sdo/ce/examples/codecs/viddec_copy/, I get this error message which is given below. I found these header files, in dir /home/sandeep/dvsdk_1_30_01_41/xdais_6_00_01/packages/ti/xdais/dm/ But these are not included when I build them. I also set my env variable for XDCPATH accordingly. Please find my XDCPATH below with heading. It looks like, I have not included the correct XDCPATH which actually is the problem for my earlier failure. Please look for below files for any help in this issue. I can copy the contents of /home/sandeep/dvsdk_1_30_01_41/xdais_6_00_01/packages/ti/ to ~/work/examples/ti/ for this error. But When I have given path in xdcpath.mak file, and the makefile in viddec_copy folder will refer to this xdcpath.mak for its packages. Please look for below files for any help/advice in this issue I am having. --- Error message: [sand...@evmdm6446 viddec_copy]$ gmake /home/sandeep/dvsdk_1_30_01_41/xdc_3_00_02/xdc XDCPATH=/home/sandeep/work/examples/ti/sdo/ce/examples/codecs/viddec_copy/../../../../../..;/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01/packages;/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01/cetools/packages;/home/sandeep/dvsdk_1_30_01_41/bios_5_31_08/packages \ XDCOPTIONS=v all -PD . making all: Wed Jun 24 14:31:14 IST 2009 ... .interfaces [/home/sandeep/work/examples/ti/sdo/ce/examples/codecs/viddec_copy] gmake[1]: `.interfaces' is up to date. .interfaces files complete: Wed Jun 24 14:31:14 IST 2009. .libraries [/home/sandeep/work/examples/ti/sdo/ce/examples/codecs/viddec_copy] rm -f package/lib/lib/viddec_copy/viddec_copy.o64P # # cl64P viddec_copy.c ... /home/sandeep/dvsdk_1_30_01_41/cg6x_6_0_15/bin/cl6x -c -oe -qq -pdsw225 -pden -pds=195 -mv64p -eo.o64P -ea.s64P -Dxdc_target_name__=C64P -Dxdc_target_types__=ti/targets/std.h -Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_6_0_15 -o2 -I.. -I/home/sandeep/work/examples/ti/sdo/ce/examples/codecs/viddec_copy/../../../../../... -I/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01/packages -I/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01/cetools/packages
RE: Codec Engine 2_23_01 Failure to load Server
I don't really understand this yet, but maybe some background will help [at least!] both of us... In general, the ARM-side Link config can be done in 1 of 2 use cases: 1. Static config. The config struct is constructed in a .c file and built _into_ the Link binaries during the DSP Link build. The pre-built config is used when, at run time, PROC_setup() is called with a NULL config struct ptr. 2. Dynamic config. The config struct is crafted at run time and passed into Link via the PROC_setup() call. Codec Engine uses the 2nd model under the hood (during Engine_open()). Since the memory map is part of this config, and different DSP images can potentially have different memory maps, this approach lets Codec Engine load different images without forcing a rebuild of anything. (BTW, this memory map info is some of the gems we scrape out of the DSP build during Engine.createFromServer()). All that to say I don't know why changing _your_ static LINKCFG_Dsp struct (which might be used in use case #1) has any affect in a Codec Engine-based system (which uses use case #2). :? Chris -Original Message- From: Brian Rhodes [mailto:b...@acdstar.com] Sent: 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 the LINKCFG_Dsp structure. The av5T ipc_dsplink library which is being linked with the application seems to have some duplicate symbols. I modified the LINKCFG_Dsp in dsplink to change the name and found that the settings from the ipc dsplink library are there as well. objdump does list duplicate symbols for the dsp config. The alignment after the dsp power control field is off 4 bytes in the data dsplink gets from the application. I was able to get the system working by adding a 4 byte offset in the LINKCFG_Dsp structure for the kernel dsplink component after the dsp power control field. Is this possibly happening because I built dsplink kernel module using kbuild? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: dvsdk 2.0 fails to build.
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 Message-
From:
davinci-linux-open-source-bounces+cring=ti@linux.davincids
p.com [mailto:davinci-linux-open-source-
bounces+cring=ti@linux.davincidsp.com] On Behalf Of Yusuf
Caglar AKYUZ
Sent: Monday, June 29, 2009 2:57 AM
To: Andrea Gasparini
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: dvsdk 2.0 fails to build.
Andrea Gasparini wrote:
Hi,
I'm trying to build DVSK 2_00_00_22, and I'm failing in it.
More precisely, it's dmai make that blame with the following line:
/mnt/lavoro/gigavision/mv_pro_5.0/montavista/pro/devkit/arm/v5
t_le/bin/../lib/gcc/armv5tl-
montavista-linux-gnueabi/4.2.0/../../../../armv5tl-montavista-linux-
gnueabi/bin/ld: cannot find
/db/rtree/niclas/davinci_multimedia_application_interface/dmai
/packages/ti/sdo/dmai/apps/video_loopback_copy/linux/video_loo
pback_copy_dm355_config/package/cfg/video_loopback_copy_dm355_
x470MV.o470MV
and of course I don't have /db/rtree/niclas/ path. A
quick search tells
me that all that kind of file:
./apps/image_decode_io1/linux/image_decode_io1_dm355_config/pa
ckage.bld
./apps/image_encode_io1/linux/image_encode_io1_dm355_config/pa
ckage.bld
./apps/speech_decode_io1/linux/speech_decode_io1_dm355_config/
package.bld
./apps/video_decode_io2/linux/video_decode_io2_dm355_config/pa
ckage.bld
./apps/video_encode_io1/linux/video_encode_io1_dm355_config/pa
ckage.bld
./apps/video_encode_io_multich1/linux/video_encode_io_multich1
_dm355_config/package.bld
./apps/video_loopback_copy/linux/video_loopback_copy_dm355_con
fig/package.bld
./apps/video_loopback_resize/linux/video_loopback_resize_dm355
_config/package.bld
have hardcoded the wrong path, here it is a snap of one of them:
var exeOpts = new Executable.Attrs({
cfgScript:
'/db/rtree/niclas/davinci_multimedia_application_interface/dma
i/packages/ti/sdo/dmai/apps/video_loopback_copy/linux/video_lo
opback_copy_dm355.cfg',
profile: 'release',
cfgHome: 'video_loopback_copy_dm355_config',
});
Ok, the question now is: am I doing something wrong or
really are all
package.bld files bugged? Is there perhaps a way to regenerate all
package.bld ?
( dmai version is 1_20_00_06 )
thanks.
AFAIK, package.bld files are generated automatically. You need to
adjust makefiles for correct toolchains. I'm using OpenEmbedded for
DMAI builds. It has most of the patches necessary for building DMAI
and gstreamer-ti. I'm attaching most related patches here for your
reference. 1st one is from OE, 2nd one is mine local patch for
dm6446 builds.
Regards,
Caglar
__
Index: dmai_1_20_00_06/packages/config.bld
===
--- dmai_1_20_00_06.orig/packages/config.bld 2009-02-11
19:38:51.0 -0600
+++ dmai_1_20_00_06/packages/config.bld 2009-02-11
19:39:23.0 -0600
@@ -42,7 +42,7 @@
/* location of the Codec Sourcery Arm9 tools */
var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
-GCArmv5T.LONGNAME = 'bin/arm-none-linux-gnueabi-gcc';
+GCArmv5T.LONGNAME = 'bin/arm-angstrom-linux-gnueabi-gcc';
GCArmv5T.platform = ti.platforms.evm3530;
GCArmv5T.rootDir = java.lang.System.getenv(CSTOOL_DIR);
Index: dmai_1_20_00_06/packages/ti/sdo/dmai/Makefile
===
--- dmai_1_20_00_06.orig/packages/ti/sdo/dmai/Makefile
2009-02-11
19:39:57.0 -0600
+++ dmai_1_20_00_06/packages/ti/sdo/dmai/Makefile 2009-02-11
19:58:05.0 -0600
@@ -33,7 +33,7 @@
DMAI_INSTALL_DIR = ../../../..
TARGET = dmai
-include $(DMAI_INSTALL_DIR)/Rules.make
+#include $(DMAI_INSTALL_DIR)/Rules.make
# Should the full command be echoed to the console during build?
VERBOSE=false
@@ -64,7 +64,7 @@
MVL_CPP_FLAGS= $(GNU_CPP_FLAGS)
-Dxdc_target_name__=MVArm9
CS_CPP_FLAGS = $(GNU_CPP_FLAGS)
-Dxdc_target_name__=codesourcery/GCArmv5T
-GNU_C_FLAGS = $(C_FLAGS) -Wall -Werror
+GNU_C_FLAGS = $(C_FLAGS) -Wall
C64P_C_FLAGS = $(C_FLAGS)
GNU_AR_FLAGS = $(AR_FLAGS)
Index: dmai_1_20_00_06/packages/ti/sdo/dmai/apps/Makefile.app
===
--- dmai_1_20_00_06.orig/packages/ti/sdo/dmai/apps/Makefile.app
2009-02-11 19:58:44.0 -0600
+++ dmai_1_20_00_06/packages/ti/sdo/dmai/apps/Makefile.app
2009-02-11 19:59:01.0 -0600
@@ -34,7 +34,7 @@
ifndef DMAI_INSTALL_DIR
DMAI_INSTALL_DIR = ../../../../../..
RE: Debugging or using trace on evmDM6446
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 Sent: Tuesday, July 07, 2009 7:25 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: bmi...@acmet.com Subject: Debugging or using trace on evmDM6446 Hello there, I am currently working on my own algorithm on evmDM6446. I m able to create video server and want to debug on DSP 64XX. Can you please inform how to debug on DSP side and any info or link is really appreciated. Many Thanks, Sandeep.Yedire ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Debugging or using trace on evmDM6446
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 on evmDM6446 I am sorry, I do not have CCS v3.3 IDE. Is it possible to debug without that on DSP core? is there Any other alternate way to check data on DSP side ? Many Thanks, Sandeep.Yedire From: Ring, Chris cr...@ti.com To: Sandeep YEDIRE sandee...@yahoo.co.in; davinci-linux-open-source@linux.davincidsp.com davinci-linux-open-source@linux.davincidsp.com Cc: bmi...@acmet.com bmi...@acmet.com Sent: Wednesday, 8 July, 2009 2:23:40 AM Subject: RE: Debugging or using trace on evmDM6446 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 Sent: Tuesday, July 07, 2009 7:25 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: bmi...@acmet.com Subject: Debugging or using trace on evmDM6446 Hello there, I am currently working on my own algorithm on evmDM6446. I m able to create video server and want to debug on DSP 64XX. Can you please inform how to debug on DSP side and any info or link is really appreciated. Many Thanks, Sandeep.Yedire Love Cricket? Check out live scores, photos, video highlights and more. Click herehttp://in.rd.yahoo.com/tagline_cricket_2/*http://cricket.yahoo.com. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to generate .map file when creating server.
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 Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Thursday, July 09, 2009 3:43 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: How to generate .map file when creating server. Hi all, Can you please suggest me How to generate .map file when creating server ? I dont have ccs v3.3. Many Thanks, Sandeep.Yedire See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzzhttp://in.rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: TMS320DM6446 errata documents
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 in early 2007! 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 avincidsp.com] On Behalf Of Ladányi Péter Sent: Thursday, July 09, 2009 3:18 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: TMS320DM6446 errata documents Dear Friends, I have to check something in more earlier versions of official Texas's errata documents for TMS320DM6446. Actually, I need the following documents: sprz241e.pdf sprz241f.pdf sprz241h.pdf sprz241i.pdf sprz241j.pdf (I have got the ...g, ...k and ..l versions) Has anybody these erratas? Best regards, Peter __ ESET Smart Security - Vírusdefiníciós adatbázis: 4227 (20090709) __ Az üzenetet az ESET Smart Security ellenorizte. http://www.eset.hu ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to generate .map file when creating server.
Ah. The video_copy example shows how to build a Server with a GNU makefile, so many of the freebies you get from a package.bld-based build (like generating a .map file) aren't there. You should see an explicit '$(LINK)' command in the makefile you'll have to modify. The TI tools generate 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 Subject: Re: How to generate .map file when creating server. Yes I did notice that its auto-generated in all_codecs folder, but its not generated in video_copy folder. I am currently working on video_copy folder. The execution flow by using CE_DEBUG =2 is not just halts after I modified (added my call to decoder) viddec_copy example. I want to check the .map generated file if any help. Please let me know what difference in extra command that actaully made all_codecs generate .map and that did not in video_copy. Many Thanks, Sandeep.Yedire From: Ring, Chris cr...@ti.com To: Sandeep YEDIRE sandee...@yahoo.co.in; davinci-linux-open-source@linux.davincidsp.com davinci-linux-open-source@linux.davincidsp.com Sent: Thursday, 9 July, 2009 7:32:16 PM Subject: RE: How to generate .map file when creating server. 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 Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Thursday, July 09, 2009 3:43 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: How to generate .map file when creating server. Hi all, Can you please suggest me How to generate .map file when creating server ? I dont have ccs v3.3. Many Thanks, Sandeep.Yedire See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzzhttp://in..rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/. Looking for local information? Find it on Yahoo! Localhttp://in.rd.yahoo.com/tagline_local_1/*http://in.local.yahoo..com/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: TI JPEGENC 2.00.00.2 unable to call IMGENC1_create
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 yourself... and here's the memory you asked for. Typically this happens b/c the specific create params aren't supported(?). Regarding #4, that's a great data point - does the codec example app use the same create params you're using? If not, can you change the create params to what you want and successfully create the codec? Chris From: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On Behalf Of Frank Bhattacharyya Sent: Wednesday, August 19, 2009 8:32 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: TI JPEGENC 2.00.00.2 unable to call IMGENC1_create Dear group, I'm still searching why the TI JPEG encoder fails in IMGENC1_create. The general problem is: Calling // setup imgenc_params.size = sizeof(IIMGENC1_Params); imgenc_params.maxHeight = 480; imgenc_params.maxWidth = 720; imgenc_params.maxScans = 3; imgenc_params.dataEndianness = XDM_BYTE; imgenc_params.forceChromaFormat = XDM_YUV_422ILE; // call iencHandle = IMGENC1_create(codecengine, encoderName, imgenc_params ); always fails (returns NULL), if I use iencHandle = IMGENC1_create(codecengine, encoderName, NULL ); a non null ptr is returned but I can't do any IMGENC1_control/process calls (all fail). I have attached a trace log of a sample run (CE_DEBUG=2, DSKT2 trace enabled)). So some basic questions/comments: 1. Has anyone ever managed to successfully integrate the JPEGENC 2.00.00.2 encoder on an DM6446 (DVEVM)board using DVSDK 1.30 into a CE application? 2. I've also tried the DVSDK 2.00 but it still fails to create the encoder instance. 3. Is there a way to get some more trace/debugging information out of the encoder (algorithm) instance? My current trace mask is: export CE_TRACE=*=01234567 export TRACEUTIL_DSP0TRACEMASK=*+01;*=01234567 There is no output from the encoder itself. The last trace message is from DSKT2_createAlg3: [DSP] @2,402,771tk: [+7 T:0x8fa0348c] ti.sdo.fc.dskt2 - DSKT2_createAlg3 algInit call failed -1 4. I have compiled the JPEG encode example with CCS and tested it as a DSP only app. Everything works as expected. So the encoder library seems to be healthy 5. I have double checked the dsplink memory segments with the TCF memory segments and they do match. 6. If I use the (very simple) imgenc1_copy encoder (replace the algorithm in the server cfg file) everything is working. 7. A self built video_copy server/app runs w/o problems, so the build environment seems to be healthy. Any hint/comment is appreciated. Regards Frank ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Regarding dynamic memory allocation on DSP side of DM6446.
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 From: davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+cring=ti@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Wednesday, August 26, 2009 6:08 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: Sandeep Yedire Subject: Regarding dynamic memory allocation on DSP side of DM6446. Hello, Can we allocate Dynamic memory on DSP side of DM6446? Many Thanks, Sandeep.Yedire Looking for 24 hour chemists in your area? Try Yahoo! India Localhttp://in.rd.yahoo.com/tagline_local_9/*http://in.local.yahoo.com/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Regarding printf usage in Codec algorithm -Dm6446
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 [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sandeep YEDIRE Sent: Monday, September 07, 2009 8:37 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: sande...@acmet.com Subject: Regarding printf usage in Codec algorithm -Dm6446 Hello all, I might not sure about this problem I come across on DM6446. The codec stack i estimated on DM6446 is 1.5KB. I have used memtab for allocation and now my data (structures) on Heap is 210KB. I confirm thru CE_DEBUG=2 and DSKT2.trace=true. This heap data is allocated. Now my doubt and my problem, even when codec stack requirement is low 2KB, why does DM6446 halts ? I simulated same problem with having a huge array of 80-90K in local(in-side func). 1. Is it like using printf's or File * can cause this? 2. Does stack size vary on DM6446 wehn compared to CCS v3.1? 3. Is it like, I am not following xDAIS? There are no malloc in my codec algo. I have taken arrays and allocated and initialized. Please suggest some advice on this. Many Thanks, Sandeep.Yedire See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzzhttp://in.rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Requesting for help:
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 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Requesting for help: Hi All, I am trying to build the Object video server , while building i am getting fallowing issue... /dm6446/dvsdk_1_30_01_41/xdc_3_00_02;/home/dm6446/dvsdk_1_30_01_41/xdc_3_00_02/etc -Dxdc.bld.targets= -DTOOLS= -Dxdc.traceEnable= /home/dm6446/dvsdk_1_30_01_41/xdc_3_00_02/packages/xdc/bld/bld.js /home/dm6446/dvsdk_1_30_01_41/codec_engine_2_00_01/packages/config.bld package.bld package.mak config.bld: loading user build configuration file /home/dm6446/dvsdk_1_30_01_41/codec_engine_2_00_01/examples/user.bld js: /home/dm6446/dvsdk_1_30_01_41/codec_engine_2_00_01/packages/config.bld, line 131: exception from uncaught JavaScript throw: Error: config.bld: Error: compiler path for C6x DSP tools points to an incorrect directory (C64P.rootDir='/db/toolsrc/library/tools/vendors/ti/c6x/6.0.16/Linux'). Edit file '/home/dm6446/dvsdk_1_30_01_41/codec_engine_2_00_01/examples/user.bld' and correct the line that sets the 'C64P.rootDir' variable. /home/dm6446/dvsdk_1_30_01_41/xdc_3_00_02/include/utils.tci, line 588 /home/dm6446/dvsdk_1_30_01_41/xdc_3_00_02/include/utils.tci, line 506 /home/dm6446/dvsdk_1_30_01_41/xdc_3_00_02/packages/xdc/bld/BuildEnvironment.xs, line 106 /home/dm6446/dvsdk_1_30_01_41/xdc_3_00_02/packages/xdc/bld/bld.js, line 74 /home/dm6446/dvsdk_1_30_01_41/xdc_3_00_02/packages/xdc/bld/bld.js, line 141 gmake[1]: *** [package.mak] Error 1 gmake: *** [/home/dm6446/chandra/OV_5.0.1/OnBoard_SDK/Davinci/CCS3.2_DVEVM6446/servers/ovanalytics,.interfaces] Error 2 make: *** [all] Error 2 Please kindly help me. Regs, Chandrashekar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DSP hang when run DVSDK Demo in DM6446
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 so, you might use the BIOS object viewers to inspect what tasks are running, if any have blown their stacks, etc. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Jack Sent: Wednesday, September 23, 2009 2:39 AM To: Uppal, Deepali; 'davinci-linux-open-source@linux.davincidsp.com' Subject: RE: DSP hang when run DVSDK Demo in DM6446 Hi: No! my meaning is after check the message when using CE_DEBUG=2, It seems the DSP hanging. Thanks. Jack -Original Message- From: Uppal, Deepali [mailto:deep...@ti.com] Sent: Wednesday, September 23, 2009 5:29 PM To: Jack; 'davinci-linux-open-source@linux.davincidsp.com' Subject: RE: DSP hang when run DVSDK Demo in DM6446 Hi, But system no respond after capture and encode some frame, It seems the DSP hand after running with CE_DEBUG=2 Do you see a hang only when you run with CE_DEBUG=2? Thanks and Regards, Deepali Uppal DSP/BIOS Link Platform Support Products -Original Message- From: Jack [mailto:ads...@gmail.com] Sent: Wednesday, September 23, 2009 1:50 PM To: Uppal, Deepali; 'davinci-linux-open-source@linux.davincidsp.com' Subject: RE: DSP hang when run DVSDK Demo in DM6446 Hi Deepali Uppal: You are right, each time when the DSP hanging, it run at: @6,001,216us: [+0 T:0x41baf490 S:0x41baea84] OC - Comm_get Enter(queue=0x10001, msg=0x41baeb3c, timeout=-1) and the next code is (according log): @6,021,210us: [+0 T:0x41baf490 S:0x41baea84] OC - Comm_get MSGQ_get() status=0x8000, return (0) It seems DSPLink waiting to get a message... @6,000,282us: [+1 T:0x41baf490 S:0x41baea84] OM - Memory__getPhysicalAddress returning physAddr=0x87965000 @6,000,443us: [+0 T:0x41baf490 S:0x41baea84] OM - Memory_getBufferPhysicalAddress return (0x87965000) @6,000,612us: [+0 T:0x41baf490 S:0x41baeac4] CV - VISA_call(visa=0x60f90, msg=0x425d0c80): messageId=0x00023823, command=0x0 @6,000,792us: [+0 T:0x41baf490 S:0x41baea8c] OC - Comm_put Enter(queue=0x2, msg=0x425d0c80) @6,001,036us: [+0 T:0x41baf490 S:0x41baea8c] OC - Comm_put return (0) @6,001,216us: [+0 T:0x41baf490 S:0x41baea84] OC - Comm_get Enter(queue=0x10001, msg=0x41baeb3c, timeout=-1) *** hang up here each time *** @6,021,210us: [+0 T:0x41baf490 S:0x41baea84] OC - Comm_get MSGQ_get() status=0x8000, return (0) @6,021,508us: [+0 T:0x41baf490 S:0x41baea14] OC - Comm_put Enter(queue=0x0, msg=0x425cfc80) @6,021,903us: [+0 T:0x41baf490 S:0x41baea14] OC - Comm_put return (0) @6,022,158us: [+0 T:0x41baf490 S:0x41baea0c] OC - Comm_get Enter(queue=0x1, msg=0x41baeaac, timeout=-1) @6,022,541us: [+0 T:0x41baf490 S:0x41baea0c] OC - Comm_get MSGQ_get() status=0x8000, return (0) [DSP] @7,792,696tk: [+5 T:0x8fa474e4 S:0x8fa4b8b4] CN - NODE 0x8fa46f88(h264enc#0) call(algHandle=0x8fa47048, msg=0x8fe06c80); messageId=0x00023823 [DSP] @7,792,786tk: [+0 T:0x8fa474e4 S:0x8fa4b77c] OM - Memory_cacheInv Enter(addr=0x87bc6000, sizeInBytes=691200) [DSP] @7,793,597tk: [+0 T:0x8fa474e4 S:0x8fa4b77c] OM - Memory_cacheInv return [DSP] @7,793,647tk: [+0 T:0x8fa474e4 S:0x8fa4b744] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process Enter (handle=0x8fa47048, inBufs=0x8fa4b7e4, outBufs=0x8fa4b8b4, inArgs=0x8fe06e04, outArgs=0x8fe06e10) [DSP] @7,793,754tk: [+5 T:0x8fa474e4 S:0x8fa4b724] CV - VISA_enter(visa=0x8fa47048): algHandle = 0x8fa47078 [DSP] @7,793,813tk: [+0 T:0x8fa474e4 S:0x8fa4b704] ti.sdo.ce.alg.Algorithm - Algorithm_activate Enter(alg=0x8fa47078) [DSP] @7,793,876tk: [+0 T:0x8fa474e4 S:0x8fa4b704] ti.sdo.ce.alg.Algorithm - Algorithm_activate Exit [DSP] @7,836,543tk: [+5 T:0x8fa474e4 S:0x8fa4b724] CV - VISA_exit(visa=0x8fa47048): algHandle = 0x8fa47078 [DSP] @7,836,637tk: [+0 T:0x8fa474e4 S:0x8fa4b704] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate Enter(alg=0x8fa47078) [DSP] @7,836,707tk: [+0 T:0x8fa474e4 S:0x8fa4b704] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate Exit [DSP] @7,836,763tk: [+0 T:0x8fa474e4 S:0x8fa4b744] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process Exit (handle=0x8fa47048, retVal=0x0) [DSP] @7,836,836tk: [+0 T:0x8fa474e4 S:0x8fa4b77c] OM - Memory_cacheWb Enter(addr=0x87965000, sizeInBytes=345600) [DSP] @7,837,300tk: [+0 T:0x8fa474e4 S:0x8fa4b77c] OM - Memory_cacheWb return Cap:Complete cap 02 frame at:8430 691200 [DSP] @7,837,345tk: [+5 T:0x8fa474e4 S:0x8fa4b8b4] CN - NODE returned from call(algHandle=0x8fa47048, msg=0x8fe06c80); messageId=0x00023823 [DSP] @7,841,122tk: [+0 T:0x8fa424e4 S:0x8fa464a4] CR - processRmsCmd(0x8fe05ca8, 4056): cmd = 5 [DSP] @7,841,179tk: [+0 T:0x8fa424e4
RE: Requesting for help:
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: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of chandrashekar reddy Sent: Wednesday, September 30, 2009 2:52 AM To: davinci-linux-open-sou...@linux.davincid Subject: Requesting for help: Hi all, While running the ./loadmodules.sh I am getting the fallowing issue.. insmod: error inserting 'cmemk.ko': -1 Invalid module format Thanks for kind help. regards, chandrashekar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Arago Kerenel w/ codec_engine_2_00_01 issues?
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 see that the memory requested by the alg succeeds (the codec needs 7 distinct memory blocks, and I can see 7 successful CMEM alloc() calls being made). However, during the algInit() call (where Codec Engine provides this newly allocated memory to the codec), the codec is returning 49280 (0xC080). So the codec didn't like something it was given - either the memory (unlikely) or the creation params(?) - and returned this error. Do the codec docs (or headers?) provide any details about this specific error code (0xC080)? Does it fail if you pass in NULL as the create() params? Finally, to your specific question, the error returned (mpeg4enc (0x0)) indicates a NULL handle, not a success code. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Paul Stuart Sent: Tuesday, January 05, 2010 7:26 AM To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? Thanks for the response! I'll give the latest CMEM, LinuxUtils, et al a whirl and see what happens. The strange thing is that the mpeg4 decoder, jpeg encode/decode, and mp3 encode/decode all load without complaint. It's just the mpeg4enc that fails. I've rebuilt cmemk.ko and dm350mmap.ko against the arago kernel. Neither process was straight forward though because of changes between the montavista kernel we were using. Maybe something got botched in the process. Turning on the trace, with CE_DEBUG=2, I get the following during mpeg4enc initialization: @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create Enter (engine=0x100670, name='mpeg4enc', params=0x432ffca8) @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create Enter(fxns=0xf89c0, idma3Fxns=0xf8988, iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8) @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, params=0x432ffca8) @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create algNumAlloc 7 memory recs @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create algAlloc returned numRecs=7 @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[0]: size=0x2c58, align=0x100, space=0x11, attrs=0x1 @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[1]: size=0x200, align=0x100, space=0x11, attrs=0x1 @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[2]: size=0x19a400, align=0x100, space=0x11, attrs=0x1 @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[3]: size=0x10e0, align=0x100, space=0x11, attrs=0x1 @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[4]: size=0x4, align=0x100, space=0x11, attrs=0x1 @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[5]: size=0x14000, align=0x100, space=0x11, attrs=0x1 @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[6]: size=0x3840, align=0x100, space=0x11, attrs=0x1 @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(11352) = 0x43301000. @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43301000) = 0x8702c000. @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(512) = 0x42a02000. @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x42a02000) = 0x87018000. @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(1680384) = 0x43305000. @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43305000) = 0x87e0. @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(4320) = 0x43505000. @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43505000) = 0x8702a000. @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(4) = 0x43507000. @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43507000) = 0x87019000. @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(81920) = 0x43508000. @5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43508000) = 0x8704e000.
RE: 76Mb memory limit on dm365
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 avincidsp.com] On Behalf Of Diego Dompe Sent: Wednesday, February 10, 2010 12:30 PM To: Ramiro Polla Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: 76Mb memory limit on dm365 Ramiro, This limit is due the cmem buffers being allocated to this location. If you have more RAM available on your final board, you can just move the cmem buffers to another location and give more memory to the Linux kernel. Diego On Feb 10, 2010, at 2:12 PM, Ramiro Polla wrote: Hi, Some documentation for the dm365 (for example dvsdk_2_10_01_18/dm365_2_10_01_18_release_notes.html) suggests setting mem=76M in the bootargs. Why is there such a limit? Isn't there more memory available in the board? Any pointer to more complete documentation on the subject is welcome. Ramiro Polla ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM Memory Map
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 also be allocated from CMEM. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of david.kond...@legrand.us Sent: Monday, February 15, 2010 6:51 AM To: Sameer Naik Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: CMEM Memory Map Greetings, As far as I knew, any XDAIS or XDM spec'd algorithms cannot allocate their own CMEM buffers. CMEM allocations are always under application control and thus you can dictate where the shared memory is allocated. In fact, you could not use CMEM at all and just have a section of memory that is non-cached and untouched by the kernel, but it is easier to use the CMEM driver. What you may be thinking of the is algorithm heap (sometimes called DDRALGHEAP) and scratch DDR memory. These can be requested (and hence denied) by the algorithm from the Codec Server. Managing total system memory involves more than just kernel + cmem allocation. Fortunately, the davinci wiki has a great write-up about it here: http://wiki.davincidsp.com/index.php/Changing_the_DVEVM_memory_map Hope this helps, David -- DAVID A. KONDRAD Software Design Engineer Legrand Home Systems Division http://www.legrand.us/onq This email, and any document attached hereto, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Compiling with link arbiter enabled on dvsdk2.0
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 .useLinkArbiter to 'true' is right... but maybe seeing the .cfg script would catch something overriding it - or let us try to reproduce it. Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sriraja Yagneswaran Sent: Thursday, February 25, 2010 3:43 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Compiling with link arbiter enabled on dvsdk2.0 Hello All, I have a codec engine based application that has been built with tools from dvsdk 1.40 (with CE 2.10.02, dsplink 1.50). I'm trying to migrate to dvsdk2.0 and the application does not compile citing undefined references to LAD functions. I have enabled the use of linkarbiter in the app's CE config script as follows for using multiple instances of the application to access the DSP engine. osalGlobal.useLinkArbiter = true; The app compiles if comment out the line enabling the use of linkArbiter, though I'm yet to check if the application runs. Are there any path settings or configuration changes that I'm missing out? Does any library have to be recompiled? Following is an extract of the errors that I observe: /home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `procDelete': Processor_dsplink.c:(.text+0x524): undefined reference to `LAD_releaseDsp' Processor_dsplink.c:(.text+0x558): undefined reference to `LAD_disconnect' /home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `daemon': Processor_dsplink.c:(.text+0xbd4): undefined reference to `LAD_connect' Processor_dsplink.c:(.text+0xc18): undefined reference to `LAD_startupDsp' Thanks and Regards Sriraja http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Building linuxutils for arago kernel (DM365)
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 kernel. [ I think there are issues (due to compatibility breaks in the Linux kernel's dma/cache APIs) with 2.6.34-based kernels - I recall some thread or forum posts mentioning this. Patches are welcome on this mailing list! ] Be sure to update both the kernel and user portions of Linux Utils (both included in the linuxutils product download). At times (I think between LU 2.24 and 2.25), changes in the user/kernel interface change, and you need to be careful to keep them in sync. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Jean-Philippe François Sent: Tuesday, March 23, 2010 2:55 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Building linuxutils for arago kernel (DM365) Hi, I am trying to move to a more recent kernel. The board currently runs a MontaVista 2.6.18 based kernel. The application use codec engine from a montavista based DVSDK. If I understand things correctly, The userspace part of the DVSDK can still be used, but I need to rebuild the kernel interface part, ie the drivers from the linuxutils package. For the dm365, the resulting modules are : cmemk.ko dm365mmap.ko edmak.ko irqk.ko Where can I find patches or a new version of the linuxutils package that would built against an arago based kernel ? Thank you, Jean-Philippe François ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: how Codec_engine call the dsplink
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: http://tiexpressdsp.com/index.php/Codec_Engine_Application_Developers_Guide - I couldn't find an article that describes the internal MSGQ usage under the VISA APIs, but you can get a good feel for what's going on under by studying the trace output when setting CE_DEBUG=3 (http://tiexpressdsp.com/index.php/CE_DEBUG). Here's a [very trimmed] excerpt of trace from a single VIDENC_process() call with CE_DEBUG=3 set. The ARM-side is in red, the DSP side is in green, and I've underlined the lines where Codec Engine internally calls MSGQ_alloc()/put()/get()/free() on the ARM side, as well as MSGQ_get()/put() on the DSP side: @1,454,227us: [+0 T:0x4001f000 S:0x03874944] ti.sdo.ce.video.VIDENC - VIDENC_process Enter (handle=0x44c90, inBufs=0x3874a74, outBufs=0x3874a68, inArgs=0x443c8, outArgs=0x443e0) @1,454,428us: [+5 T:0x4001f000 S:0x038748dc] CV - VISA_allocMsg Allocating message for messageId=0x00026700 @1,458,639us: [+0 T:0x4001f000 S:0x038748e4] CV - VISA_call(visa=0x44c90, msg=0x41169c80): messageId=0x00026700, command=0x0 @1,458,807us: [+0 T:0x4001f000 S:0x038748ac] OC - Comm_put Enter(queue=0x2, msg=0x41169c80) @1,459,039us: [+0 T:0x4001f000 S:0x038748ac] OC - Comm_put return (0) @1,459,221us: [+0 T:0x4001f000 S:0x038748a4] OC - Comm_get Enter(queue=0x10001, msg=0x387495c, timeout=-1) @1,507,703us: [+0 T:0x4001f000 S:0x038748a4] OC - Comm_get MSGQ_get() status=0x8000, return (0) [DSP] @0,511,501tk: [+5 T:0x8b9fb21c S:0x8b9fd1e4] CN - NODE 0x8fa82398(xavsc_ateme#0) call(algHandle=0x8fa82450, msg=0x8fe06c80); messageId=0x00026700 [DSP] @0,512,933tk: [+0 T:0x8b9fb21c S:0x8b9fd14c] ti.sdo.ce.video.VIDENC - VIDENC_process Enter (handle=0x8fa82450, inBufs=0x8b9fd1ec, outBufs=0x8b9fd1f8, inArgs=0x8fe06db8, outArgs=0x8fe06dc8) [DSP] @0,513,035tk: [+5 T:0x8b9fb21c S:0x8b9fd12c] CV - VISA_enter(visa=0x8fa82450): algHandle = 0x8fa82480 [DSP] @0,513,095tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_activate Enter(alg=0x8fa82480) [DSP] @0,513,157tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_activate Exit [DSP] @0,622,199tk: [+5 T:0x8b9fb21c S:0x8b9fd12c] CV - VISA_exit(visa=0x8fa82450): algHandle = 0x8fa82480 [DSP] @0,622,282tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate Enter(alg=0x8fa82480) [DSP] @0,622,371tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate Exit [DSP] @0,622,424tk: [+0 T:0x8b9fb21c S:0x8b9fd14c] ti.sdo.ce.video.VIDENC - VIDENC_process Exit (handle=0x8fa82450, retVal=0x0) [DSP] @0,623,888tk: [+5 T:0x8b9fb21c S:0x8b9fd1e4] CN - NODE returned from call(algHandle=0x8fa82450, msg=0x8fe06c80); messageId=0x00026700 @1,518,966us: [+0 T:0x4001f000 S:0x038748e4] CV - VISA_call Completed: messageId=0x00026700, command=0x0, return(status=0) @1,522,687us: [+5 T:0x4001f000 S:0x038748bc] CV - VISA_freeMsg(0x44c90, 0x41169c80): Freeing message with messageId=0x00026700 @1,522,855us: [+0 T:0x4001f000 S:0x03874944] ti.sdo.ce.video.VIDENC - VIDENC_process Exit (handle=0x44c90, retVal=0x0) Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Tivy, Robert Sent: Wednesday, April 07, 2010 10:39 AM To: liuyue18301; davinci-linux-open-source@linux.davincidsp.com Subject: RE: how Codec_engine call the dsplink From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of liuyue18301 Sent: Tuesday, April 06, 2010 6:56 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: how Codec_engine call the dsplink hello everybody: well in the video_copy demos of the codec_engine i think i call the api of dsplink to implement the communication between arm and dsp. but i can't find out that in the code who can help me it confused me so long time. what is the relationship codec_engine and dsplink and the relationship of calling thank you very much. DSPLink is used internally by Codec Engine. You do not call any DSPLink APIs, which is the whole point of Codec Engine, to insulate the user from the details of the implementation. You just call Codec Engine APIs, as the video_copy demo does, or any of the Codec Engine example apps. DSPLink is used by Codec Engine when there is a remote server configured into the system, so you need to configure a remote server but you don't need to configure the use of DSPLink, since Codec Engine does that for you. If you're just doing a local codec then you won't specify a server and
RE: dm365: problem when aacenc update from version 2.8.0 to 3.5.0
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 create failure by: 1. Enabling trace in Framework Components (http://processors.wiki.ti.com/index.php/Trace_in_Framework_Components) 2. Displaying that trace via CE_DEBUG (http://processors.wiki.ti.com/index.php/CE_DEBUG) You might also dig through the codec data sheets and/or users guide. Sometimes those show what resource requirements the codecs have - you might get lucky and find differences there, too. Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of johnny Sent: Wednesday, June 09, 2010 11:29 PM To: Davinci-linux-open-source Subject: dm365: problem when aacenc update from version 2.8.0 to 3.5.0 Hi all, I'm use dvsdk_2_10_01_18 and update framework_component to 2_25_00_04 and linuxutils to 2_24_03, when I use aac audio codec v2.8.0, everything is ok, but when I update it to v3.5.0, with same paramters to open audio codec, it does not work. that's, Aenc1_create() return NULL,. If anybody has solved or encounterd this problem, please help me. thank you very much. 2010-06-10 johnny ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
