📄 219.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://202.112.58.200"><font face="黑体"><big><big>Tsinghua</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> 嵌入式系统 (BM: turbolinux jacobw) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="198.htm">上一层</a>][<a href="220.htm">下一篇</a>]
<hr><p align="left"><small>发信人: plato (纯真年代), 信区: Embedded <br>
标 题: linux for ppc chapter 18 <br>
发信站: BBS 水木清华站 (Wed May 30 23:22:52 2001) <br>
<br>
Next Previous Contents <br>
---------------------------------------------------------------------------- <br>
---- <br>
18. Debugging <br>
18.1 BDM <br>
BDM is way cool, especially if you are bringing up a custom board and don't <br>
want to invest in an In Circuit Emulator. You should definitely include a BD <br>
M connector on any custom hardware, and all off-the-shelf boards have it. Fo <br>
r a broad introduction, see: http://www.macraigor.com/zenofbdm.pdf <br>
Be careful to ensure that the CPU watchdog is disabled in your BDM probes' c <br>
onfiguration file, otherwise it will continually reset the CPU and nothing w <br>
ill work. In particulary, the watchdog is enabled at reset and must be disab <br>
led if you wish to single step from reset. Also check that DER is zero'd whe <br>
n running with the debugger. Leaving the BDM probe connected can interfere w <br>
ith the target if it is not configured absolutely correctly, which usually i <br>
nvolves the BDM probe being completely passive once the kernel is running. S <br>
ymptoms are that the kernel crashes with the BDM probe connected, but runs f <br>
ine without it. If you are using BDM and experience unexpected kernel crashe <br>
s, try disconnecting the BDM probe. <br>
If you're using an off-the-shelf board which already has a working rom monit <br>
or, you generally won't need to use BDM at all, as you can get by fine with <br>
just the serial console. Many developers, particularly those bringing up a c <br>
ustom board from scratch, find BDM invaluable; to others it can be more trou <br>
ble than it's worth. One advantage of a BDM interface over a kernel debugger <br>
is that you can really "freeze" the CPU including all timers, interrupts et <br>
c. <br>
MMU Support <br>
Some BDM debuggers are capable of performing MMU table walks, which is essen <br>
tial for debugging in virtual memory environments such as Linux because othe <br>
rwise the BDM port merely deals with raw physical addresses. However, many B <br>
DM systems can't do this, so check with the vendor that they support MMU tab <br>
le walks on the particular CPU you're interested in before committing to one <br>
; otherwise it will be almost impossible to use once the kernel has turned t <br>
he MMU on. See: http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/ <br>
msg00021.html. <br>
Once the kernel is running you can use gdb remotely or even run it natively <br>
on the target hardware if you have enough RAM. It may be worth providing ext <br>
ra RAM on some of your development boards to allow for this. <br>
GDB on BDM <br>
See "Using GDB for Remote Debugging: BDM Support" in the CrossGCC FAQ at: ht <br>
tp://www.objsw.com/CrossGCC/FAQ-7.html <br>
BDM debugging under GDB is not supported by all BDM hardware vendors. See th <br>
e thread: http://www.oarcorp.com/rtems/freesupport/rtemslistArchive/1999/jul <br>
y/msg00057.html <br>
To support BDM debugging under gdb requires the appropriate remote-* device <br>
in GDB, and possibly a kernel driver. If you are cross-developing, you must <br>
configure gdb as follows to include the appropriate devices: <br>
% configure --target=powerpc-linux <br>
The following systems currently support BDM debugging on gdb: <br>
BDM4GDB <br>
http://bdm4gdb.sourceforge.net/ <br>
An open user-supported project to build your own PowerPC BDM interface at ex <br>
tremely low cost. Supports extensible Flash programming and implements softw <br>
are-tablewalk so you have MMU support; you can use GDB to debug kernel code <br>
(single stepping, breakpoints, etc.) and/or inspect kernel data. <br>
If you don't want to build it yourself, the adapter is available at cost fro <br>
m Denx, subject to availability. <br>
MPCBDM <br>
http://www.vas-gmbh.de/software/mpcbdm/ <br>
The precursor to the BDM4GDB project, courtesy of Frank Przybylski. <br>
PPCBDM <br>
http://cyclone.parad.ru/ppcbdm/ <br>
The ultra low hardware cost precursor to MPCBDM and BDM4GDB, courtesy of Ser <br>
gey Drazhnikov. <br>
Abatron <br>
http://www.abatron.ch/BDI/bdiGDB.html <br>
Has an ideal BDM/JTAG emulation solution for Linux hosting, with Linux MMU s <br>
upport specifically in mind. It is an Ethernet-based unit which has a telnet <br>
interface with which one can program various popular flash parts. This is i <br>
deal for Linux since one can build a kernel and expect script the programmin <br>
g process automagically. <br>
Their external box implements the standard GDB remote protocol allowing you <br>
to host debugging on any platform that can host GDB. <br>
Huntsville Microsystems <br>
http://www.hmi.com/bmd.htm <br>
Patches to add support to gdb are available in: ftp://ftp.hmi.com/pub/gdb/ <br>
Macraigor Systems <br>
http://www.macraigor.com/ <br>
Currently only support Windoze platform, but say Linux support for the Kestr <br>
el device (but not the Wiggler, Raven, etc) should be available sometime in <br>
September 2000. <br>
OCD Commander is a free assembly level debugger for Windows, which may work <br>
under VMWare. I couldn't get it to work with the Raven/Blackbird interface o <br>
n the Embedded Planet CLLF under Windows; it wouldn't single step correctly. <br>
<br>
<br>
Beware that the 1999 version of OCD Commander silently truncates S-records l <br>
onger than 20 bytes during download, so you'll need to patch objcopy or writ <br>
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 http://sources.redhat.com/cygwin/ 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 http://www.macraigor.com/ 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>
http://www.estc.com/ <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>
http://www.mentor.com/embedded/xray/index.html <br>
Huntsville Microsystems (SourceGate) <br>
http://www.hmi.com/bmd.htm <br>
Tasking (CrossView Pro) <br>
http://www.tasking.com/products/PPC/ppcsolution.htm#debugger <br>
SDS (SingleStep) <br>
http://www.sdsi.com/product/powerpc/index.php3#power <br>
Applied Microsystems (PowerTap): <br>
http://www.amc.com/products/powertap.html <br>
Lauterbach <br>
http://www.lauterbach.com/ <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: http://qslinux.org/docs/cross/gdb/ <br>
index.html <br>
If you're cross-developing, remember to configure your gdb as described earl <br>
ier. <br>
rproxy <br>
http://www.std.com/qqi/labslave/rproxy.html <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: http://lists.linuxpp <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>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="198.htm">上一层</a>][<a href="220.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -