Speex encoder running on DSP through DSP Gateway

Speex encoder running on DSP through DSP Gateway

[Eduardo Bezerra]

Hi all,


  I know that the issue below is related more to the DSP-GW community as
opposed to Linux-OMAP and I do apologise for posting it here, but DSP-GW
list seems to be populated sparringly and responses are really slow or
long term. I would therefore appreciate if someone has already seen this
issue and could give me a hint or two.

  I'm trying to run a speex encoder on the OSK 5912 DSP using
DSP Gateway.  This enconder is based on the speex library
that can be found in www.speex.org.

  The whole code to produce a single encoder using this library
plus the tokliBIOS library code resulted in a binary with
200KB of size. A simple frame coding step also requires
a stack size of 4K words. It also does about 12K words
of allocation (using malloc). These memory requirements
were analysed using valgrind tools.

  Because of these memory requirements, the DSP task needed some shared
memory. So, I added one memory space to put some data. The .cmd
of the DSP Task is:

/*
 * Data sections
 * */

-l tokliBIOScfg.cmd
-l tokliBIOS.cmd

MEMORY {
        PAGE 0: SARAM_D:     origin = 0x30000, len = 0x5000
}
SECTIONS {
        shared_data:    {} > SARAM_D PAGE 0
}

  However, as the application also needs more memory to
stack and heap, I also modified the tokliBIOScfg.tcf:

.
.
.

var myHeap = bios.MEM.create("MYHEAP");
myHeap.comment = "Speex Heap";
myHeap.base = 0x1a800;
myHeap.len = 0x8000;
myHeap.createHeap = true;
myHeap.space = "data";
myHeap.heapSize = 0x4000;

bios.MEM.MALLOCSEG = prog.get("MYHEAP");
bios.MEM.BIOSOBJSEG = prog.get("DARAM");
bios.MEM.STACKSEG = prog.get("MYHEAP");
bios.MEM.SYSSTACKSEG = prog.get("MYHEAP");

.
.
.
/*
 * TSK
 */
bios.TSK.ENABLETSK = true;
bios.TSK.STACKSEG = prog.get("MYHEAP");

  I did a static compilation of this task and it was fine. Before the
loading of the resulted binary, I executed the following commands on the
OSK board:

# dspctl kmem_reserve 0x20000

As in the .cmd file, it needs a TLB entry pointing to 0x30000, size
0x5000
# dspctl exmap 0x30000 0x5000

As in the .tcf file, it needs a TLB entry pointing to 0x35000, size
0x10000
# dspctl exmap 0x35000 0x10000


  So, I did the loading:

# dspctl start speex.out


  The loading was fine also. But when I run a user space program to
communicate to the DSP task through the DSP gateway device file, it
gets an error. The user space program only sends a ipbuffer a requests
another one. It sends and receives the ipbuffer without any problem.
And the user space application ends. The data produced by the encoder is
correct. The problem is that the kernel prints out a message indicating
that there is a mailbox message from a non-existing DSP task. After
that, the DSP task hangs out. The message error code is: BADTID.

  Any suggestion?

BR,

Eduardo Bezerra Valentin

Re: Speex encoder running on DSP through DSP Gateway

[toshihiro.kobayashi]

Hi,

From: Eduardo Bezerra <edubezval@gmail.com>
Subject: Speex encoder running on DSP through DSP Gateway
Date: Wed, 11 Jan 2006 11:18:39 -0400

>   I know that the issue below is related more to the DSP-GW community as
> opposed to Linux-OMAP and I do apologise for posting it here, but DSP-GW
> list seems to be populated sparringly and responses are really slow or
> long term.

However, eventually I'm answering in any ways. :)
I've been on the business trip followed by the vacation.
Sorry for slow replies.

>   I'm trying to run a speex encoder on the OSK 5912 DSP using
> DSP Gateway.  This enconder is based on the speex library
> that can be found in www.speex.org.
> 
>   The whole code to produce a single encoder using this library
> plus the tokliBIOS library code resulted in a binary with
> 200KB of size. A simple frame coding step also requires
> a stack size of 4K words. It also does about 12K words
> of allocation (using malloc). These memory requirements
> were analysed using valgrind tools.
> 
>   Because of these memory requirements, the DSP task needed some shared
> memory. So, I added one memory space to put some data. The .cmd
> of the DSP Task is:
> 
> /*
>  * Data sections
>  * */
> 
> -l tokliBIOScfg.cmd
> -l tokliBIOS.cmd
> 
> MEMORY {
>         PAGE 0: SARAM_D:     origin = 0x30000, len = 0x5000
> }
> SECTIONS {
>         shared_data:    {} > SARAM_D PAGE 0
> }
> 
>   However, as the application also needs more memory to
> stack and heap, I also modified the tokliBIOScfg.tcf:
> 
> .
> .
> .
> 
> var myHeap = bios.MEM.create("MYHEAP");
> myHeap.comment = "Speex Heap";
> myHeap.base = 0x1a800;
> myHeap.len = 0x8000;
> myHeap.createHeap = true;
> myHeap.space = "data";
> myHeap.heapSize = 0x4000;
> 
> bios.MEM.MALLOCSEG = prog.get("MYHEAP");
> bios.MEM.BIOSOBJSEG = prog.get("DARAM");
> bios.MEM.STACKSEG = prog.get("MYHEAP");
> bios.MEM.SYSSTACKSEG = prog.get("MYHEAP");
> 
> .
> .
> .
> /*
>  * TSK
>  */
> bios.TSK.ENABLETSK = true;
> bios.TSK.STACKSEG = prog.get("MYHEAP");
> 
>   I did a static compilation of this task and it was fine. Before the
> loading of the resulted binary, I executed the following commands on the
> OSK board:
> 
> # dspctl kmem_reserve 0x20000
> 
> As in the .cmd file, it needs a TLB entry pointing to 0x30000, size
> 0x5000
> # dspctl exmap 0x30000 0x5000
> 
> As in the .tcf file, it needs a TLB entry pointing to 0x35000, size
> 0x10000
> # dspctl exmap 0x35000 0x10000
> 
> 
>   So, I did the loading:
> 
> # dspctl start speex.out
> 
> 
>   The loading was fine also. But when I run a user space program to
> communicate to the DSP task through the DSP gateway device file, it
> gets an error. The user space program only sends a ipbuffer a requests
> another one. It sends and receives the ipbuffer without any problem.
> And the user space application ends. The data produced by the encoder is
> correct. The problem is that the kernel prints out a message indicating
> that there is a mailbox message from a non-existing DSP task. After
> that, the DSP task hangs out. The message error code is: BADTID.

Can you show me how you use bksnd() in your DSP task?
Because the TID used in the mailbox command is extracted from the "task"
argument passed with the bksnd().
Also the dump list of /sys/devices/platform/dsp/mblog may be some help.

BR,
Toshihiro Kobayashi

Re: Speex encoder running on DSP through DSP Gateway

[Eduardo Bezerra]

Hi,


2006/1/13, toshihiro.kobayashi@nokia.com <toshihiro.kobayashi@nokia.com>:
> Hi,
>
> From: Eduardo Bezerra <edubezval@gmail.com>
> Subject: Speex encoder running on DSP through DSP Gateway
> Date: Wed, 11 Jan 2006 11:18:39 -0400
>
> >   I know that the issue below is related more to the DSP-GW community as
> > opposed to Linux-OMAP and I do apologise for posting it here, but DSP-GW
> > list seems to be populated sparringly and responses are really slow or
> > long term.
>
> However, eventually I'm answering in any ways. :)
> I've been on the business trip followed by the vacation.
> Sorry for slow replies.
>
> >   I'm trying to run a speex encoder on the OSK 5912 DSP using
> > DSP Gateway.  This enconder is based on the speex library
> > that can be found in www.speex.org.
> >
> >   The whole code to produce a single encoder using this library
> > plus the tokliBIOS library code resulted in a binary with
> > 200KB of size. A simple frame coding step also requires
> > a stack size of 4K words. It also does about 12K words
> > of allocation (using malloc). These memory requirements
> > were analysed using valgrind tools.
> >
> >   Because of these memory requirements, the DSP task needed some shared
> > memory. So, I added one memory space to put some data. The .cmd
> > of the DSP Task is:
> >
> > /*
> >  * Data sections
> >  * */
> >
> > -l tokliBIOScfg.cmd
> > -l tokliBIOS.cmd
> >
> > MEMORY {
> >         PAGE 0: SARAM_D:     origin = 0x30000, len = 0x5000
> > }
> > SECTIONS {
> >         shared_data:    {} > SARAM_D PAGE 0
> > }
> >
> >   However, as the application also needs more memory to
> > stack and heap, I also modified the tokliBIOScfg.tcf:
> >
> > .
> > .
> > .
> >
> > var myHeap = bios.MEM.create("MYHEAP");
> > myHeap.comment = "Speex Heap";
> > myHeap.base = 0x1a800;
> > myHeap.len = 0x8000;
> > myHeap.createHeap = true;
> > myHeap.space = "data";
> > myHeap.heapSize = 0x4000;
> >
> > bios.MEM.MALLOCSEG = prog.get("MYHEAP");
> > bios.MEM.BIOSOBJSEG = prog.get("DARAM");
> > bios.MEM.STACKSEG = prog.get("MYHEAP");
> > bios.MEM.SYSSTACKSEG = prog.get("MYHEAP");
> >
> > .
> > .
> > .
> > /*
> >  * TSK
> >  */
> > bios.TSK.ENABLETSK = true;
> > bios.TSK.STACKSEG = prog.get("MYHEAP");
> >
> >   I did a static compilation of this task and it was fine. Before the
> > loading of the resulted binary, I executed the following commands on the
> > OSK board:
> >
> > # dspctl kmem_reserve 0x20000
> >
> > As in the .cmd file, it needs a TLB entry pointing to 0x30000, size
> > 0x5000
> > # dspctl exmap 0x30000 0x5000
> >
> > As in the .tcf file, it needs a TLB entry pointing to 0x35000, size
> > 0x10000
> > # dspctl exmap 0x35000 0x10000
> >
> >
> >   So, I did the loading:
> >
> > # dspctl start speex.out
> >
> >
> >   The loading was fine also. But when I run a user space program to
> > communicate to the DSP task through the DSP gateway device file, it
> > gets an error. The user space program only sends a ipbuffer a requests
> > another one. It sends and receives the ipbuffer without any problem.
> > And the user space application ends. The data produced by the encoder is
> > correct. The problem is that the kernel prints out a message indicating
> > that there is a mailbox message from a non-existing DSP task. After
> > that, the DSP task hangs out. The message error code is: BADTID.
>
> Can you show me how you use bksnd() in your DSP task?

Ok. Here is it (just a piece of the tk_rcv_bkreq(), the function that
I point to in rcv_req field of my dsptast  struct):
/* Sending data in blocks */
static Uns tk_rcv_bkreq(struct dsptask *task, Uns cnt)
.
.
.
	bid = get_free_ipbuf(task);
	if (bid == MBCMD_BID_NULL)
		return MBCMD_EID_STVBUF;
	
	dbg(task, "11. preparing the buf\n");
	ipbuf_d[bid][0] = nbBytes;

	memcpy(ipbuf_d[bid]+1, cbits, nbBytes);
	dbg(task, "12. sending data: %d words\n", nbBytes);
	
	bksnd(task, bid, cnt);

	dbg(task, "13. releasing\n");

	speex_encoder_destroy(enc);
	speex_bits_destroy(&bits);

	dbg(task, "14. done\n");
        return 0;
}

    Is there any problem in using dbg after sending the block (after
the bksnd call)?

> Because the TID used in the mailbox command is extracted from the "task"
> argument passed with the bksnd().
> Also the dump list of /sys/devices/platform/dsp/mblog may be some help.

here is my mblog, after the user space applications ends:
log count:35 / ARM->DSP:10, DSP->ARM:25
          ARM -> DSP   ARM <- DSP
jiffies  q cmd  data q cmd  data
ffff9fcb 0 7000 0000             DSPCFG:REQ
ffff9fcb             0 7070 0019 DSPCFG:PROTREV
ffff9fcb             1 f028 007f DSPCFG:SYSADRH
ffff9fcb             0 70a9 fe88 DSPCFG:SYSADRL
ffff9fcd             1 a300 0003 BKYLD
ffff9fcd             0 2300 0004 BKYLD
ffff9fcd             1 a300 0005 BKYLD
ffff9fce 0 6000 0000             TCFG:task 0
ffff9fcf             0 6000 0000 TCFG:task 0
ffff9fd8 1 b000 0000             TCTL:task 0
ffff9fd9 0 7500 ffff             SETVAR:ICRMASK
ffff9fd9             1 f900 0020 DBG
ffffa05b 1 d200 0002             PM:DISABLE
ffffe653 0 3000 8101             TCTL:task 0
ffffe653 1 d201 0002             PM:ENABLE
ffffe653 0 2000 0003             BKSND:task 0
ffffe653             0 7900 0027 DBG
ffffe655             1 f900 0014 DBG
ffffe655 1 a100 0065             BKREQ:task 0
ffffe656             0 7900 0017 DBG
ffffe657             1 f900 0010 DBG
ffffe65a             0 7900 0013 DBG
ffffe65b             1 f900 0016 DBG
ffffe65d             0 7900 0012 DBG
ffffe65e             1 f900 0012 DBG
ffffe663             0 7900 0018 DBG
ffffe664             1 f900 0015 DBG
ffffe665             0 7900 0015 DBG
ffffe665             1 f900 0016 DBG
ffffe666             0 7900 001b DBG
ffffe667             1 a000 0000 BKSND:task 0
ffffe667             0 7900 000e DBG
ffffe668             1 f900 0009 DBG
ffffe668             0 7810 0000 ERR:BADTID
ffffe6d5 0 5200 0002             PM:DISABLE



>
> BR,
> Toshihiro Kobayashi
>

BR,
--
Eduardo Bezerra Valentin

RE: Speex encoder running on DSP through DSP Gateway

[Toshihiro.Kobayashi]

Hi,

>From: ext Eduardo Bezerra [mailto:edubezval@gmail.com] 
>Sent: Saturday, January 14, 2006 5:26 AM

>> Can you show me how you use bksnd() in your DSP task?
>
>Ok. Here is it (just a piece of the tk_rcv_bkreq(), the function that
>I point to in rcv_req field of my dsptast  struct):
>/* Sending data in blocks */
>static Uns tk_rcv_bkreq(struct dsptask *task, Uns cnt)
>.
>.
>.
>	bid = get_free_ipbuf(task);
>	if (bid == MBCMD_BID_NULL)
>		return MBCMD_EID_STVBUF;
>	
>	dbg(task, "11. preparing the buf\n");
>	ipbuf_d[bid][0] = nbBytes;
>
>	memcpy(ipbuf_d[bid]+1, cbits, nbBytes);
>	dbg(task, "12. sending data: %d words\n", nbBytes);
>	
>	bksnd(task, bid, cnt);
>
>	dbg(task, "13. releasing\n");
>
>	speex_encoder_destroy(enc);
>	speex_bits_destroy(&bits);
>
>	dbg(task, "14. done\n");
>        return 0;
>}
>
>    Is there any problem in using dbg after sending the block (after
>the bksnd call)?

No, it's OK at all.

>> Also the dump list of /sys/devices/platform/dsp/mblog may be some
help.
>
>here is my mblog, after the user space applications ends:
>log count:35 / ARM->DSP:10, DSP->ARM:25
>          ARM -> DSP   ARM <- DSP
>jiffies  q cmd  data q cmd  data
>ffff9fcb 0 7000 0000             DSPCFG:REQ
>ffff9fcb             0 7070 0019 DSPCFG:PROTREV
>ffff9fcb             1 f028 007f DSPCFG:SYSADRH
>ffff9fcb             0 70a9 fe88 DSPCFG:SYSADRL
>ffff9fcd             1 a300 0003 BKYLD
>ffff9fcd             0 2300 0004 BKYLD
>ffff9fcd             1 a300 0005 BKYLD
>ffff9fce 0 6000 0000             TCFG:task 0
>ffff9fcf             0 6000 0000 TCFG:task 0
>ffff9fd8 1 b000 0000             TCTL:task 0
>ffff9fd9 0 7500 ffff             SETVAR:ICRMASK
>ffff9fd9             1 f900 0020 DBG
>ffffa05b 1 d200 0002             PM:DISABLE
>ffffe653 0 3000 8101             TCTL:task 0
>ffffe653 1 d201 0002             PM:ENABLE
>ffffe653 0 2000 0003             BKSND:task 0
>ffffe653             0 7900 0027 DBG
>ffffe655             1 f900 0014 DBG
>ffffe655 1 a100 0065             BKREQ:task 0
>ffffe656             0 7900 0017 DBG
>ffffe657             1 f900 0010 DBG
>ffffe65a             0 7900 0013 DBG
>ffffe65b             1 f900 0016 DBG
>ffffe65d             0 7900 0012 DBG
>ffffe65e             1 f900 0012 DBG
>ffffe663             0 7900 0018 DBG
>ffffe664             1 f900 0015 DBG
>ffffe665             0 7900 0015 DBG
>ffffe665             1 f900 0016 DBG
>ffffe666             0 7900 001b DBG
>ffffe667             1 a000 0000 BKSND:task 0
>ffffe667             0 7900 000e DBG
>ffffe668             1 f900 0009 DBG
>ffffe668             0 7810 0000 ERR:BADTID
>ffffe6d5 0 5200 0002             PM:DISABLE

And this looks fine too, except for the BADTID error...

Unfortunately I have no idea at the moment.
Could you find out which routine in tokliBIOS returns
BADTID error, by replacing MBCMD_EID_BADTID with other values?

for example,

-------------------------------------------------
diff -urN 1/supertask.c 2/supertask.c
--- 1/supertask.c	2006-01-16 22:52:31 +09:00
+++ 2/supertask.c	2006-01-16 22:53:28 +09:00
@@ -346,7 +346,7 @@
 	Uns ret;
 
 	if ((tid < n_task) || (tid >= N_TASK_MAX) || (task_prop[tid] ==
NULL)) {
-		ret = MBCMD_EID_BADTID;
+		ret = 0x83;	// test value
 		goto fail;
 	}
 	if (how == MBCMD_TDEL_KILL) {
diff -urN 1/tokliBIOS.c 2/tokliBIOS.c
--- 1/tokliBIOS.c	2006-01-16 22:52:41 +09:00
+++ 2/tokliBIOS.c	2006-01-16 22:53:05 +09:00
@@ -182,7 +182,7 @@
 	if (bid >= _ipbuf_lines)
 		return MBCMD_EID_BADBID;
 	if ((tid >= N_TASK_MAX) || (task_prop[tid] == NULL))
-		return MBCMD_EID_BADTID;
+		return 0x82;	// test value
 	sync_with_arm(&ipbuf[bid]->sa, tid);
 
 	return 0;
diff -urN 1/usertask.c 2/usertask.c
--- 1/usertask.c	2006-01-16 22:48:59 +09:00
+++ 2/usertask.c	2006-01-16 22:49:37 +09:00
@@ -301,7 +301,7 @@
 	Uns wp, newwp;
 
 	if ((tid >= N_TASK_MAX) || (task_prop[tid] == NULL))
-		return MBCMD_EID_BADTID;
+		return 0x80;	// test value
 
 	prop = task_prop[tid];
 	if (prop->stat == TASK_STAT_STOP)
@@ -389,7 +389,7 @@
 	struct TSK_Attrs *attrs;
 
 	if (task->tid != TID_MAGIC)
-		return MBCMD_EID_BADTID;
+		return 0x81;	// test value
 
 	task_prop[tid] = prop;
 	prop->dsptask = task;
-------------------------------------------------

BR,
Toshihiro Kobayashi

Re: Speex encoder running on DSP through DSP Gateway

[Eduardo Bezerra]

Hi,


  I did your changes to find out what routine in tokliBIOS returns BADTID error.
And it returned 0x81, as you can see in the mailbox kernel message from my
dmesg:

mbx: receiving seq=0, cmd=78:81(ERR:Unknown), data=0000
mbx: ERR from DSP (unknown EID=81): 0000
mbx: sending seq=0, cmd=52:00(PM:DISABLE), data=0002

  and here is my mblog:

arm:~/dspgw# cat /sys/devices/platform/dsp/mblog
log count:47 / ARM->DSP:15, DSP->ARM:32
          ARM -> DSP   ARM <- DSP
jiffies  q cmd  data q cmd  data
0066e9b3 0 7000 0000             DSPCFG:REQ
0066e9b3             0 7070 0019 DSPCFG:PROTREV
0066e9b3             1 f028 007f DSPCFG:SYSADRH
0066e9b3             0 70a9 fe88 DSPCFG:SYSADRL
0066e9b6             1 a300 0003 BKYLD
0066e9b6             0 2300 0004 BKYLD
0066e9b6             1 a300 0005 BKYLD
0066e9b7 0 6000 0000             TCFG:task 0
0066e9b7             0 6000 0000 TCFG:task 0
0066e9c1 1 b000 0000             TCTL:task 0
0066e9c3 0 7500 ffff             SETVAR:ICRMASK
0066ea43 1 d200 0002             PM:DISABLE
00670d32 0 7000 0000             DSPCFG:REQ
00670d32             0 7070 0019 DSPCFG:PROTREV
00670d32             1 f028 007f DSPCFG:SYSADRH
00670d32             0 70a9 fe88 DSPCFG:SYSADRL
00670d34             1 a300 0003 BKYLD
00670d34             0 2300 0004 BKYLD
00670d34             1 a300 0005 BKYLD
00670d36 0 6000 0000             TCFG:task 0
00670d36             0 6000 0000 TCFG:task 0
00670d3e 1 b000 0000             TCTL:task 0
00670d40 0 7500 ffff             SETVAR:ICRMASK
00670d40             1 f900 0020 DBG
00670dc2 1 d200 0002             PM:DISABLE
006720a7 0 3000 8101             TCTL:task 0
006720a7             0 7900 0027 DBG
006720a7 1 d201 0002             PM:ENABLE
006720a9 0 2000 0003             BKSND:task 0
006720a9             1 f900 0014 DBG
006720ab 1 a100 0065             BKREQ:task 0
006720ab             0 7900 0017 DBG
006720ac             1 f900 0010 DBG
006720af             0 7900 0013 DBG
006720b0             1 f900 0016 DBG
006720b2             0 7900 0012 DBG
006720b3             1 f900 0012 DBG
006720b7             0 7900 0018 DBG
006720b8             1 f900 0015 DBG
006720b9             0 7900 0015 DBG
006720ba             1 f900 0016 DBG
006720bb             0 7900 001b DBG
006720bb             1 a000 0000 BKSND:task 0
006720bc             0 7900 000e DBG
006720bc             1 f900 0009 DBG
006720bd             0 7881 0000 ERR:Unknown
0067213c 0 5200 0002             PM:DISABLE

   As I can see in your patch, 0x81 is returned by task_config, when
it checks the
dsp task struct looking for a  TID_MAGIC flag. However, my dsp task struct is:

#pragma DATA_SECTION(task_test, "dspgw_task")

struct dsptask task_test = {
        TID_MAGIC,              /*tid*/
        "task_speex",
        MBCMD_TTYP_GBDM | MBCMD_TTYP_GBMD |
        MBCMD_TTYP_BKDM | MBCMD_TTYP_BKMD |
        MBCMD_TTYP_PSND | MBCMD_TTYP_PRCV,      /* ttyp: passive block
sender, passive block receiver */
        tk_rcv_bksnd, /* rcv_snd */
        tk_rcv_bkreq, /* rcv_req */
        tk_rcv_tctl, /* rcv_tctl */
        NULL, /* tsk_attrs */
        NULL, /* mmap_info */
        &queue/* udata */
};

   I didn't forget to put the TID_MAGIC, as you can see. Nevertheless,
the problem
occurs after the end of the user space application. What do you think?
Do I need to
set TID_MAGIC again, after sending blocks to the ARM side?


2006/1/16, Toshihiro.Kobayashi@nokia.com <Toshihiro.Kobayashi@nokia.com>:
> Hi,
>
> >From: ext Eduardo Bezerra [mailto:edubezval@gmail.com]
> >Sent: Saturday, January 14, 2006 5:26 AM
>
> >> Can you show me how you use bksnd() in your DSP task?
> >
> >Ok. Here is it (just a piece of the tk_rcv_bkreq(), the function that
> >I point to in rcv_req field of my dsptast  struct):
> >/* Sending data in blocks */
> >static Uns tk_rcv_bkreq(struct dsptask *task, Uns cnt)
> >.
> >.
> >.
> >       bid = get_free_ipbuf(task);
> >       if (bid == MBCMD_BID_NULL)
> >               return MBCMD_EID_STVBUF;
> >
> >       dbg(task, "11. preparing the buf\n");
> >       ipbuf_d[bid][0] = nbBytes;
> >
> >       memcpy(ipbuf_d[bid]+1, cbits, nbBytes);
> >       dbg(task, "12. sending data: %d words\n", nbBytes);
> >
> >       bksnd(task, bid, cnt);
> >
> >       dbg(task, "13. releasing\n");
> >
> >       speex_encoder_destroy(enc);
> >       speex_bits_destroy(&bits);
> >
> >       dbg(task, "14. done\n");
> >        return 0;
> >}
> >
> >    Is there any problem in using dbg after sending the block (after
> >the bksnd call)?
>
> No, it's OK at all.
>
> >> Also the dump list of /sys/devices/platform/dsp/mblog may be some
> help.
> >
> >here is my mblog, after the user space applications ends:
> >log count:35 / ARM->DSP:10, DSP->ARM:25
> >          ARM -> DSP   ARM <- DSP
> >jiffies  q cmd  data q cmd  data
> >ffff9fcb 0 7000 0000             DSPCFG:REQ
> >ffff9fcb             0 7070 0019 DSPCFG:PROTREV
> >ffff9fcb             1 f028 007f DSPCFG:SYSADRH
> >ffff9fcb             0 70a9 fe88 DSPCFG:SYSADRL
> >ffff9fcd             1 a300 0003 BKYLD
> >ffff9fcd             0 2300 0004 BKYLD
> >ffff9fcd             1 a300 0005 BKYLD
> >ffff9fce 0 6000 0000             TCFG:task 0
> >ffff9fcf             0 6000 0000 TCFG:task 0
> >ffff9fd8 1 b000 0000             TCTL:task 0
> >ffff9fd9 0 7500 ffff             SETVAR:ICRMASK
> >ffff9fd9             1 f900 0020 DBG
> >ffffa05b 1 d200 0002             PM:DISABLE
> >ffffe653 0 3000 8101             TCTL:task 0
> >ffffe653 1 d201 0002             PM:ENABLE
> >ffffe653 0 2000 0003             BKSND:task 0
> >ffffe653             0 7900 0027 DBG
> >ffffe655             1 f900 0014 DBG
> >ffffe655 1 a100 0065             BKREQ:task 0
> >ffffe656             0 7900 0017 DBG
> >ffffe657             1 f900 0010 DBG
> >ffffe65a             0 7900 0013 DBG
> >ffffe65b             1 f900 0016 DBG
> >ffffe65d             0 7900 0012 DBG
> >ffffe65e             1 f900 0012 DBG
> >ffffe663             0 7900 0018 DBG
> >ffffe664             1 f900 0015 DBG
> >ffffe665             0 7900 0015 DBG
> >ffffe665             1 f900 0016 DBG
> >ffffe666             0 7900 001b DBG
> >ffffe667             1 a000 0000 BKSND:task 0
> >ffffe667             0 7900 000e DBG
> >ffffe668             1 f900 0009 DBG
> >ffffe668             0 7810 0000 ERR:BADTID
> >ffffe6d5 0 5200 0002             PM:DISABLE
>
> And this looks fine too, except for the BADTID error...
>
> Unfortunately I have no idea at the moment.
> Could you find out which routine in tokliBIOS returns
> BADTID error, by replacing MBCMD_EID_BADTID with other values?
>
> for example,
>
> -------------------------------------------------
> diff -urN 1/supertask.c 2/supertask.c
> --- 1/supertask.c       2006-01-16 22:52:31 +09:00
> +++ 2/supertask.c       2006-01-16 22:53:28 +09:00
> @@ -346,7 +346,7 @@
>         Uns ret;
>
>         if ((tid < n_task) || (tid >= N_TASK_MAX) || (task_prop[tid] ==
> NULL)) {
> -               ret = MBCMD_EID_BADTID;
> +               ret = 0x83;     // test value
>                 goto fail;
>         }
>         if (how == MBCMD_TDEL_KILL) {
> diff -urN 1/tokliBIOS.c 2/tokliBIOS.c
> --- 1/tokliBIOS.c       2006-01-16 22:52:41 +09:00
> +++ 2/tokliBIOS.c       2006-01-16 22:53:05 +09:00
> @@ -182,7 +182,7 @@
>         if (bid >= _ipbuf_lines)
>                 return MBCMD_EID_BADBID;
>         if ((tid >= N_TASK_MAX) || (task_prop[tid] == NULL))
> -               return MBCMD_EID_BADTID;
> +               return 0x82;    // test value
>         sync_with_arm(&ipbuf[bid]->sa, tid);
>
>         return 0;
> diff -urN 1/usertask.c 2/usertask.c
> --- 1/usertask.c        2006-01-16 22:48:59 +09:00
> +++ 2/usertask.c        2006-01-16 22:49:37 +09:00
> @@ -301,7 +301,7 @@
>         Uns wp, newwp;
>
>         if ((tid >= N_TASK_MAX) || (task_prop[tid] == NULL))
> -               return MBCMD_EID_BADTID;
> +               return 0x80;    // test value
>
>         prop = task_prop[tid];
>         if (prop->stat == TASK_STAT_STOP)
> @@ -389,7 +389,7 @@
>         struct TSK_Attrs *attrs;
>
>         if (task->tid != TID_MAGIC)
> -               return MBCMD_EID_BADTID;
> +               return 0x81;    // test value
>
>         task_prop[tid] = prop;
>         prop->dsptask = task;
> -------------------------------------------------
>
> BR,
> Toshihiro Kobayashi
>


--
Eduardo Bezerra Valentin