Re: simple data exchange between ARM and DSP
Am Wed, 6 Feb 2008 13:09:42 +0100 schrieb Robert W. Kuhn: main.c, line 20: fatal error #5: could not open source file std.h #include std.h It is a strange problem: /cygdrive/c/CCStudio_v3.3/dsplink_1_50/dsplink/dsp/src/base/gen $ /opt/ti-tools/c6000/cgtools/bin/cl6x -I=/opt/ti-tools/bios/packages/ti/bios/include/ failure.c failure.c, line 20: fatal error: could not open source file std.h 1 fatal error detected in the compilation of failure.c. Compilation terminated. Compilation failure /cygdrive/c/CCStudio_v3.3/dsplink_1_50/dsplink/dsp/src/base/gen $ /opt/ti-tools/c6000/cgtools/bin/cl6x -I/opt/ti-tools/bios/packages/ti/bios/include/ failure.c failure.c, line 20: fatal error: could not open source file std.h 1 fatal error detected in the compilation of failure.c. Compilation terminated. Compilation failure Has anybody seen that before? I followed the instructions in the UserGuide.pdf Bye - Robert ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: simple data exchange between ARM and DSP
Robert, It appears that you are using mvcyg4.0 on Windows. We have seen issues when attempting to build DSP-side code using TI tools from mvcyg4.0. The TI tools (CGTOOLS) for Windows were not taking in the forward slashes correctly. Have you installed the Linux version or the CCS version of CGTOOLS BIOS in your mvcyg? For DSP-side on a Windows PC, can you try to build using a dos shell instead? Choose Windows-based distribution for DSP-side build when running the dsplinkcfg script, and build DSP-side separately from dos shell. Regards, Mugdha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert W. Kuhn Sent: Thursday, February 07, 2008 2:29 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: simple data exchange between ARM and DSP Am Wed, 6 Feb 2008 13:09:42 +0100 schrieb Robert W. Kuhn: main.c, line 20: fatal error #5: could not open source file std.h #include std.h It is a strange problem: /cygdrive/c/CCStudio_v3.3/dsplink_1_50/dsplink/dsp/src/base/gen $ /opt/ti-tools/c6000/cgtools/bin/cl6x -I=/opt/ti-tools/bios/packages/ti/bios/include/ failure.c failure.c, line 20: fatal error: could not open source file std.h 1 fatal error detected in the compilation of failure.c. Compilation terminated. Compilation failure /cygdrive/c/CCStudio_v3.3/dsplink_1_50/dsplink/dsp/src/base/gen $ /opt/ti-tools/c6000/cgtools/bin/cl6x -I/opt/ti-tools/bios/packages/ti/bios/include/ failure.c failure.c, line 20: fatal error: could not open source file std.h 1 fatal error detected in the compilation of failure.c. Compilation terminated. Compilation failure Has anybody seen that before? I followed the instructions in the UserGuide.pdf Bye - Robert ___ 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
Accessing Processor Registers
Hello all, I want to be able to use both UART2 and CI interface present in the DC4 connector. The way I'm planning to do this is to MUX my devices onto the DC4 connector using a 4pin 2 to 1 MUX. From the DM 6446 datasheet I came to know that there is a register called PINMUX1 in where I'm supposed to toggle bit no. 2 in order to switch between UART2 and CI interfaces. My question is how to access that register in a C code. Is there any header files that provides the mapping of all the processor register to some C data structure. Also do anyone see any potential problem in my above plan of MUXing the lines. Thanks, Preetham.S Send instant messages to your online friends http://uk.messenger.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: simple data exchange between ARM and DSP
Am Thu, 7 Feb 2008 14:39:07 +0530 schrieb Kamoolkar, Mugdha: For DSP-side on a Windows PC, can you try to build using a dos shell instead? Choose Windows-based distribution for DSP-side build when running the dsplinkcfg script, and build DSP-side separately from dos shell. I am just doing it. I installed perl in c:\perl But gmake stop very early: C:\CCStudio_v3.3\dsplink_1_50\dsplink\dsp\src\base\gengmake [GEN ] --- DIRS -- INCLUDE C:\DOKUME~1\rwkuhn\LOKALE~1\Temp\make20682.sh: line 1: C:perl\bin\perl: command not fo gmake: *** [c:\CCStudio_v3.3\dsplink_1_50\dsplink\dsp\\export\\INCLUDE] Error 127 Tschau - Robert -- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: simple data exchange between ARM and DSP
Am Thu, 7 Feb 2008 16:17:27 +0530 schrieb Uppal, Deepali: Can you verify that gmake is in the path? Gmake can be found in the BIOS installation ($bios\xdctools) C:\CCStudio_v3.3\dsplink\dsp\src\base\genecho %PATH% C:\CCStudio_v3.3\c2000\cgtools\bin;C:\CCStudio_v3.3\c2400\cgtools\bin;C:\CCStudio_v3.3\bin;C:\CCStudio_v3.3\cc\bin;C:\CC Studio_v3.3\c6000\cgtools\bin;C:\CCStudio_v3.3\c6000\evm6x\bin;C:\CCStudio_v3.3\c5400\cgtools\bin;C:\CCStudio_v3.3\c5500 \cgtools\bin;C:\CCStudio_v3.3\TMS470\cgtools\bin;C:\CCStudio_v3.3\plugins\bios;C:\CCStudio_v3.3\bios_5_31_02\xdctools; ^^^ It is found: C:\TEMPgmake gmake: *** No targets specified and no makefile found. Stop. Bye - Robert ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: simple data exchange between ARM and DSP
Am Thu, 7 Feb 2008 16:43:10 +0530 schrieb Kamoolkar, Mugdha: Please remove cygwin from the path for dos shell usage, otherwise it interferes with the directory separator. You will notice that backslash is removed in C:perl\bin\perl. Hey, this removed this problem. But it seems it does not find all necessary headers (again)?: gmake release ... [SRC ] === OBJECTS === DEBUG == gmake[1]: Entering directory `C:/CCStudio_v3.3/dsplink/dsp/src/base' [BASE] === OBJECTS === DEBUG == gmake[2]: Entering directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/gen' [GEN ] --- DIRS -- DEBUG -- [GEN ] --- OBJECT DEBUG -- gmake[3]: Entering directory `c:/CCStudio_v3.3/dsplink/dsp/src/base/gen' Compiling failure.c... Das System kann den angegebenen Pfad nicht finden.¹ gmake[3]: *** [failure.c.deb] Error 1 gmake[3]: Leaving directory `c:/CCStudio_v3.3/dsplink/dsp/src/base/gen' gmake[2]: *** [objdeb] Error 512 gmake[2]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/gen' gmake[1]: *** [gen.objdeb] Error 2 gmake[1]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base' gmake: *** [base.objdeb] Error 2 [1] Translation: The system cannot find the specific/given path Any idea? My path: C:\CCStudio_v3.3\dsplink\dsp\srcecho %PATH% C:\CCStudio_v3.3\c2000\cgtools\bin;C:\CCStudio_v3.3\c2400\cgtools\bin;C:\CCStudio_v3.3\bin;C:\CCStudio_v3.3\cc\bin;C:\CC Studio_v3.3\c6000\cgtools\bin;C:\CCStudio_v3.3\c6000\evm6x\bin;C:\CCStudio_v3.3\c5400\cgtools\bin;C:\CCStudio_v3.3\c5500 \cgtools\bin;C:\CCStudio_v3.3\TMS470\cgtools\bin;C:\CCStudio_v3.3\plugins\bios;C:\CCStudio_v3.3\bios_5_31_02\xdctools;C: \Perl\site\bin;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\Gemeinsame Dateien\GTK\2 .0\bin;C:\Programme\Gemeinsame Dateien\AdaptecShared\System;C:\CCStudio_v3.3\cc\bin;c:\CCStudio_v3.3\bios_5_31_07\packag es\ti\bios\rta\vbd\CCS_3.1\bin\ Bye - Robert ___ 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 Targets and Codecs
Please review this thread and see if it answers your question. http://osdir.com/ml/linux.davinci/2006-09/msg00095.html In short, your codec package can just have a 64P library, but you may have to adjust its getlibs() fxn as described at the link above. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Hintze Sent: Thursday, February 07, 2008 8:58 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Compiling Targets and Codecs Hello, I am running with the DM6446 processor and something that I have not yet figured out is the compiling targets when working with the codec engine. What I mean is if I want to have the codec running on the DSP and the executable running on the ARM do I need to produce two different libraries for the codec? It seems the app likes to link with .a470MV. However if I turn off the MVArm9 build target in user.bld this file no longer gets generated. My questions are, can I get the linux side app to link with .a64P? The reason why I only want to generate the .a64P is because I have a lot of cl6x (DSP) only code in my codec, that takes advantage of DSP optimizations and the arm compiler chokes on that when compiling the codec. I noticed in the linux app makefile there is an XDCTARGET that is set to XDCTARGET = gnu.targets.MVArm9. I tried gnu.targets.C64P with no luck. 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
RE: simple data exchange between ARM and DSP
Robert, This time the problem is that the paths in your build environment do not match the actual available ones. This refers to DSP/BIOS CGTOOLS paths. As per the Customizing your build environment section in UserGuide, you need to refer to the make system distribution file: \dsplink\make\DspBios\c64xxp_5.xx_windows.mk BASE_INSTALL:= C:\ti-tools BASE_SABIOS := $(BASE_INSTALL)\bios BASE_CGTOOLS:= $(BASE_INSTALL)\C6000\cgtools Change these as per your actual installation paths. Note, however, that you seem to be using the DSP/BIOS available with CCS 3.3 (DSP/BIOS 5.31.07), but DSPLink 1.50 requires DSP/BIOS 5.32.01 (downloadable at: https://www-a.ti.com/downloads/sds_support/targetcontent/bios/index.html). Regards, Mugdha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert W. Kuhn Sent: Thursday, February 07, 2008 5:41 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: simple data exchange between ARM and DSP Am Thu, 7 Feb 2008 16:43:10 +0530 schrieb Kamoolkar, Mugdha: Please remove cygwin from the path for dos shell usage, otherwise it interferes with the directory separator. You will notice that backslash is removed in C:perl\bin\perl. Hey, this removed this problem. But it seems it does not find all necessary headers (again)?: gmake release ... [SRC ] === OBJECTS === DEBUG == gmake[1]: Entering directory `C:/CCStudio_v3.3/dsplink/dsp/src/base' [BASE] === OBJECTS === DEBUG == gmake[2]: Entering directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/gen' [GEN ] --- DIRS -- DEBUG -- [GEN ] --- OBJECT DEBUG -- gmake[3]: Entering directory `c:/CCStudio_v3.3/dsplink/dsp/src/base/gen' Compiling failure.c... Das System kann den angegebenen Pfad nicht finden.¹ gmake[3]: *** [failure.c.deb] Error 1 gmake[3]: Leaving directory `c:/CCStudio_v3.3/dsplink/dsp/src/base/gen' gmake[2]: *** [objdeb] Error 512 gmake[2]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/gen' gmake[1]: *** [gen.objdeb] Error 2 gmake[1]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base' gmake: *** [base.objdeb] Error 2 [1] Translation: The system cannot find the specific/given path Any idea? My path: C:\CCStudio_v3.3\dsplink\dsp\srcecho %PATH% C:\CCStudio_v3.3\c2000\cgtools\bin;C:\CCStudio_v3.3\c2400\cgtools\bin;C:\CCStudio_v3.3\bin;C:\CCStudio_v3.3\cc\bin;C:\CC Studio_v3.3\c6000\cgtools\bin;C:\CCStudio_v3.3\c6000\evm6x\bin;C:\CCStudio_v3.3\c5400\cgtools\bin;C:\CCStudio_v3.3\c5500 \cgtools\bin;C:\CCStudio_v3.3\TMS470\cgtools\bin;C:\CCStudio_v3.3\plugins\bios;C:\CCStudio_v3.3\bios_5_31_02\xdctools;C: \Perl\site\bin;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\Gemeinsame Dateien\GTK\2 .0\bin;C:\Programme\Gemeinsame Dateien\AdaptecShared\System;C:\CCStudio_v3.3\cc\bin;c:\CCStudio_v3.3\bios_5_31_07\packag es\ti\bios\rta\vbd\CCS_3.1\bin\ Bye - Robert ___ 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: Montavisa git tree
Kevin Hilman wrote: Dirk Behme [EMAIL PROTECTED] writes: Troy Kisky wrote: I'm exploring the montavista git tree and saw that there has been no activity for a few months. Yes, unfortunately, you are right. git kernel is hosted by MV, and maintained by a MV employee, Kevin Hilman. This is the open source git kernel for DaVinci, we all (the community) can, should and have to contribute to if it should be viable. The commercial official product TI/MV still supports is the 2.6.10 (?) TI/MV kernel. One other minor clarification/disclaimer... Please do not call the git tree a Montavista tree. Let's call it the DaVinci git tree. It is indeed hosted by MV (as is the OMAP tree) but that is all. This is a _community_ tree, dependent on the quality of _community_ contributions. Kevin: Yes, I completely agree. This is exactly what I tried to express above with my own words ;) All: To avoid confusion in the future, can we agree on the following wording: - DaVinci git kernel: This is the _community_ kernel as expressed above by Kevin. It is available at http://source.mvista.com/git/?p=linux-davinci-2.6.git;a=summary - TI/MV kernel: This is the outdated 2.6.10 (?) one you get with DVEVM CDs and after registration at http://www.ti.com/dvevmupdates Dirk I have been maintaining it in my spare time, not in any official MV role. As the DaVinci community grows, the maintainer role may need to be revisited as more work is will be required. Until then, lets keep discussions going and keep the patches coming. I just saw that you updated git kernel. MANY THANKS for this! Dirk ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DaVinci git updated to 2.6.24
Kevin Hilman wrote: DaVinci tree has now been updated to 2.6.24, Again, many thanks for this! While this are quite good news, hopefully TI doesn't take this as a things work well without TI, we don't need to do anything. IMHO Triloks comments http://linux.omap.com/pipermail/davinci-linux-open-source/2008-February/005173.html are still valid. but there are several things not yet working in this tree (see below.) The pre-merge tree is tagged as 'pre-2.6.24-merge', if you want to stay with a pre-2.6.24 tree, you can checkout your own development branch at this tag: 'git checkout -b my-dev-branch pre-2.6.24-merge'. This has had minimal testing using attached .config. Known problems (but I'm sure there are others) I will look into some of them in the next days. At least NAND and maybe I2C and Network/NFS. Note that this doesn't exclude that any help is really appreciated! In some discussions the last days we stressed the word _community_. Hint, hint ... ;) - i2c - I added the zero-byte hack (as done in OMAP driver), but still doesn't seem to work Any hint what's the best/easiest test case for this? - EMAC driver cannot get MAC using i2c - workaround: pass eth=MAC addr on kerne cmd line - no audio (since aic33 is via i2c) - needs to be disabled in .config - IDE - seems to hang - there is a new version of this driver which (I believe) has been submitted to linux-ide. This should be merged soon. - NAND - board-evm code doesn't compile due to missing nand_platform_data - Video - V4L2 changes will require a rework of the video drivers - Audio - crashes in i2c accesses if enabled - only has untested/deprecated OSS driver - Network / NFS - does not fully boot my NFS root filesystem. It stops part way through and thinks the NFS server went away. - There were some NAPI related compile fixes after 2.6.24 (Thanks Dirk) that may require investigation/debug. Dirk ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: hotplug subsytem, dm355, and gadget driver
The situation is I have a DM355 with an SD card. I would like the SD card to be mounted for used by Linux most of the time. But, on insertion of a USB cable I want to unmount the card and mount (although it's really a modprobe) the card via g_file_storage. Then, when the cable is unplugged I want to remount it as a linux file system. It seems that hotplug would do that, and there seem to be calls to the hotplug system in the gadget code. I don't remember if I found them in the Iventra driver code or not. I decided at that point to see if anyone had dealt with this already. All I really need is to have some scripts called on USB insert/remove. If you have any ideas about how to do that, I would be really greatful. Chris On Feb 6, 2008 9:44 PM, Nori, Sekhar [EMAIL PROTECTED] wrote: Chris, Hotplug in USB comes into picture in host mode, when a device plugs into it. Why do you want to trap the cable insertion event? Thanks, Sekhar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Stillson Sent: Tuesday, February 05, 2008 5:43 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: hotplug subsytem, dm355, and gadget driver I'm trying to determine when the USB cable is inserted, which would seem to be from the hotplug subsystem, but this doesn't work for me. The hotplug system (which works for the sd card) doesn't seem to trigger from USB. I have a system the successfully runs g_file_storage. I'm pretty sure I have everything set up normally. Should the hotplug system work this way? If not, are there any alternatives? Chris ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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 0/2] ARM: DAVINCI: fix TI previewer driver
Vasiliy Titskiy [EMAIL PROTECTED] writes: These patches fix 2 bugs in TI Previewer driver. First patch makes all declarations of C-structures in file davinci_previewer.h independent of used compiler options. Old (non-patched) version has different aligment requirements for some structures in user-mode and kernel-mode. As result, some (not all) records of that structures has different offset in user- and kernel- modes. Second patch fixes incorrect access to user-mode memory in ioctl() function. Old version crashed our system very fast on high load. Vasiliy, First, thanks for contributing your fixes to the list. In the future, please be sure to specify which kernel these patches apply to. Patches to this list are generally for the DaVinci git kernel. If they are not against git, but still may be of use to others (like your patches are), please be sure to say that in the description. Second, your patches are not usable in the form they have been sent. They were not properly generated, and your mailer seems to have also done line wrapping which makes them not usable for others. The file Documentation/SubmittingPatches in the linux kernel sources gives good guidance on how to submit patches. Thanks, Kevin ___ 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 Targets and Codecs
Thanks Chris this worked great. I have another quick question. How can I change the cl6x compiler switches that are defaulted in the Codec Engine when using package.bld. For example I want to add a couple like: -pm -op2 and change -o2 to -o3. Thanks, Josh From: Ring, Chris [mailto:[EMAIL PROTECTED] Sent: Thursday, February 07, 2008 12:20 PM To: Joshua Hintze; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Compiling Targets and Codecs Please review this thread and see if it answers your question. http://osdir.com/ml/linux.davinci/2006-09/msg00095.html In short, your codec package can just have a 64P library, but you may have to adjust its getlibs() fxn as described at the link above. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Hintze Sent: Thursday, February 07, 2008 8:58 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Compiling Targets and Codecs Hello, I am running with the DM6446 processor and something that I have not yet figured out is the compiling targets when working with the codec engine. What I mean is if I want to have the codec running on the DSP and the executable running on the ARM do I need to produce two different libraries for the codec? It seems the app likes to link with .a470MV. However if I turn off the MVArm9 build target in user.bld this file no longer gets generated. My questions are, can I get the linux side app to link with .a64P? The reason why I only want to generate the .a64P is because I have a lot of cl6x (DSP) only code in my codec, that takes advantage of DSP optimizations and the arm compiler chokes on that when compiling the codec. I noticed in the linux app makefile there is an XDCTARGET that is set to XDCTARGET = gnu.targets.MVArm9. I tried gnu.targets.C64P with no luck. 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
Compiling Targets and Codecs
Hello, I am running with the DM6446 processor and something that I have not yet figured out is the compiling targets when working with the codec engine. What I mean is if I want to have the codec running on the DSP and the executable running on the ARM do I need to produce two different libraries for the codec? It seems the app likes to link with .a470MV. However if I turn off the MVArm9 build target in user.bld this file no longer gets generated. My questions are, can I get the linux side app to link with .a64P? The reason why I only want to generate the .a64P is because I have a lot of cl6x (DSP) only code in my codec, that takes advantage of DSP optimizations and the arm compiler chokes on that when compiling the codec. I noticed in the linux app makefile there is an XDCTARGET that is set to XDCTARGET = gnu.targets.MVArm9. I tried gnu.targets.C64P with no luck. 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
Re: [PATCH 0/1 v1] ARM: DAVINCI: Power management support
Dirk Behme [EMAIL PROTECTED] writes: Add basic power management support for DaVinci. Dirk, These patches didn't apply for me to the HEAD of DaVinci git before I did the 2.6.24 merge. Do you mind re-working/resubmitting for the current tree? Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
toggle GPIO port pin
Hi, I tried to toggle the bit on 6 GPIO ports given on DM355 EVM board. I tried using mmap and the base address given was0x01C67000. I tried to toggleGPIO64 pin. DIR45 offset is 60h. OUT_DATA45 is 64h. I have made DIR45 = 0x00; configuring all the ports in bank 4 and 5 to output ports. and then OUT_DATA45=0x01 making 0th bit high which is GPIO64. I also tried SET_DATA45 =0x01; Ihave kept an LED ontthat port and triedbut it was not working. Any body helpme please. thanks regds Gopi K Meet people who discuss and share your passions. Join them now. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
How to control memory space used for instance creation?
Hi, We have come across instances when application integrator would like to control memory-space used for instance creation of an Algorithm. I am looking for ways application can achieve this in codec engine. For example let us assume that in a system two algorithms A1 and A2 are there and both ask for internal memories (via algAlloc()) and the total internal memory available on chip is not sufficient. A1 uses DMA so can't work from external memory whereas A2 can work from external but will have performance hit. In this case app would like to create A2 from external memory although it is asking for internal (via algAlloc). If A1 is created before A2, is it guaranteed that A1 gets memory from internal and A2 is created from external? If not then what are the better ways? Best Regards, Kumar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 08, 2008 3:40 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Davinci-linux-open-source Digest, Vol 26, Issue 18 Send Davinci-linux-open-source mailing list submissions to davinci-linux-open-source@linux.davincidsp.com To subscribe or unsubscribe via the World Wide Web, visit http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Davinci-linux-open-source digest... Today's Topics: 1. RE: Compiling Targets and Codecs (Ring, Chris) 2. Re: hotplug subsytem, dm355, and gadget driver (Christopher Stillson) 3. RE: Compiling Targets and Codecs (Joshua Hintze) -- Message: 1 Date: Thu, 7 Feb 2008 13:20:18 -0600 From: Ring, Chris [EMAIL PROTECTED] Subject: RE: Compiling Targets and Codecs To: Joshua Hintze [EMAIL PROTECTED], davinci-linux-open-source@linux.davincidsp.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Please review this thread and see if it answers your question. http://osdir.com/ml/linux.davinci/2006-09/msg00095.html In short, your codec package can just have a 64P library, but you may have to adjust its getlibs() fxn as described at the link above. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Hintze Sent: Thursday, February 07, 2008 8:58 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Compiling Targets and Codecs Hello, I am running with the DM6446 processor and something that I have not yet figured out is the compiling targets when working with the codec engine. What I mean is if I want to have the codec running on the DSP and the executable running on the ARM do I need to produce two different libraries for the codec? It seems the app likes to link with .a470MV. However if I turn off the MVArm9 build target in user.bld this file no longer gets generated. My questions are, can I get the linux side app to link with .a64P? The reason why I only want to generate the .a64P is because I have a lot of cl6x (DSP) only code in my codec, that takes advantage of DSP optimizations and the arm compiler chokes on that when compiling the codec. I noticed in the linux app makefile there is an XDCTARGET that is set to XDCTARGET = gnu.targets.MVArm9. I tried gnu.targets.C64P with no luck. Thanks, Josh -- next part -- An HTML attachment was scrubbed... URL: http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20 080207/4236ac05/attachment-0001.htm -- Message: 2 Date: Thu, 7 Feb 2008 13:01:28 -0800 From: Christopher Stillson [EMAIL PROTECTED] Subject: Re: hotplug subsytem, dm355, and gadget driver To: Nori, Sekhar [EMAIL PROTECTED] Cc: davinci-linux-open-source@linux.davincidsp.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 The situation is I have a DM355 with an SD card. I would like the SD card to be mounted for used by Linux most of the time. But, on insertion of a USB cable I want to unmount the card and mount (although it's really a modprobe) the card via g_file_storage. Then, when the cable is unplugged I want to remount it as a linux file system. It seems that hotplug would do that, and there seem to be calls to the hotplug system in the gadget code. I don't remember if I found them in the Iventra driver code or not. I decided at that point to see if anyone had dealt with this already. All I really need is to have some scripts called on USB insert/remove. If you have
Re: simple data exchange between ARM and DSP
Am Thu, 7 Feb 2008 23:06:50 +0530 schrieb Kamoolkar, Mugdha: file: \dsplink\make\DspBios\c64xxp_5.xx_windows.mk BASE_INSTALL:= C:\ti-tools BASE_SABIOS := $(BASE_INSTALL)\bios BASE_CGTOOLS:= $(BASE_INSTALL)\C6000\cgtools Finally it works!: ... gmake[2]: Nothing to be done for `exprel'. gmake[2]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/hal' gmake[2]: Entering directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/drv' [DRV ] --- EXPORT RELEASE gmake[2]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/drv' gmake[1]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base' :-)) Thank you! It is right that I have to compile the gpp-src in the cygwin enviroment (this actually works!)? When I try it in the same enviroment as the dsp I get the following error: C:\CCStudio_v3.3\dsplink\gpp\srcgmake process_begin: CreateProcess((null), /usr/bin\perl C:\CCStudio_v3.3\dsplink\make\bin\banner.pl 1 SRC DIRS INCLUDE, ...) failed. make (e=3): System cannot find specific path gmake: *** [b_dirinc] Error 3 I guess I will have a windows-enviroment for the dsp-side and a second directory with a cygwin-enviroment for the gpp-side... Bye - Robert ___ 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 control memory space used for instance creation?
This feature was added in Codec Engine 2.00. When creating the algorithm, an optional argument string can be appended to the _name_ of the alg. In CE 2.00, the name can be up to 3 parts separated by a colon ':'. The syntax is name:priority:flag. The API Reference Guide describes this in a bit of detail (e.g., look at the Remarks section of AUDDEC1_create() here: https://www-a.ti.com/downloads/sds_support/targetcontent/CE/ce_2_00/code c_engine_2_00/docs/html/group__ti__sdo__ce__audio1___a_u_d_d_e_c1.html#g ea018c45115cbd0a8770533652d64605) In short, to create an xDM 1.0 audio decoder with all its memory in external, you create it like this: hAudDec = AUDDEC1_create(hEngine, codecname::1, NULL); Hope that helps! Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Kumar Brajbhushan Sent: Thursday, February 07, 2008 9:53 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: How to control memory space used for instance creation? Hi, We have come across instances when application integrator would like to control memory-space used for instance creation of an Algorithm. I am looking for ways application can achieve this in codec engine. For example let us assume that in a system two algorithms A1 and A2 are there and both ask for internal memories (via algAlloc()) and the total internal memory available on chip is not sufficient. A1 uses DMA so can't work from external memory whereas A2 can work from external but will have performance hit. In this case app would like to create A2 from external memory although it is asking for internal (via algAlloc). If A1 is created before A2, is it guaranteed that A1 gets memory from internal and A2 is created from external? If not then what are the better ways? Best Regards, Kumar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: simple data exchange between ARM and DSP
Robert, Yes, that's right, you have to use msdos for DSP-side and cygwin for GPP-side. You actually saw all these issues only because you're attempting to build on Windows PC. If you use a Linux box for your build, you can directly use Linux-based tools to build both GPP and DSP-side in the same manner, and there are far fewer hassles involved. To summarize for the archive: If you are building on a Windows PC: - Use mvcyg4.0 shell to build GPP-side. - To build DSP-side, use a dos shell. Ensure that cygwin is removed from your path. - Follow the steps in UserGuide to customize your build environment (specifically modifying distribution files to customize them for your install paths). Regards, Mugdha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert W. Kuhn Sent: Friday, February 08, 2008 12:44 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: simple data exchange between ARM and DSP Am Thu, 7 Feb 2008 23:06:50 +0530 schrieb Kamoolkar, Mugdha: file: \dsplink\make\DspBios\c64xxp_5.xx_windows.mk BASE_INSTALL:= C:\ti-tools BASE_SABIOS := $(BASE_INSTALL)\bios BASE_CGTOOLS:= $(BASE_INSTALL)\C6000\cgtools Finally it works!: ... gmake[2]: Nothing to be done for `exprel'. gmake[2]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/hal' gmake[2]: Entering directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/drv' [DRV ] --- EXPORT RELEASE gmake[2]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base/drv' gmake[1]: Leaving directory `C:/CCStudio_v3.3/dsplink/dsp/src/base' :-)) Thank you! It is right that I have to compile the gpp-src in the cygwin enviroment (this actually works!)? When I try it in the same enviroment as the dsp I get the following error: C:\CCStudio_v3.3\dsplink\gpp\srcgmake process_begin: CreateProcess((null), /usr/bin\perl C:\CCStudio_v3.3\dsplink\make\bin\banner.pl 1 SRC DIRS INCLUDE, ...) failed. make (e=3): System cannot find specific path gmake: *** [b_dirinc] Error 3 I guess I will have a windows-enviroment for the dsp-side and a second directory with a cygwin-enviroment for the gpp-side... Bye - Robert ___ 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
