Windows下u-boot-2011.03在Mini2440移植详解(2)

SDRAM中调试uboot
本部分代码下载地址在文章最后。
进入调试状态前必须安装Jlink的驱动。之后上电mini2440开发板，运行J-Link GDB Server via JTAG，如下图。



然后在Eclipse单击

下箭头，选择u-boot-2011.03

进入调试状态。如下图，代码停在了_start
0x33000000处。



如果觉得在Eclipse看代码费劲，可以参考/article/8001752.html，里面使用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结尾，说明后面还有其它的信息。



这两个网址有助于uboot-Ram结构的理解。
http://blog.chinaunix.net/uid-22841689-id-3585932.html，
/article/10806107.html
本部分代码下载地址：360云盘http://yunpan.360.cn/，在《Uboot相关代码》文件夹里的《u-boot-2011.03_SRAM调试.zip》文件。

《u-boot-2011.03源码无修改.tar.bz2》是从官网下的无修改代码。