在刚刚开始学习u-boot的移植的时候，自然是从网上下载源代码，然后从网上找一些别人移植的经验，然后根据别人的方法一步一步地去改，当然我也是这样做的。但是这样做就有个问题，当你按照别人的办法修改好了u-boot，好不容易把编译时的错误都排除掉，编译链接通过，然后通过并口download到nandflash上，一上电，如果串口有输出，那么恭喜你，你很幸运，但这种情况的概率很少，绝大多数情况下串口都没有输出的，甚至连LED调试灯也没有亮。这时候你的心情可能会很低落，因为你可能活了好多天(如果你不是仅仅照搬别人的步骤的话)，但是最终什么也得不到，情绪肯定很lonely。
对于造成上面所说的情况，我想大多都是因为我们根本就不知道程序跑到哪里了？串口没有输出，LED灯不亮，到底是我们写的程序有问题呢？还是程序在某个地方死循环了，根本没有跑到点亮LED灯的地方，甚至程序有没有开始跑，都不知道。这样我们就需要调试了，我们在程序的起跑点加个LED灯的现实程序，确认LED灯显示起来了，然后就利用LED灯一步一步跟踪下去，直到串口有输出为止。
调试的方法我们找到了，但要看这种方法话不划算。首先确定，这种调试方法肯定要经常更改LED灯的点亮位置和点亮方式，如果这样，就有一个问题，你想想，你在程序里没添加一段LED灯的调试程序，或者修改LED灯点亮的方式都要通过并口重新把u-boot烧写到nandflash里面才能运行，暂且不计较你耗掉nandflash的青春(要知道nandflash的烧写次数是有限的)，也不计较经常要做插拔并口线这种麻烦事，光是时间你就耗掉不起。
既然那种调试方法在时间上有问题，那么就要解决。当然就想能不能找到一种方法，不把u-boot烧写到nandflash上去，而是直接把u-boot放到SDRAM上运行，好，想到方法就要去试试，把开发板自带的u-boot烧回nandflash，然后启动u-boot，通过tftp服务把u-boot下载到SDRAM的某个位置(我是把它下载到 0x30080000的地方)，然后 go 0x30080000运行程序，结果在程序起跑点添加的LED灯控制程序跑起来了，说明自己编译的u-boot已经开始跑了，但是程序后面的某些LED灯的控制程序没有跑起来，没关系，我们从程序起跑点一步一步调试。反正不用烧写nandflash，调试还不容易？
经过跟踪调试，发现在调用函数levellow_init前的LED灯控制程序执行了，但levellow_init后面的没有执行，仔细分析一下levellow_init,它是跟SDRAM的初始化有关，也可以说跟内存的分配有关，那么跟u-boot的启动也有关。
详细分析levellow_init,在u-boot编译的根目录下，打开System.map，查看levellow_init的地址，离起跑点的距离没有超出4k范围，这样就排除由于地址分配导致levellow_init跑不通。
这时候该把自己编译的u-boot烧写到nandflash里面，看程序能不能跑过levellow_init了，证实是可以的，这样得出结论，跑不过levellow_init可能是因S3C2440的Steppingstone 技术(请参考S3C2440 datasheet的第6章)引起的。
那样的话，我们可以模仿Steppingstone技术，具体实现如下：
1. 把开发板自带的u-boot烧回nandflash。
2. 修改u-boot的TEXT_BASE地址，也就是起跑点地址，把config.mk里面的
TEXT_BASE=0x33f80000 改为TEXT_BASE=0x30010000
3. 把start.S里面的u-boot代码relocate(u-boot代码重定向或把u-boot从nandflash拷贝到SDRAM)部分注释掉。
4. 重新编译u-boot，把u-boot拷贝到tftpboot目录下，
#make clean;make
#cp -f u-boot.bin /tftpboot
5. 在启动开发板自带的u-boot情况下执行下面命令：
tftp 0x30100000 u-boot.bin
cp 0x300100000 0x000000000 0x1000 /*说明0x1000=4096也就是4k，为什么是4k，见Steppingstone*/
go 0x00000000
这样就实现了不用烧写nandflash直接从SDRAM调试u-boot了。