请教移植调试过程中的问题,谢谢了!

现在欲将qnx移植到CIRRUS的ep9315芯片上,代码(startup,ipl等)的修改已经结束,进入了调试阶段,但是调试总卡在一个地方,通过串口输出的信息如下,随后即出现了问题。
Dcache: 512x32 WB
Icache: 512x32
cpuid:1091736064,cpuspeed:0
arm920 rev 0 5MHz

System page at phys:000ed000 user:fc404000 kern:fc404000
Starting next program at vfe01c530

Shutdown[0,0] S/C/F=11/1/11 C/D=fe005d7c/fe048500 state(c0)= now lock
[0]PID-TID=1-1? P/T FL=00019001/09000000
armle context[ff7f5f54]:
0000: 00000000 00000000 00000000 00000000 ff7f4070 ff7fdbb0 00000000 ff7f4070
0020: 00000004 fe020eec 00000000 ff7f5fa8 fc40b000 ff7f5f98 fc4047c0 fc4047c0
0040: 800000d3
instruction[fc4047c0]:
10 20 90 e5 01 20 a0 e3 20 10 41 e2 13 31 a0 e1 03 20 80 e1 00 10 a0 e3 10 10
stack[ff7f5f98]:
0000: ff7fb448 ff7f5fd8 ff7f5fac fe023500 fe0237fc 00000000 00000004 fe0480c4
0020: 00000001 ff7fdbb0 00000000 00000000 00000000 ff7f5fec ff7f5fdc fe0216b4
0040: fe0233dc ff7fdbb0 ff7f5ffc ff7f5ff0 fe03158c fe021664 ff7f3f6c ff7f6000
0060: fe01f500 fe031574 ff7fdbb0 00001000 ff7f8038 00000ff8 35f7bfff 67f7dff7

向请教各位,大概出现了啥问题?
附上我的buildfile
[image=0x00000000]
[virtual=armle,binary] .bootstrap = {
startup-ep9315 -v
PATH=/proc/boot procnto -v
}
[+script] .script = {
rocmgr_symlink …/…/proc/boot/libc.so.2 /usr/lib/ldqnx.so.2

display_msg Welcome to Neutrino on the ep9315 Development Board--1

devc-ep9315 -e &
reopen

display_msg Welcome to Neutrino on the ep9315 Development Board---2

slogger &
pipe &
[+session] ksh &
}
[type=link] /dev/console=/dev/ser1
libc.so
[data=copy]
devc-ep9315
pipe
pidin
ls
cat
slogger
sloginfo
ksh=fesh

出现这种情况的原因很多,需要耐心.:slight_smile:
首先build file中的image地址有点不对头,比较安全的是SDRAM地址+1M.
输出信息说你操作的地址没有映射进来.具体指令为
ldr r2, [r0, #16]
mov r2, #1 ; 0x1
sub r1, r1, #32
mov r3, r3, lsl r1
orr r2, r0, r3
mov r1, #0 ; 0x0

指令有些让人摸不到头脑.

还有一个小问题,CPU频率检测为零,说明在startup中TIMER没有启动,但这无关大局.

首先谢谢了!

有几个疑问还是想请教一下:

  1. 在我的buildfile中image=0x00000000,而我的系统镜像文件(.ifs)只有 860k左右,而显示的信息中有:
    System page at phys:000ed000 user:fc404000 kern:fc404000
    Starting next program at vfe01c530
    其中“ System page at phys:000ed000 ”的000ed000完全超出了实际的地址,这个是怎么回事?还是我理解有错误呢?

2.我的arm有两个中断控制器,管理64个中断源,我的做法是写一个callout的.s文件,在中断初试化的做法是这样的:
_NTO_INTR_CLASS_EXTERNAL, // vector base
64, // number of vectors
_NTO_INTR_SPARE, // cascade vector
0, // CPU vector base
0, // CPU vector stride
0, // flags
{ INTR_GENFLAG_LOAD_SYSPAGE, 0, &interrupt_id_ep9315},
{ INTR_GENFLAG_LOAD_INTRMASK|INTR_GENFLAG_LOAD_SYSPAGE, 0, &interrupt_eoi_ep9315},
&interrupt_mask_ep9315, // mask callout
&interrupt_unmask_ep9315, // unmask callout
0, // config callout
不知道这样的初始化有没有问题?
现在调试下来是这样的情况:
在callout中只处理前32个中断则不会出现错误信息,信息只显示到
System page at phys:000ed000 user:fc404000 kern:fc404000
Starting next program at vfe01c530
为止,后面没有任何的提示信息,也没有buildfile中的message信息,因为显示message信息要涉及到后面32个中断。
而是在callout中添加上后面32个中断源的处理就出现了复位的信息。
不知道是不是我的callout文件出现了错误,我的做法是将64个中断源一并处理,没有进行分开处理,是不是这样不大合适呢?

最后还是谢谢comquter了!

syspage是startup代码运行时创建的,不属于你的image.
你所指的那段代码只是告诉startup及内核你的中断控制器的有关信息,至于初试化正确与否要看init_intrinfo.c和patcher正不正确及callout本身是否正确.
至于一并处理/两并处理我记得以前回答过这个问题,都可以,但要作对.
你的情况十有八九是callout写的不正确.

首先感谢comquter不厌其烦的帮我解答,这几天的调试也有了一点的进展
但是现在碰到了一个自己不大明白的问题,终端输出如下:
Dcache: 512x32 WB
Icache: 512x32
arm920 rev 0 147MHz

System page at phys:00013000 user:fc404000 kern:fc404000
Starting next program at vfe01c530
Welcome to Neutrino on the ep9315
W
Shutdown[0,0] S/C/F=10/1/5 C/D=fe005d7c/fe048500 state(1)= 1
[0]PID-TID=2-2? P/T FL=00001010/85020000 “G:/BSP/ep9315/src/hardware/devc/ep9315/arm/le/devc-ep9315”
armle context[ff7f5f7c]:
0000: 00000001 fe04850c 00100000 fe048498 00000000 00000001 fe04850c 00000001
0020: 00000000 00000800 00000022 ff7f5fd8 ff7f5fdc ff7f5fc0 fe02d3e4 fe0080a8
0040: 00000013
instruction[fe0080a8]:
6c 40 95 e5 00 00 54 e3 11 00 00 0a 00 30 0f e1 c0 30 83 e3 03 f0 29 e1 05 30
stack[ff7f5fc0]:
0000: 00000000 ff7fd110 fe04850c ff7f5ffc ff7f5fdc fe02d3e4 fe0080a4 00000034
0020: fc404000 00000057 01800000 ff7f4370 000ffcf0 ff7f6000 ff7f4a84 fe02d300
0040: ff7fdbb0 ff7fdaa0 ff7fd990 ff7fd880 ff7fd770 ff7fd660 ff7fd550 ff7fd330
0060: ff7fd220 ff7f6029 00000001 fffa79ef ff7f8038 00000fd0 ff7a7bfc cfffceed

其中“Welcome to Neutrino on the ep9315”是CLLOUT_DEBUG输出的,
但是在加载串口驱动后只输出“w”就shutdown了,应该是输出同上的一句话,
我也看到了comquter在回答了别人同样问题的解答,当前的问题应该出在串口驱动中,可能是中断发送
我在汇编中在关闭定时器的情况下调试,callout的调用顺序是这样的:
1.callout_unmask(Timer)
2.callout_unmask(UART1,UART1是我输出信息的串口)
3.间隔一段时间(10秒左右),期间输出了“w”
4.callout_mask(UART1)
5.接着运行就shutdown了

不知道这样的运行顺序是不是有问题,先谢谢了!

死在
ldr r4, [r5, #108]
cmp r4, #0 ; 0x0
beq 54
mrs r3, CPSR
orr r3, r3, #192 ; 0xc0
msr CPSR_fc, r3


callout是由内核来调用的,你控制不了调用顺序.
一般来说要中断callout及DEBUG callout调通以后才作串口调试.
你将build file中"ksh=fesk"改为单纯"ksh",将串口驱动及reopen拿掉,"这样的话没有串口也可以输入/输出,记住要将硬件flow control"关掉.
在这种情况下内核回定期调用你的pull_key callout看有没有输入,通过display_char callout来输出.

我不大理解在将build file中"ksh=fesk"改为单纯"ksh",将串口驱动及reopen拿掉,此时怎样将硬件flow control"关掉.
我只知道在调用串口驱动时加上"-F"可以将硬件flow control"关掉,但是在将串口驱动及reopen拿掉怎么样呢?

指的是主机侧的flow control.

按照comquter的说法我进行两种测试:
1.关闭了串口驱动和“reopen”后,串口有输出,问题应该不在callout_debug处;
2.在关闭串口驱动和“reopen”的情况下,添加“pidin -l”语句,运行后串口会定时输出内容,但是并不能确定每次输出的间隔是否为一秒,因为每次输出的内容比较多,表面看到的是串口一直在输出信息

在这样的情况下我想问的是现在问题可以定位到串口驱动上了呢,还是其他的一些地方还存在可疑?

还有一个很奇怪的问题就是,comquter你一再强调需要将“ksh=fesh”改为“ksh”,但是奇怪的是我修改后我的串口接受工具(网上下载的)会在输出“Dcache: 512x32 WB Icache”后死掉,但是不将“ksh=fesh”改为“ksh”则会得到上面的两个测试结果。现在还不是很清楚“ksh=fesh”这句话的作用,不知道是怎么一回事?

“ksh=fesh”是将ksh指向fesh,虽然你启动的是ksh,实际上启动的是fesh.
若没有串口驱动,用fesh只能输出,不能输入.用ksh死机八成是你的poll_key callout有问题.
5秒一次pidin输出用"pidin -l -d50"

之前仔细查看过poll_key callout,其实只有短短数句,我实在是看不出哪里出了问题的。我现在PO上来,请comquter帮忙看一下:
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000

ldr r3, [ip, #EP9315_UART_FLAG] //UART Flag register
tst r3, #EP9315_FLAG_RXFE //Receive FIFO Empty
ldreq r0, [ip, #EP9315_UART_DATA_RX] //UART Data Register
mvnne r0, #1

mov pc, lr
因为display是可以正常被调用的,除了poll_key callout可能本身的问题外还有其他引起这种状况的原因吗?

代码看起来没有问题.蹊跷.
能不能看看你整个startup代码及buildfile?还有IPL的main.c.
你可以发到我的PM.

再次感谢comquter的耐心解答。

(1).按照comquter的方法我每10秒循环调用pidin,中断是有10循环的输出信息,输出的信息:
pid tid name prio STATE Blocked
1 1 proc/boot/procnto 0f READY
1 2 proc/boot/procnto 63r RECEIVE 1
1 3 proc/boot/procnto 10r RECEIVE 1
1 4 proc/boot/procnto 11r RECEIVE 1
1 5 proc/boot/procnto 63r RECEIVE 1
1 6 proc/boot/procnto 10r RECEIVE 1
1 7 proc/boot/procnto 10r RECEIVE 1
1 8 proc/boot/procnto 10r RECEIVE 1
1 9 proc/boot/procnto 10r RECEIVE 1
1 10 proc/boot/procnto 10r RUNNING
1 11 proc/boot/procnto 10r RECEIVE 1
135170 1 proc/boot/pidin 10r REPLY 1
3 1 proc/boot/slogger 10r RECEIVE 1
4 1 proc/boot/pipe 10r RECEIVE 1
4 2 proc/boot/pipe 10r RECEIVE 1
4 3 proc/boot/pipe 10r RECEIVE 1
5 1 proc/boot/ksh 10r SIGSUSPEND
假如没有循环在输出以上内容后会出现如下的信息:
ksh: j_init: tcgetpgrp() failed: Inappropriate I/O control operation
ksh: warning: won’t have full job control

"j_init: tcgetpgrp() failed"的错误不知道是什么问题引起的,不知道是不是
和串口驱动有关的,因为我没有添加串口驱动。还有我感到疑问的是为何会有那么多个的procnto出于接受状态,是不是代表着内核内出于监听状态的线程?只是自己的猜测而已。

(2)至于poll_key_的问题,我仔细查看了相关的代码,实在是没有任何的问题,索性在网上又下载了一个串口调试软件,这次串口能接受我输入的内容,并且通过串口输出相应的内容,我想问题应该出在串口调试软件上。

以上的情况都没有在buildfile内添加devc,这样下来后添加上devc串口驱动后出
现shutdown是不是可以定位于串口驱动的问题了呢?

ksh: j_init: tcgetpgrp() failed: Inappropriate I/O control operation
ksh: warning: won’t have full job control
是正常的,因为你没有console.
unmask/mask callout有问题,因为它们是函数调用,只有r0-r3,ip是可以随便用的,要用别的寄存器的话要用堆栈来保护/恢复.
IntEnable写零无效,所以不需要与操作.

Unmask callout 例
mov r0, #0x000000ff
orr r0, r0, #0x0000ff00
orr r0, r0, #0x00ff0000
orr r0, r0, #0xff000000

mov r3, #0x000000ff // VIC2 physical base (patched)
orr r3, r3, #0x0000ff00
orr r3, r3, #0x00ff0000
orr r3, r3, #0xff000000

subs r2, r1, #32
movpl r1, r2
movpl r0, r3
mov r3, #1
mov r1, r3, lsl r1
str r1, [r0, #EP9315_INTERRUPT_ENABLE]

mov r0, #0
mov pc, lr
串口驱动一般用InterruptAttach()否则的话很容易接受溢出.

以前调试中断callout的时候曾经注意过callout中寄存器的使用,因为当我遇到一个莫名其妙的问题到无计可施的时候,更换一个寄存器后当时遇到的问题就解决了,但是后来也就再没有想到过这个问题。

按照comquter的修改我运行了一下,下载已经没有问题了,谢谢comquter那么及时的帮我检查代码。

还有一点疑问就是在callout中的“#if 0 … #else#endif”的判断依据是什么呢?只是使用了“#if 0 ”,是判断栈中是否有存放积存器的值吗?

#if 0 与#else之间的代码不会被编译.

现在有一个不大明白的小问题,就是当内核运行在arm上时,通过串口发送cat命令令其显示一个文件的内容时,没有任何的反应,而且没有了“#”这个标志,再向其发送命令则就没有了任何的反应,不知道怎么回事?其他之类的命令“cd,pwd,pidin”都是没有问题的。

有没有串口驱动?文件内容是否为文本?

串口驱动已经添加了的.
可能是我要打开的文件不是文本文件的关系吧,可是在用我在虚拟机安装的qnx 下打开显示是可以的,只是输出的信息都是乱码一片,导致命令行都是以乱码出现的

现在向在arm上运行的内核发送打开某文件的命令都是没有响应的,而且都导致没有了"#"提示符,当然这边打开也不是文本文件,可能是系统的一些链接库文件!

不好说,你最好能作一下串口的stress测试.