RTEMS的板级调试

最近实在太忙，实在是赶时间。朋友提了个在9260上板级调试问题。这个问题我觉得提得非常好，具有通用性。所以，怎么也抽时间写这篇博文。

RTEMS的板级别调试不像使用qemu mini2440 那么简单。还是比较复杂的。当中有许多技术上的小细节。首先我们从qemu mini2440的调试讲起。我建议大家使用DDD来调试。关于DDD的调试，可以看rickleaf牛牛的博文，《RTEMS 在 Linux环境开发的小技巧》。这位大牛喜欢用ubuntu,我比较喜欢用fedora, 就以fedora8为例，以root权限登录后，在控制端里输入以下命令：

yum install ddd

安装完成后(保持网速哦)，输入
ddd --debugger arm-rtems4.9-gdb


(注意，arm-rtems4.9-gdb的路径一定要在环境变量里)就启动了ddd,很酷的。
我们在另一个终端里启动qemu mini2440的仿真器。打开qemu/mini2440/mini2440_start.sh

cmd="$base/../arm-softmmu/qemu-system-arm \
    -M mini2440 $* \
    -drive file=$name_snapshots,snapshot=on \
    -serial stdio \
    -kernel uImage \
    -mtdblock "$name_nand" \
    -show-cursor \
    -usb -usbdevice keyboard -usbdevice mouse \
    -net nic,vlan=0 \
    -net tap,vlan=0,ifname=tap0 \
    -monitor telnet::5555,server,nowait"

修改为：

cmd="$base/../arm-softmmu/qemu-system-arm \
    -S -s \
    -M mini2440 $* \
    -drive file=$name_snapshots,snapshot=on \
    -serial stdio \
    -kernel /tftpboot/uImage \
    -mtdblock "$name_nand" \
    -show-cursor \
    -usb -usbdevice keyboard -usbdevice mouse \
    -net nic,vlan=0 \
    -net tap,vlan=0,ifname=tap0 \
    -monitor telnet::5555,server,nowait"

保存后，在路径 qemu/下输入命令：
./mini2440/mini2440_start.sh

注意一定要在 qemu/ 路径下输入该命令，否则，该脚本会执行不正常。等待mini2440_start.sh脚本执行完毕，它会停在一个位置不动，然后回到DDD的界面下，在命令行界面下输入：
file ~/work/network-demos-4.9.5/telnetd/o-optimize/telnetd.exe
target remote 127.0.0.1:1234

load

(文件地址~/work/network-demos-4.9.5/telnetd/o-optimize/telnetd.exe地址也要根据你的情况变一下，你懂的)

这样就可以了。注意，不要在DDD里输入RUN命令，否则，会引起gdb异常动作，造成mini2440的模拟器推出，导致失败。可以手动输入c 命令和 step命令，右侧的DDD面板上是快捷命令你可以使用，但同样，不能点击Run命令。如果点击了，就导致模拟失败。这个特别注意。

我们可以双击代码区，设置断点。如下图所示，可以选择information,然后点击display,在框中出现information的地址，选择显示的information，再次点击display,会发现系统把information结构的细节也列出来了。很好很强大啊。enjoy it.这样的跟踪，比手动使用gdb要好很多。 要简单很多。

我们谈完了mini2440的仿真调试后，我们来看看如何进行真实的硬件仿真。实际上这个问题异常的复杂，我的水平有限。gdb的调试是多种多样的。我曾经看到一篇论文，可以使用代码+UART的方式进行单步调试，思路是利用ARM的异常陷阱，进入单步。在异常的服务中写UART的通讯代码。论文我仔细读了，一些东西还未实践，就先作罢。这里我谈谈用segger公司的j-link来调试arm91sam9260的。

jlink一定要全版本的，支持gdb server,如果不支持gdb server的jlink，是没有办法进行rtems的板级调试的。上面我们讨论的qemu mini2440的仿真上用ddd调试，其实本质上没什么太大的差别。唯一的差别是，真实的板子，可能当前板子的状态并不适合运行要调试的程序。必须将板子调整到适合运行要调试程序的运行环境，才能仿真成功。仿真的mini2440没有这个问题，因为仿真代码并未考虑一些硬件因素。然而真实的板子，是不能不考虑的。对于arm9260，上电后，链接上jlink，打开gdb server,在ddd中输入：target remote 127.0.0.1:2331。(这个IP地址要根据实际情况变一下，不过端口号不用改)其他操作均相同。发现这样可能并不能成功的仿真，为什么呢？步骤没有错，问题在哪呢？

其实就是arm9260的工作状态可能并不适合运行当前的仿真代码。因为9260上电后是辅助时钟在工作，如果没有运行bootstrap或者bootloader，就可能出现，还是辅助时钟在工作。而非主时钟在工作，也没有初始化相关的硬件资源，比如说SDRAM等外设。程序直接上去，可能什么都看不到，就像死了一样。


这样，如果我们仿真的程序，只是用到了9260的一些片内资源，和SDRAM，最简单的办法莫过于。使用atmel官方的SAM-BA工具，选择at9260ek，选择jlink，只要sam-ba的主界面出现了就OK了。因为SAM-BA启动时，会运行一个jlink的脚本，用以初始化9260。主要做了：关闭watch dog,启动主时钟，配置sdram和复位电路。然后关闭SAM-BA，再打开segger的gdb server,这样，下面的步骤都和mini2440大同小异了。这样仿真就没问题了。这个过程中，目标板不能断电哦。

如果用到了9260一些内部硬件和用到了一些外部硬件，情况稍微复杂一些。atmel官方的sam-ba工具可能解决不了问题，(大多数情况下，上面的办法都可以搞定的，总有例外)。我们可以借用uboot工具，我们把bootstrap烧写到目标板上，然后安装uboot，配置uboot不启动应用程序，而是停止在uboot的命令行上。利用命令行，控制uboot初始化9260的硬件和片外的硬件。完成后，下面的步骤也和mini2440一样。

第一个方法是属于atmel一家芯片的独门解决方法。而第二个方法则属于通用的方法，效果很好很强大。童鞋们在学习过程中应注意在多平台上实践体会。过程不难，但是细节较多，应反复实践，多多体会。