返回信息流利用uboot启动内核kernel，但是刚启动uboot之后就卡住了，分析代码和现象，利用jtag调试，发现拷贝nandflash中二进制uboot数据到内存中之后，比较内存与nandflash二进制数据是否相同，结果不相同失败，然后死循环卡住的。
分析在内存中的数据出现有规律的错位问题，于是修改uboot用于测试，进一步证明确实是有规律的错位问题。如附件，代码中实际上是从地址0x57e00000开始，使用以下16个字节循环写入内存中，（E1FB0050--DA04FFFE--0050E1FA--6EE5CC(I++)），（I++）初始化为0.但是发现对于最低4位地址的数据，把地址4--7的数据写到了c---f中，而把c---f的数据写到了下一行的4---7地址中。
希望有类似开发经验的人给点提示。
谢谢了
这是一条镜像帖。来源：北邮人论坛 / embedded-system / #10758同步于 2011/6/22
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Embedded_System机器人发帖
求助，写数据到内存中出现有规律错误
AuGust0806
2011/6/22镜像同步16 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
看来是读写内存出错了吧
希望澄清几点，有助于分析问题
1、看描述应该是uboot都启动完？启动到什么位置了？
uboot能输入命令了吗？可以把已有的uboot打印发出来看看。
2、是否能单独确认flash和内存的读写是正确无误的。
比如可以在uboot中加些调试语句做flash和内存的读写测试，多写一些地址，写入不同的数值，然后读出来比较。
注意：flash的读写测试和内存的读写测试分开进行，以便隔离问题。
对了，还有一点
是自己做的板子吗？如果是的话，可能有两点也要考虑
1、是否存在焊接问题，比如焊错了管脚，或者有虚焊
2、板子的配置是怎么来的，比如sdram的时序和频率等配置
【 在 hobby 的大作中提到: 】
: 看来是读写内存出错了吧
: 希望澄清几点，有助于分析问题
: 1、看描述应该是uboot都启动完？启动到什么位置了？
: ...................
1、uboot启动并未完成，在sram中执行uboot前4k的代码没有问题，这个执行中copy-uboot-to-dram出现了问题，拷贝之后对比两者二进制不相同，于是死循环卡住的。所以还没到执行命令这个阶段。
2、分别测试nand和内存，可以确定的是nandflash中的读写没有问题。内存的读写有问题，因为单独的往0x57e0000f写入一个字节数据，结果这个数据被写到了0x57e00017这个位置上了。
3、是自己做的板子，没什么经验，感觉焊错管脚的可能比较小，昨天也和同学检查了一遍，没发现问题。虚焊的可能性不大，因为出现错误明显错位，如果虚焊应该很乱，毫无规律可言（个人看法）。
4、寄存器的配置问题，有哪个寄存器的配置跟这种错位规律有联系吗.burstlength为4，cl设置为2，对着数据手册来设置寄存器的。而时序以及频率配置按照ddr sdram的配置来的。
感觉是sdram读写的问题啊,应该不是虚焊,否则会很乱的.也许是设计问题或者信号问题吧, 后者的话可以降频试试.另外再看看sdram的初始化吧.
【 在 AuGust0806 (APologize) 的大作中提到: 】
: 1、uboot启动并未完成，在sram中执行uboot前4k的代码没有问题，这个执行中copy-uboot-to-dram出现了问题，拷贝之后对比两者二进制不相同，于是死循环卡住的。所以还没到执行命令这个阶段。
: 2、分别测试nand和内存，可以确定的是nandflash中的读写没有问题。内存的读写有问题，因为单独的往0x57e0000f写入一个字节数据，结果这个数据被写到了0x57e00017这个位置上了。
: 3、是自己做的板子，没什么经验，感觉焊错管脚的可能比较小，昨天也和同学检查了一遍，没发现问题。虚焊的可能性不大，因为出现错误明显错位，如果虚焊应该很乱，毫无规律可言（个人看法）。
: ...................
前一阵我用CPU向DSP的寄存器写数，写出来的结果就是这样，后来找到原因是DSP boot没有成功，没boot成功的原因是CPU权限设置不对。不知道对你有没有帮助
【 在 vanxy 的大作中提到: 】
: 前一阵我用CPU向DSP的寄存器写数，写出来的结果就是这样，后来找到原因是DSP boot没有成功，没boot成功的原因是CPU权限设置不对。不知道对你有没有帮助
: --
权限设置？？这个是什么意思呢？能具体点吗，网上搜索相关内容也没结果呀？
【 在 ArmStrong 的大作中提到: 】
: 感觉是sdram读写的问题啊,应该不是虚焊,否则会很乱的.也许是设计问题或者信号问题吧, 后者的话可以降频试试.另外再看看sdram的初始化吧.
: 【 在 AuGust0806 (APologize) 的大作中提到: 】
: : 1、uboot启动并未完成，在sram中执行uboot前4k的代码没有问题，这个执行中copy-uboot-to-dram出现了问题，拷贝之后对比两者二进制不相同，于是死循环卡住的。所以还没到执行命令这个阶段。
: ...................
首先谢谢了。又作了一部分测试，将ddr的频率由133mhz降低为66mhz，这个有规律的错位错误消失了，但是还是uboot卡住了，出现了很小很小部分的随机错误，再将内存降低频率到33mhz，也是随机错误。请问，这个降低频率之后，错位错误消失是不是说明信号问题，这个信号问题指的是什么，是来自于硬件布线吗？
那就是说纯粹是SDRAM的读写问题了呗
如果有可参考的板子或设计，比照着查一查
软件上，找相关的寄存器配置。之前实验室做的板子用的是ppc的cpu，里面有很多控制内存读写的寄存器，可配置时序延时等。
硬件上，SDRAM有没有一些信号线是直接拉高或拉低的（例如控制芯片的工作模式），也查一查？
【 在 AuGust0806 的大作中提到: 】
: 首先谢谢了。又作了一部分测试，将ddr的频率由133mhz降低为66mhz，这个有规律的错位错误消失了，但是还是uboot卡住了，出现了很小很小部分的随机错误，再将内存降低频率到33mhz，也是随机错误。请问，这个降低频率之后，错位错误消失是不是说明信号问题，这个信号问题指的是什么，是来自于硬件布线吗？
之前好像有个什么芯片的时序控制，看手册不太懂，但是经过一些实验，找到一组比较稳定的配置，就那么用了。楼主要是没办法了也可以试试
大致的想法是：遍历所有配置，每组配置进行读写测试，找效果最好的。
例如A、B、C那个寄存器，那么就三层循环，在最内侧的循环里做读写测试。然后打印各组结果。
当然，前提是你的uboot能打印出来东西