We're using a DM6446 for general purpose signal demodulation. Our application doesn't really fit in the Codec Engine flow. We need to call various DSP functions like equalize, and agc, and so on from our ARM side. We have our own board in hand now, and I'm trying to get the DSP/BIOS Link code up and running on the target. I've tried to run samples as well as my own code and have had trouble. Maybe I've missed something obvious. We're running MVL4.0.1 with DSPLink_1_51 and bios_5_31_08. We were going to move up to MVL5.0 but it meant rewriting some drivers we'd already finished, so we didn't.
When I run the scale sample, it never returns from MSGQ_locate() unless I specify a different timeout that WAIT_FOREVER.
/* in scale.c... the gpp side.
* Locate the DSP's message queue
*/
syncLocateAttrs.timeout = WAIT_NONE;
while ((status == DSP_ENOTFOUND) || (status == DSP_ENOTREADY)) {
status = MSGQ_locate (SampleDspMsgqName, &SampleDspMsgq, &syncLocateAttrs) ;
SCALE_Sleep (100000);
if ((status == DSP_ENOTFOUND) || (status == DSP_ENOTREADY)) {
SCALE_Sleep (100000) ;
}
else if (DSP_FAILED (status)) {
SCALE_1Print ("MSGQ_locate () failed. Status = [0x%x]\n", status) ;
}
}
So my gpp-side app hangs and on my console output, I get the following assertion failure...
root@target:/opt/dsplink/samples/scale/debug# Assertion failed (mpBuf->totalBuffers == mpBuf->freeBuffers). File : ../../POOLS/Davinci/mpbuf.c Line : 380
I've insmoded dsplinkk.ko and cmemk.ko as follows...
insmod dsplinkk.ko
mknod /dev/dsplink c 230 0
insmod cmemk.ko phys_start=0x87400000 phys_end=0x87500000 pools=40x4096
As I've been reading the forums, I thought it might be our memory map. But now I'm not so sure. Our Linux kernel is 112 MB, 0x8000000 up to 0x83FFFFFF, which is smaller than the default kernel. We have 256 MB of RAM on the board. When I cat /proc/iomem and /proc/cmem I get...
root@target:/opt/dsplink/samples/scale/debug# cat /proc/iomem
01c64000-01c645ff : musb_hdrc
01c66800-01c67000 : dm_spi.0
01e10000-01e103ff : mmc.0
01e10000-01e103ff : mmc
04000000-0401ffff : fpga
80000000-873fffff : System RAM
80034000-8028270f : Kernel text
80284000-802fb45f : Kernel data
e1080000-e10847ff : eth0
root@target:/opt/dsplink/samples/scale/debug# cat /proc/cmem
Pool 0: 40 bufs size 4096 (4096 requested)
Pool 0 busy bufs:
Pool 0 free bufs:
id 0: phys addr 0x874ff000
id 1: phys addr 0x874fe000
id 2: phys addr 0x874fd000
id 3: phys addr 0x874fc000
id 4: phys addr 0x874fb000
id 5: phys addr 0x874fa000
id 6: phys addr 0x874f9000
id 7: phys addr 0x874f8000
id 8: phys addr 0x874f7000
id 9: phys addr 0x874f6000
id 10: phys addr 0x874f5000
id 11: phys addr 0x874f4000
id 12: phys addr 0x874f3000
id 13: phys addr 0x874f2000
id 14: phys addr 0x874f1000
id 15: phys addr 0x874f0000
id 16: phys addr 0x874ef000
id 17: phys addr 0x874ee000
id 18: phys addr 0x874ed000
id 19: phys addr 0x874ec000
id 20: phys addr 0x874eb000
id 21: phys addr 0x874ea000
id 22: phys addr 0x874e9000
id 23: phys addr 0x874e8000
id 24: phys addr 0x874e7000
id 25: phys addr 0x874e6000
id 26: phys addr 0x874e5000
id 27: phys addr 0x874e4000
id 28: phys addr 0x874e3000
id 29: phys addr 0x874e2000
id 30: phys addr 0x874e1000
id 31: phys addr 0x874e0000
id 32: phys addr 0x874df000
id 33: phys addr 0x874de000
id 34: phys addr 0x874dd000
id 35: phys addr 0x874dc000
id 36: phys addr 0x874db000
id 37: phys addr 0x874da000
id 38: phys addr 0x874d9000
id 39: phys addr 0x874d8000
Can anyone shed some light on this one for me? i.e. what would cause it to wait forever on MSGQ_locate() ??????? Thanks everybody.
