Windows下u-boot-2011.03在Mini2440移植详解(2)_thread [1 thread 1 (cpu#0)] (suspended: signal 'si-CSDN博客

本文链接：https://blog.csdn.net/zisehuoxia/article/details/30542473

SDRAM中调试uboot

本部分代码下载地址在文章最后。

进入调试状态前必须安装Jlink的驱动。之后上电mini2440开发板，运行J-Link GDB Server via JTAG，如下图。

然后在Eclipse单击下箭头，选择u-boot-2011.03进入调试状态。如下图，代码停在了_start 0x33000000处。

如果觉得在Eclipse看代码费劲，可以参考http://blog.csdn.net/yicao821/article/details/6747454，里面使用Source Insight来阅读代码，还是比较方便的。

想在SDRAM中调试uboot，将uboot的CONFIG_SYS_TEXT_BASE = 0x33000000，单步调试发现uboot还会去relocate，这没关系，关键是relocate后，跳到新的uboot地址处时，程序就会suspend在下图位置中。总是接收到SIGTRAP。其中0x33fbd138是新的uboot中board_init_r函数的地址。

Suspended: Signal 'SIGTRAP' received. Description:Trace/breakpoint trap.

而0x33fbd18c感觉是有问题的语句，一直停到此句。而且copy前和copy后两个uboot中函数board_init_r内容不一样。如下表。不知道是什么原因导致的，还是，copy后就应该是这样？

Coyp 前	Copy后

如果copy前和copy后一致的话，全速运行，应该就能够看到uboot移植后的效果了，但目前copy后的，没有办法去调试。这是目前的理解。

@2014-04-09：今天调试时把所有的调试断点remove后就可以了全速运行了，难道是断点打到了后面的部分导致一直receive signal？莫非最开始也是这个原因？不过还是要说一下，即使可以运行，但跳转到第二阶段时，是无法去单步调试的，所以还是需要下面的方法修改。

为了能够在SDRAM中，做如下图改动。此时，就不会去执行copy了。

/arch/arm/cpu/arm920t/start.S

经过上述图片修改后，全速运行。串口输出如下。看起来好像挺正常的，还有待以后调试。

问题：正如上面所说，copy后uboot的地址r6会随着uboot的大小而变化，难道每次都得先调试查看r6的值，然后再将r6的值赋值给CONFIG_SYS_TEXT_BASE，再重新编译么？

答：想来应该不用这么麻烦，可以首先多预留些Ram的值给uboot，那么即使uboot的大小发生变化了，只要不超过之前预留的Ram大小，它的首地址都不会改变，这样就不用修改CONFIG_SYS_TEXT_BASE的值了。那么在哪里修改这个Ram的大小呢？

在arch/arm/lib/board.c文件的board_init_f函数里，gd->relocaddr = addr这个里面存的就是copy后uboot的首地址。addr最后赋值如下图。

CONFIG_SYS_TEXT_BASE修改在文件board\samsung\mini2440\config.mk文件中。

但这也不能完全保证r0与r6相等，因为你的uboot代码可能会很大，超过了预留的64kB对齐，不过只需要再设置的大些即可。调试时可以确认这些值的大小。下面给出了uboot第一阶段到第二阶段时的SDRAM结构图，上面的address地址不完全和现有程序对应上，但这个图也是基于uboot代码调试而来的。

图中寄存器R0、R1、R2，就是传给函数relocate_code (u-boot-2011.03\arch\arm\cpu\arm920t\start.S)的形参。relocate_code函数是在u-boot-2011.03\arch\arm\lib\board.c的board_init_f函数末尾调用的。

图中说uboot所用内容，但不包括__bss_end__之后的内容。通过查看uboot根目录下System.map文件，__bss_end__之后还包括__dynsym_start，__rel_dyn_end和_end结尾，说明后面还有其它的信息。