海思3559万能平台搭建:DDR移植的一些问题 | 您所在的位置:网站首页 › ddr4降频使用 › 海思3559万能平台搭建:DDR移植的一些问题 |
前言:
开发板是绝对无误的硬件环境,但是我们平时的开发肯定会接触自己搭建的硬件环境,难免会有这样那样的小问题,这里给出一次DDR的调试过程 问题描述 海思3559开发板可以用默认配置表格生成的uboot拿hitool烧写进板子,进口追踪器用的和开发板一致型号的DDR,却不能直接使用。烧写时报错如下: 烧写时会打印###,过段时间提示发送数据帧失败 参考手册HiBurn工具使用指南,有打印了###后停止打印的情况,但是描述的是发送失败的是头帧不是消息帧。 开发手册上还有另一种情况描述数据帧发送失败的情况。但又没有提及可以打印部分#### 步骤 1 完成配置表格的修改后,保存表格。 步骤 2 单击表格第一个标签页上的按钮【Generate reg bin file】或者使用 hiregbin 工具(详细使用方法请参考 osdrv/ tools/pc/uboot_tools/ hiregbin-v5.0.1.tgz 压缩包里的 readme 文件),生成临时文件 reg_info.bin。 步骤 3 将临时文件 reg_info.bin 拷贝到 SDK 中的“osdrv/opensource/uboot/u-boot-2016.11/”目录下, 并命名为: .reg,然后执行命令: make CROSS_COMPILE=aarch64-himix100-linux- u-boot-z.bin 生成的 u-boot-hi3559av100.bin 就是能够在单板上运行的 uboot 镜像。 分析一下烧写过程中都干了些什么 HiBurn烧入的基本原理是,HiBurn工具与BOOTROM程序建立连接之后,先下载uboot程序的开始4KB数据到海思芯片的内部RAM,然后通过下载的那一小部分uboot代码去初始化外部的DDR,如果DDR初始化成功,HiBurn再将剩下的uboot程序下载到外部的DDR中去,最后是在DDR中启动uboot,如果要进行烧入操作,是通过DDR中的Uboot程序,发送uboot命令将DDR中的uboot程序烧入到外部的flash中去,这样就实现了uboot程序的升级。 开始想到是不是需要正确对DDR进行设置呢? ReleaseDoc\zh\02.only for reference\hardware路径下有关于DDR的配置说明文档:Hi3559A╱C V100 DDR4 参数配置方法有关于频率的配置说明(硬件应该为2400MB但是默认和前同事的版本都是2666MB) 按照开发手册的步骤也尝试过2400MB,依然没有效果 降频
寄存器地址 通道 0:0x12068108 通道 1:0x12069108 寄存器描述 − Bit[10:0]:自动刷新周期 taref 自动刷新周期的时间计算公式为:T * 32 * taref,其中 T 为 DDR 的时钟周期。 以发布表格为例,默认配置值为 0xa0(十进制 160),DDR 时钟周期为 750ps(时钟 1333MHz,速率> 2666Mbps),根据公式计算自动刷新周期 750ps32160=3.84us,如把DDR 速率从 2666Mbps 降低到> 2400Mbps,则周期从 750ps 变为 833ps,如果需要保持自动刷新周期 3.84us,则 taref 应配置为 0x90(十进制 144)。对应 uboot 表格修改如下 阴差阳错下有次上电和少些的顺序点反了居然烧进去了经过多次重复实验,发现需要在上电的一秒内点击烧写就可以烧进去(也不能太快,否则hitool识别不到脉冲信号?),不能像开发板一样点击烧写烧写后的15秒之内给电 很明显问题没有查清楚,因为其他的板子没有这个问题,虽说是硬件问题但是具体原因还没找见 国产DDR 在后续的国产化ddr中同样的现象,这次怎么倒腾顺序也不行了,说明还是得搞清楚问题的原因,首先从代码开始着手查 在查Makefile想了解都编译了那些ddr相关文件时发现,最顶层是指定了DDR配置文件的,也就是说我们要是想一步到位编好uboot需要指定配置表格。同理替换了表格的话也需要修改Makefile里的文件名 在修改完代码或者配置后我们也可以通过make hiboot直接编译出uboot
会不会是因为我们的映射偏大了导致ddr初始化阶段判定溢出了呢? 很遗憾单独修改映射大小后还是没有什么效果,检查手册 根据JEDEC标准,ddr4是支持指令真值表的。看soc手册,DDRC 接口时序满足 JEDEC 标准,通过发送 DDR4/LPDDR4 SDRAM 的命令字,完成对 DDR4/LPDDR4 SDRAM 的数据访问和状态控制, 直接烧写 /osdrv/opensource/uboot/u-boot-2016.11/drivers/ddr/hisilicon/default/cmd_bin/ddr_cmd.bin到ddr 对比国产的和进口的ddr差异 生成的uboot实际上是有配置表格生成的bin文件和我们常规意义上的uboot打包的,且生成的.reg二进制文件靠前的,也就是首先要烧进ddr里做硬件初始化的那部分 先补充下表格里没见过的名词,ddrphy是什么? 首先我们可以这样假设:在时序确定的情况下,芯片中的数据传输信号,是可以直接通过IO传输给内存的。 问题就出在这个时序上面,因为芯片不同,IO和封装的延时都有可能不一样,PCB单板不一样,PCB上的延时也很有不一样,所以上述理想的传输场景是很难出现的。为了应对这种不确定性,DDRPHY应运而生。 DDRPHY就是一个能让DDR地址命令以及数据线按照协议规定正确传输的通道。 是的,他只是一个通道。 既然是这样一个通道,那么他一定包含如下的模块: 1、为了能够补偿这些不确定的延时,针对不同的信号,他一定有个可以灵活配置的延时电路以及对应的辅助逻辑。 2、第1点中的延时电路的具体延时会随着电压和温度的变化而变化,那么他一定会有一些对这些延时电路延时进行校准的模块。 3、根据上述描述DDRPHY一定会和IO正面交锋那么一些对IO的时序和控制逻辑也是必不可少的了。 阻抗匹配check手册里之前没检查到的驱动和odt配置: 检查阻抗匹配,却发现所有的接口都是参考开发板直连的,不能理解这里驱动的电阻值是怎么得来的 主板终结是一种最为常见的终结主板内干扰信号的方法。 在每一条信号传输路径的末端,都会安置一个终结电阻,它具备一定的阻值可以吸收反射回来的电子。但是DDR2 内存的工作频率偏高,这种主板终结的方法并不能有效的阻止干扰信号。若硬要采用主板终结的方法得到纯净的 DDR2 时钟信号会花费巨额的制造成本。 ODT 是 On-Die Termination 的缩写,其意思为内部核心终结。从 DDR2 内存开始内部集成了终结电阻器,主板上的终结电路被移植到了内存芯片中。在内存芯片工作时系统会把终结电阻器屏蔽,而对于暂时不工作的内存芯片则打开终结电阻器以减少信号的反射。由此DDR2 内存控制器可以通过 ODT 同时管理所有内存引脚的信号终结。并且阻抗值也可以有多种选择。并且内存控制器可以根据系统内干扰信号的强度自动调整阻值的大小。
当软件查无可查时,硬件终于发现复位信号是由海思的看门狗给出两秒一次,复位信号引错了!!!很明显不对,但到这时已经耽误了大量的时间,明明接一下示波器一下看出来很简单的问题,如果通过穷举排除一一验证带来的工作量还是很大的 再次吸取经验教训,当基本的状态都有怀疑时,要先查硬件的电源,时钟,复位 |
CopyRight 2018-2019 实验室设备网 版权所有 |