📄 00000019.htm
字号:
e your own S-record generator to work around this. <br />They have flash programming software available for download, but the website <br /> doesn't mention that it isn't actually free: you have to pay for the key to <br /> use it. <br />If you're prepared to do your debugging under Windoze, you can use the Cygwi <br />n tools from <a href="http://sources.redhat.com/cygwin/">http://sources.redhat.com/cygwin/</a> to build a gdb cross-debugger <br /> which runs under Windoze and uses the Wigglers.dll to talk to the target. N <br />ote that Wigglers.dll also loads other DLLs, so copy all the DLLs that come <br />with OCD Commander from <a href="http://www.macraigor.com/">http://www.macraigor.com/</a> into your GDB directory an <br />d use the command: <br /> (gdb) target ocd wiggler <br />You can also do this remotely, by using rproxy, described below. <br />EST Corporation <br /><a href="http://www.estc.com/">http://www.estc.com/</a> <br />They've ported their VisionXD UNIX debugger to Linux and it is available wit <br />h their parallel port of Ethernet based probe. It can program flash parts an <br />d do source level debugging. It costs $6k or $8k depending on parport or Eth <br />ernet connection. The Windoze version is only $4k. :-/ <br />Beware that the EST tools don't handle the Linux zImage properly. See: http: <br />//lists.linuxppc.org/listarcs/linuxppc-embedded/200002/msg00073.html <br />Other debuggers <br />There are many other sources of BDM hardware probes and debuggers, but many <br />vendors still lag way behind as far as Linux support. Commercial solutions w <br />hich do not support a Linux development host: <br />Mentor (X-ray) <br /><a href="http://www.mentor.com/embedded/xray/index.html">http://www.mentor.com/embedded/xray/index.html</a> <br />Huntsville Microsystems (SourceGate) <br /><a href="http://www.hmi.com/bmd.htm">http://www.hmi.com/bmd.htm</a> <br />Tasking (CrossView Pro) <br /><a href="http://www.tasking.com/products/PPC/ppcsolution.htm#debugger">http://www.tasking.com/products/PPC/ppcsolution.htm#debugger</a> <br />SDS (SingleStep) <br /><a href="http://www.sdsi.com/product/powerpc/index.php3#power">http://www.sdsi.com/product/powerpc/index.php3#power</a> <br />Applied Microsystems (PowerTap): <br /><a href="http://www.amc.com/products/powertap.html">http://www.amc.com/products/powertap.html</a> <br />Lauterbach <br /><a href="http://www.lauterbach.com/">http://www.lauterbach.com/</a> <br />18.2 Serial Console <br />Virtually all boards use a serial console on SMC1 for boot messages and gene <br />ral debugging. Connect it to a serial port on your Linux development machine <br />, where you can run minicom to interact with the board. <br />18.3 GDB <br />Once the kernel is running, you can use gdb in several different ways to deb <br />ug user space programs: <br />gdbserver <br />You can run gdbserver on your target and run gdb back on your development ma <br />chine, even if you're cross developing. This requires far less resources tha <br />n running all of gdb on your target. See: <a href="http://qslinux.org/docs/cross/gdb/">http://qslinux.org/docs/cross/gdb/</a> <br />index.html <br />If you're cross-developing, remember to configure your gdb as described earl <br />ier. <br />rproxy <br /><a href="http://www.std.com/qqi/labslave/rproxy.html">http://www.std.com/qqi/labslave/rproxy.html</a> <br />This in an extended/enhanced gdbserver, which can also run on Windoze and ta <br />lk to BDM devices not yet supported by Linux. <br />native <br />If you have lots of RAM, you can run gdb directly on your target. If you are <br /> cross developing, you need to configure gdb with: <br /> % configure --host=powerpc-linux <br />18.4 Kernel <br />Some kernels include "kgdb" support for using gdb for kernel debugging, enab <br />led by configuring with CONFIG_KGDB. <br />18.5 Oops Messages <br />You get these whenever something truly bad happens in the kernel. Learn to k <br />now and respect them -- they are your friend, not your enemy. For general in <br />fo on how to understand them, see the file Documentation/oops-tracing.txt in <br /> the kernel source tree. <br />You'll get a long way just by looking up the instruction at the address indi <br />cated by NIP on the first line of the Oops in the output of: <br />objdump --disassemble vmlinux <br />This will show you the instruction causing the fault. Work backwards to find <br /> the line of C source code associated with it, and add printk's around it to <br /> find what is going wrong. <br />For more help with decoding kernel panic messages, see: <a href="http://lists.linuxpp">http://lists.linuxpp</a> <br />c.org/listarcs/linuxppc-embedded/199912/msg00090.html <br />18.6 printk <br />printk is an indispensible tool. You can use it to add checkpointing, print <br />kernel values that you can't get to via /proc, etc etc. It can be called any <br />where, including interrupt routines, provided you're prepared for some inter <br />esting output. <br />Note that during the boot process, the kernel "prints" lots of stuff, and it <br /> all goes into a buffer, to emerge quite late in the boot process when the s <br />erial console port is initialized with the call to console_init. This eventu <br />ally calls register_console which will dump out the logged messages. So you <br />can't necessarily assume that the kernel didn't get to your checkpoint just <br />because the printk message didn't appear on the serial port during this part <br /> of the boot sequence. <br />---------------------------------------------------------------------------- <br />---- <br />Next Previous Contents <br /> <br />-- <br /> <br />※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.161.8] <br /><a href="00000018.htm">上一篇</a><a href="javascript:history.go(-1)">返回上一页</a><a href="index.htm">回到目录</a><a href="#top">回到页首</a><a href="00000020.htm">下一篇</a></h1></center><center><h1>BBS 水木清华站∶精华区</h1></center></body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -