Mat, We have verified DSPLink with 2.6.18+ versions (notably 2.6.22 and 2.6.23, and later even latest GIT versions). There is no issue of the sort that you have mentioned below. The folder says 2.6.18 because there's no difference as far as DSPLink is concerned between 2.6.18 and later versions that we have tested with. So this (2.6.18) actually means 2.6.18+.
DSPLink requires some shared memory which is removed from Linux address space using appropriate mem= parameter in bootargs. In default configuration, it's 2MB. You can look here for more details: http://tiexpressdsp.com/index.php?title=Changing_the_DVEVM_memory_map Regards, Mugdha ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Mat Laibowitz Sent: Monday, April 13, 2009 4:20 AM To: [email protected] Subject: Re: moved on to a kernel cmem problem Changing the mutex functions to rt_mutex functions did not help, neither did include mutex.h. I also tried following the instructions on the wiki here: http://tiexpressdsp.com/index.php?title=Building_DSPLink_with_kbuild and this will successfully build the dsplink, but it still exits with a kernel error on mutex_lock. -mat On Sun, Apr 12, 2009 at 4:32 PM, Mat Laibowitz <[email protected]<mailto:[email protected]>> wrote: After trying to play around with the memory map some more, I did a little more digging. It seems that the function that fails, according to the oops, is SYNC_SpinLockStartEx, which is in the dsplink source file sync.c located in gpp/src/osal/Linux/2.6.18.<http://2.6.18.> Considering that the folder is called 2.6.18, there might be a kernel version problem with my 2.6.22 kernel. Within the SYNC_SpinLockStartEx function, the specific call that fails is mutex_lock_interruptible. The sync.c file includes rtmutex.h from the kernel includes. The actual function call for mutex_lock_interruptible that is in rtmutex.h is rt_mutex_lock_interruptible. The call mutex_lock_interruptible is not actual in rtmutex.h and it is in mutex.h which as far as I can tell is not included in sync.c. Dsplink version 1.4 does not use mutexes in its sync.c file. I think it turns on and off irqs to protect critical sections. I am going to try to change all the calls in sync.c to rt_ and recompile and see if it works. -mat On Sun, Apr 12, 2009 at 3:14 PM, Mat Laibowitz <[email protected]<mailto:[email protected]>> wrote: Thanks for the replies. I am using kernel 2.6.22 and dsplink 1.60. Maybe your findings could help even if these are different versions. >From what you guys are saying, it seems that the app is looking for dsplink >and not finding it? When you change the bootarg to mem=118M do you also change the cmem location or do you leave a gap between the linux section and the cmem section? Does this effect the dsplink somehow? Also, if I am using NSF and the root directory on the nsf partition contains more than 120M worth of files, will this cause a problem? Thanks again, -mat On Sun, Apr 12, 2009 at 8:48 AM, Steve Chen <[email protected]<mailto:[email protected]>> wrote: On Sun, 2009-04-12 at 10:08 +0300, Yusuf Caglar AKYUZ wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mat Laibowitz wrote: > > In order to debug my mpeg4dec app side program I was looking dmai to see how > > it accessed the viddec2 ce interface. > > > > Along the way I decided to try and compile it and also to try and upgrade > > some components. > > I modified the dmai source to support my custom board and can compile it. > > > > Now I am having a run-time issue with the codec engine. > > I am just trying to run the decode demo. > > I get the error: > > Unable to handle kernel paging request at virtual address c808b000 > > > > There is a lot of talk about this error, and I have read through the > > postings, but still have not figured it out. > > If I change the CMEM insert command, I can get it to say: > > CMEMK Error: CMEM phys_start (0x87600000) overlaps kernel (0x80000000 -> > > 0x87800000) > > [...] > > Looking at the kernel oops, this is dsplink problem rather than > cmem. Which kernel version are you using? and is this dsplink > version 1.40? I faced a similar issues with 2.6.28 recently. If we > are using the same software versions, I can summarize my findings. > > Regards, > Caglar I also saw similar crash issue with 2.6.18 (MV pro 5 kernel). Chaning MEM=120M to MEM=118M on the kernel command line fixed the problem for me. Regards, Steve > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iEYEARECAAYFAknhk3UACgkQ/nL+S5dojeiE2wCfc7pxnMMdXS8xciSfGAvxfMH/ > dTkAnRgmpnQLfvNY11i6tct70PfBeKdM > =ey7g > -----END PGP SIGNATURE----- > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected]<mailto:[email protected]> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
