所有文件在附件里
确保你已经安装了开发工具
1.使用新立得安装libusb
2.复制45-jlink.rules到/etc/udev/rules.d/下,重新启动
3.添加组plugdev,并且把当前用户添加到这个组里面
sudo groupadd plugdev
sudo usermod -a -G plugdev 用户名
4.解压openocd-0.4.0.tar.bz2
tar jxvf openocd-0.4.0.tar.bz2
5.编译openocd
cd openocd-0.4.0
./configure --prefix=/opt/openocd --enable-jlink
make && make install
6.修改/etc/environment在PATH添加/opt/openocd/bin路径
sudo gedit /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/openocd/bin"
7.拷贝配置文件到开发的目录
cp /opt/openocd/share/openocd/scripts/interface/jlink.cfg ./
目前分類：openjtag (3)
- Mar 31 Thu 2011 13:45
在ubuntu9.10下使用openocd+jlink
- Mar 30 Wed 2011 19:21
Debugging the Linux kernel with JTAG
Debugging the Linux kernel with JTAG
Alexander Sirotkin
8/29/2010 1:31 PM EDT
As with many Linux-related topics, the issue of using debuggers to troubleshoot the Linux kernel is not only technical--it's political. Linux is being mostly developed on the x86 platform, which does not have JTAG debugging capabilities, and software-only kernel debuggers are complex and unreliable. Because of this and other reasons, Linus Torvalds objected for a long time to inclusion of the KGDB (Linux kernel debugger) patch in the main Linux tree until Ingo Molnar managed to get a rather slimmed down KGDB variant into the 2.6.26 version. Putting politics aside, I believe that most developers would agree with me, that at least in the embedded world, a kernel debugger is a must-have tool for many tasks, BSP (board support package) development being probably the most obvious example.
Fortunately, compared with the world of x86, embedded platforms introduce not only additional challenges but also a good tool to help us tackle the problem--a JTAG debugger. It's easy to use, reliable, provides some nice features that are not available in software-only debuggers and is free from any controversy that is always associated with invasive Linux kernel patches, such as the original KGDB.
I assume that the topic of JTAG debugging is not new to you--as an experienced embedded systems developer, you have probably used something like Wind River's On-Chip Debugging in the past. I will go very briefly over general JTAG debugging capabilities and show you the peculiarities of Linux kernel debugging using JTAG.
JTAG is your friend
JTAG (Joint Test Action Group) was initially developed as a way to test circuit boards after manufacture, however today it's more commonly used for debugging embedded systems. A JTAG adaptor, sometimes referred to as in-circuit emulator (ICE), is used to access on-chip debug modules inside the target CPU.
It allows, among other things, to halt the CPU, inspect its registers and memory, single step through the code, and define breakpoints. In addition to the hard, you will also need a software debugger that supports it. Some JTAG adapter vendors provide software tools while others rely on open source packages.
Even though most JTAG debuggers nowadays support Linux, if you're shopping for a low-cost device, I suggest you ask whether it supports Linux, which boils down to memory management units (MMU), Linux binary formats, and loadable modules support. If it supports remote GDB (GNU debugger) protocol as well, you can be sure that it's going to work.
Cast of characters
I will use my setup of a FemtoLinux project throughout this article to demonstrate how to debug the Linux kernel on ARM, so it's beneficial to describe the setup first. The aim of this project is to reduce the Linux system's call latency and overhead in order to make it possible to port VxWorks 5.5 monolithic applications to Linux without redesign. As you would imagine, this kind of low-level Linux kernel hacking would be nearly impossible without JTAG.
- Mar 30 Wed 2011 17:39
DebuggingTheLinuxKernelUsingGdb
eLinux.org - Embedded Linux Wiki
DebuggingTheLinuxKernelUsingGdb
From eLinux.org
Contents[hide] |
Debugging the linux kernel using gdb
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in Kernel Debugging Tips. Using printk is a relatively simple, effective and cheap way to find problems. There are many other Linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the GNU debugger (GDB) to do kernel debugging. The GDB page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.
Most of the examples here will work in two (open source) situations. When using JTAG and when using QEMU system emulation. As the second option does not require any hardware you could go on and try it right away!
The open source JTAG debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested ARM11 and ARM9.
Requirements
GDB:
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target (read armv6). with that you might also want to have the gdbserver that can serve as stub for you user land debugging.
OpenOCD:
TODO...
A JTAG Dongle:
TODO...
The basics
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done you can do your normal kernel development. When needed you can "hook-up" your debugger. Start debugging a running kernel.
- start openocd
vmlinuz v.s zImage
When you want to debug the kernel you need a little understanding of how the kernel is composed. Most important is the difference between your vmlinux and the zImage. What you need to understand at this point is that the zImage is a container. This container gets loaded by a boot loader and that execution is handed over to the zImage. This zImage unpacks the kernel to the same memory location and starts executing the kernel. (explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot
vmlinux arch/arm/boot `-- zImage
vmlinux is what we will be using during debugging of the Linux kernel.
