Skip to contentSkip to conversation

Speex encoder running on DSP through DSP Gateway

DISCUSSION Eduardo Bezerra 2 participants 5 messages Jan 11, 2006 – Jan 18, 2006

lore
Share & tools
lore

Eduardo Bezerra

author
#0 lore raw

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

#1 lore raw

Hi,

From: Eduardo Bezerra <[email protected]>
Subject: Speex encoder running on DSP through DSP Gateway
Date: Wed, 11 Jan 2006 11:18:39 -0400

Quoted 4 lines

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.

Quoted 78 lines

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
* */

(quoted diff) +0 -2
-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
Quoted 8 lines

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

author
#2 lore raw

Hi,

2006/1/13, [email protected] <[email protected]>:

Quoted 93 lines

Hi,

From: Eduardo Bezerra <[email protected]>
Subject: Speex encoder running on DSP through DSP Gateway
Date: Wed, 11 Jan 2006 11:18:39 -0400

Quoted 4 lines

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.

Quoted 78 lines

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
* */

(quoted diff) +0 -2
-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
Quoted 10 lines
Quoted 8 lines

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)?

Quoted 3 lines

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

Quoted 4 lines

BR,
Toshihiro Kobayashi

BR,
--
Eduardo Bezerra Valentin

#3 lore raw

Hi,

Quoted 33 lines

From: ext Eduardo Bezerra [mailto:[email protected]]
Sent: Saturday, January 14, 2006 5:26 AM

Quoted 1 line

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;
}
Quoted 2 lines

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

No, it's OK at all.

Quoted 1 line
Quoted 1 line

Also the dump list of /sys/devices/platform/dsp/mblog may be some

help.

Quoted 39 lines

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
Quoted 1 line

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,

-------------------------------------------------

supertask.c +0 -0
diff -urN 1/supertask.c 2/supertask.c
@@ -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) {

tokliBIOS.c +1 -1
diff -urN 1/tokliBIOS.c 2/tokliBIOS.c
@@ -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;
usertask.c +2 -2
diff -urN 1/usertask.c 2/usertask.c
@@ -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

author
#4 lore raw

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, [email protected] <[email protected]>:

Quoted 140 lines

Hi,

Quoted 33 lines

From: ext Eduardo Bezerra [mailto:[email protected]]
Sent: Saturday, January 14, 2006 5:26 AM

Quoted 1 line

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;
}
Quoted 2 lines

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

No, it's OK at all.

Quoted 1 line
Quoted 1 line

Also the dump list of /sys/devices/platform/dsp/mblog may be some

help.

Quoted 39 lines

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
Quoted 1 line

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

supertask.c 2006-01-16 22:53:28 +09:00 renamed from supertask.c 2006-01-16 22:52:31 +09:00 +1 -1
@@ -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

tokliBIOS.c 2006-01-16 22:53:05 +09:00 renamed from tokliBIOS.c 2006-01-16 22:52:41 +09:00 +1 -1
@@ -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

usertask.c 2006-01-16 22:49:37 +09:00 renamed from usertask.c 2006-01-16 22:48:59 +09:00 +2 -3
@@ -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;
-------------------------------------------------
Quoted 3 lines

BR,
Toshihiro Kobayashi

--
Eduardo Bezerra Valentin