Embedded 版 (精华区)

发信人: he (无情的雨), 信区: Embedded_system
标  题: linux for ppc chapter 18 
发信站: 哈工大紫丁香 (2001年06月04日11:10:07 星期一), 站内信件

----------------------------------------------------------------------------
----
18. Debugging
18.1 BDM
BDM is way cool, especially if you are bringing up a custom board and don't
want to invest in an In Circuit Emulator. You should definitely include a BD
M connector on any custom hardware, and all off-the-shelf boards have it. Fo
r a broad introduction, see: http://www.macraigor.com/zenofbdm.pdf
Be careful to ensure that the CPU watchdog is disabled in your BDM probes' c
onfiguration file, otherwise it will continually reset the CPU and nothing w
ill work. In particulary, the watchdog is enabled at reset and must be disab
led if you wish to single step from reset. Also check that DER is zero'd whe
n running with the debugger. Leaving the BDM probe connected can interfere w
ith the target if it is not configured absolutely correctly, which usually i
nvolves the BDM probe being completely passive once the kernel is running. S
ymptoms are that the kernel crashes with the BDM probe connected, but runs f
ine without it. If you are using BDM and experience unexpected kernel crashe
s, try disconnecting the BDM probe.
If you're using an off-the-shelf board which already has a working rom monit
or, you generally won't need to use BDM at all, as you can get by fine with
just the serial console. Many developers, particularly those bringing up a c
ustom board from scratch, find BDM invaluable; to others it can be more trou
ble than it's worth. One advantage of a BDM interface over a kernel debugger
 is that you can really "freeze" the CPU including all timers, interrupts et
c.
MMU Support
Some BDM debuggers are capable of performing MMU table walks, which is essen
tial for debugging in virtual memory environments such as Linux because othe
rwise the BDM port merely deals with raw physical addresses. However, many B
DM systems can't do this, so check with the vendor that they support MMU tab
le walks on the particular CPU you're interested in before committing to one
; otherwise it will be almost impossible to use once the kernel has turned t
he MMU on. See: http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/
msg00021.html.
Once the kernel is running you can use gdb remotely or even run it natively
on the target hardware if you have enough RAM. It may be worth providing ext
ra RAM on some of your development boards to allow for this.
GDB on BDM
See "Using GDB for Remote Debugging: BDM Support" in the CrossGCC FAQ at: ht
tp://www.objsw.com/CrossGCC/FAQ-7.html
tp://www.objsw.com/CrossGCC/FAQ-7.html
BDM debugging under GDB is not supported by all BDM hardware vendors. See th
e thread: http://www.oarcorp.com/rtems/freesupport/rtemslistArchive/1999/jul
y/msg00057.html
To support BDM debugging under gdb requires the appropriate remote-* device
in GDB, and possibly a kernel driver. If you are cross-developing, you must
configure gdb as follows to include the appropriate devices:
    % configure --target=powerpc-linux
The following systems currently support BDM debugging on gdb:
BDM4GDB
http://bdm4gdb.sourceforge.net/
An open user-supported project to build your own PowerPC BDM interface at ex
tremely low cost. Supports extensible Flash programming and implements softw
are-tablewalk so you have MMU support; you can use GDB to debug kernel code
(single stepping, breakpoints, etc.) and/or inspect kernel data.
If you don't want to build it yourself, the adapter is available at cost fro
m Denx, subject to availability.
MPCBDM
http://www.vas-gmbh.de/software/mpcbdm/
The precursor to the BDM4GDB project, courtesy of Frank Przybylski.
PPCBDM
http://cyclone.parad.ru/ppcbdm/
The ultra low hardware cost precursor to MPCBDM and BDM4GDB, courtesy of Ser
gey Drazhnikov.
Abatron
http://www.abatron.ch/BDI/bdiGDB.html
Has an ideal BDM/JTAG emulation solution for Linux hosting, with Linux MMU s
upport specifically in mind. It is an Ethernet-based unit which has a telnet
 interface with which one can program various popular flash parts. This is i
deal for Linux since one can build a kernel and expect script the programmin
g process automagically.
Their external box implements the standard GDB remote protocol allowing you
to host debugging on any platform that can host GDB.
Huntsville Microsystems
http://www.hmi.com/bmd.htm
Patches to add support to gdb are available in: ftp://ftp.hmi.com/pub/gdb/
Macraigor Systems
http://www.macraigor.com/
Currently only support Windoze platform, but say Linux support for the Kestr
el device (but not the Wiggler, Raven, etc) should be available sometime in
September 2000.
OCD Commander is a free assembly level debugger for Windows, which may work
under VMWare. I couldn't get it to work with the Raven/Blackbird interface o
n the Embedded Planet CLLF under Windows; it wouldn't single step correctly.


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

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.235.250]