海思3559万能平台搭建：DDR移植的一些问题

最新推荐文章于 2024-04-26 10:47:35 发布

快跑bug来啦

最新推荐文章于 2024-04-26 10:47:35 发布

阅读量2.2k

点赞数 2

分类专栏：海思3559 文章标签：物联网海思3559

本文链接：https://blog.csdn.net/qq_42330920/article/details/127076283

版权

海思3559 专栏收录该内容

45 篇文章 87 订阅

订阅专栏

前言：

开发板是绝对无误的硬件环境，但是我们平时的开发肯定会接触自己搭建的硬件环境，难免会有这样那样的小问题，这里给出一次DDR的调试过程

问题描述

海思3559开发板可以用默认配置表格生成的uboot拿hitool烧写进板子，进口追踪器用的和开发板一致型号的DDR，却不能直接使用。烧写时报错如下：
烧写时会打印###，过段时间提示发送数据帧失败
在这里插入图片描述

排查过程：

参考手册HiBurn工具使用指南，有打印了###后停止打印的情况，但是描述的是发送失败的是头帧不是消息帧。
在这里插入图片描述
还是了参考解决办法

单板型号选择肯定是正确的，更换过两个进口追踪器，也可以排除进口ddr本身的硬件问题。进一步开始怀疑ddr的配置是不是有问题？然后导致生成的uboot文件出了问题？

开发手册上还有另一种情况描述数据帧发送失败的情况。但又没有提及可以打印部分####
在这里插入图片描述
也参考了这个解决办法去查串口的硬件，和开发板对调串口排除了串口硬件和usb转串口驱动的问题
参考手册Hi3559A╱C V100 U-boot 移植应用开发指南重点排查uboot的生成：
在 Windows 下打开 SDK 中的“osdrv/tools/pc/uboot_tools/”目录下的配置表格。当选用不同的 DDR SDRAM 时，需要针对不同器件的特性，对配置工作表中的 DDR 相关标签页进行修改。

修改方法如下：

步骤 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，依然没有效果

降频

在这里插入图片描述
手册上说：
如 DDR4 有降频的修改，对应的 DDR4 时序参数也应做相应的调整，我们建议只调整自动刷新周期，其他参数可不作修改。因为在降频的时候其他时序参数都是往宽松的方向变化。
自动刷新周期的定义如下：

寄存器地址
通道 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
在这里插入图片描述

根据Makefile找到uboot编译链接的文件uboot.lds，再找到对应hi3559av100的start.S，

在这里插入图片描述
分析osdrv/opensource/uboot/u-boot-2016.11/board/hisilicon/hi3559av100下的hi3559av100.c

static struct mm_region hi3559av100_mem_map[] = {
    {
        .virt = 0x0UL,
        .phys = 0x0UL,
        .size = 0x40000000UL,
        .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
        PTE_BLOCK_NON_SHARE
    }, {
        .virt = 0x40000000UL,
        .phys = 0x40000000UL,
        .size = 0x200000000,//PHYS_SDRAM_1_SIZE,
        .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
        PTE_BLOCK_INNER_SHARE
    }, {
        /* List terminator */
        0,
    }
};

会不会是因为我们的映射偏大了导致ddr初始化阶段判定溢出了呢？
很遗憾单独修改映射大小后还是没有什么效果，检查手册
在这里插入图片描述

默认的uboot表格是4G，查看包里面的其他表格文件，2G是32bit的版本，应该没有其他默认的了，可能大小不需要更改其他配置，兼容性比较好吧？（对表格的怀疑在后面依然做了修改）

根据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里做硬件初始化的那部分
在这里插入图片描述
参考手册DDR参数配置

Hexdump读编好的uboot文件，能看到文件头是寄存器配置表格生成的地址以及对应的值，说明我们烧进去的head部分实际上可以理解就是配置表格，也有理由怀疑会不会和源码没有关系呢？只要把寄存器配置搞好了，正常来说硬件就可以初始化完成了呀
在这里插入图片描述
接下来开始把重心转移到配置表格里的寄存器都是干什么的和常规的DDR的工作原理上

DDRPHY

先补充下表格里没见过的名词，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 同时管理所有内存引脚的信号终结。并且阻抗值也可以有多种选择。并且内存控制器可以根据系统内干扰信号的强度自动调整阻值的大小。

在这里插入图片描述
可惜一个没找见
查看原理图的时候偶然发现了升级模式，难道和xilinx一样，进口ddr兼容性好，不需要烧写模式也能烧写但是国产的不行吗

很遗憾，这个怀疑依旧是不成立的
SOC手册上关于ddr控制器的操作流程如下
在这里插入图片描述
都做过没问题了啊