Port on Board DDR Chip on QorIQ T1&2 Series

FSL(Now is NXP) used DIMM slot on T1040RDB and T2080QDS board. And my company first customized board used DIMM also.

But, due to the reliability, we decided change DIMM slot to on board DDR chip, so I need make it work.

The fsl support one powerful tool named ‘Code warrior’ and it has a plugin named ‘QCVS’. We can validate DDR configurates by it. See Ref.4 for more information.

After validate, we should make some change to U-Boot.

First add ‘CONFIG_SYS_DDR_RAW_TIMING’ defined in board config.h file.

T104x SD/MMC boot research

PBL -> load RCW (64 bytes/512 bits) -> write to RCWSRn cfg_rcw_src [0]_[1:4]_[5:8] -> 0_0100_0000 cfg_rcw_src用以决定RCW配置字的来源 RCW[PBI_SRC]用以决定PBL初始化控制器的类别 SD启动,起始地址为0x0000_1000,SD Card block size 512KB Useful macros: CONFIG_SYS_FSL_PBL_RCW CONFIG_SYS_FSL_PBL_PBI Reference https://pagure.io/u-boot/raw/2015-07/f/board/freescale/t104xrdb/README u-boot:board/freescale/t104xrdb/README

FreeScale QorIQ Build failure

编译fsl的QorIQ的时候可能会出现如下错误: | checking for gnumake... make | checking version of make... 4.0, bad | checking for gnumsgfmt... no 目前发现类似的还有makeinfo。系统为dabian 8.0 其实是fsl配置的时候判断过于严谨。 根据编译上下文找到对应的configuration文件,修改 if test -z "$MAKE"; then ac_verc_fail=yes else #…

MPC8309 NAND Flash启动

之前我做了MPC8309+K9F5608U0D (16MB)的启动。一直想把移植过程写出来,后来耽搁了也没写。正好这次公司定MPC8309 CPU方案准备采用K9F2G08U0C(256MB)。移植完后就有了下面的文章。 前景提要 之前移植K9F5608U0C的时候可谓复杂。我们最早焊的是64M的K9F1208U0C,但是Freescale的Code Warrior上只有K9F5608U0D的选项。本着Dev的考虑,我认为1208和5608仅仅在与前者比后者多了几个Block,产品ID不一样,于是我试着改了一下Code Warrior的FPDeviceConfig.xml。 结果惊奇的发现在FPDeviceConfig.xml文件中,K9F5608U0D的manufacturerid是35,id是75。这个不合道理啊。如果按照Freescale的CWFLASHPROWP.pdf上所述,SamSung的manufacturerid应该是EC,id应该是75。于是我把manufacturerid和id来回调换,都不成。于是我直接直接换了一片K9F5608U0D,又找FAE要了他机器上面的K9F5608x0D.elf和K9F5608x0D_utility.elf。终于可以用CW烧写NAND Flash了。 移植K9F2G08SU0C 有了上次的经验,我试了一下CW自带的K9F2G08X0A。结果很悲剧,还是无法操作FLASH,我看了看它的manufacturerid和id,分别被设置成23和EC。还是猜不透。 我又翻读了AN3859.pdf文档,AN3859上说:"Samsung uses its own algorithm for flash programming, not compatible with other vendors"。如果本身自带的elf不行的话只有自己编写适合自己所用芯片的algorithem文件了。于是我找到了CW目录下的NAND Flash例程。而他的例程针对的是MPC8360和K9NBG08U5M,NAND Flash和我目前所用差距太大,直接在CPU上仿真发现老是进入取指异常。而查看它的源码有了点新发现。它的getFlashID实现中: [crayon-68033c2f21077262114034/] 看起来manufacturerid取的是第3个字节,id取的是第二个字节,于是我有来回倒腾manufacturerid和id。最终一无所获。 实在没有办法,我在Freescale的论坛上发了帖子。同时我试图先通过NOR Flash启动,然后在u-boot下将编好的U-boot下载到NAND…

Freescale MPC8309调试

10/09/2011 第一步是连接仿真器。 打开ltib默认的MPC8309配置,修改 DDR大小为128M NOR Flash为8bit OK,连接上仿真器,仿真器居然没有8309的选项,郁闷,下载了8309的补丁包,EPPC_8.8_830X_b101126.exe。安装,可以选择8309了。又在freescale上瞄了一下,CW8.8.5的patch可以支持win7,这是个好消息,因为之前都是在虚拟机用的,贼不方便。安装好patch,在按照说明装好了驱动,又拿8315的板子连了一下,通过。 好的,连上8309,擦写Flash,显示”连接失败”。新建一个8309的工程,点击Debug->connect,显示无法复位CPU或者无法将CPU置于DEBUG模式,看来是CPU没有正常工作。 郁闷了,检查8309配置,复位配置字为1100,没问题;JTAG设计也没问题;复位没问题;晶振也没问题。最后发现PCI_SYNC_IN没有和PCI_SYNC_OUT连接,导致CPU没有时钟。还好PCI_SYNC_IN通过一个下拉电阻引了出来,不然这个板子就废掉了。 将33M时钟飞到PCI_SYNC_IN上,在次连接一下,成功!擦除Flash,成功!校验Flash,不对。到底是没擦除还是校验错呢?还好Flash上Busy信号接了灯,在擦一下,发现灯亮了,所以应该是校验错误。因为8309和8315是一样的,将8309的NOR Flash配置改成与8315一样。校验成功! 接着烧写u-boot,改为NOR Flash启动,串口显示启动信息,但是出现”Error in I2C Direction reg read”,搜索u-boot源码,原来freescale公版会先读一个EEPROM。注释掉。 这次显示了”Not a microcode”,然后就在打印NET:后停掉了。跟踪了代码,发现是在初始化QE的UEC的时候执行初始化TX&RX的时候一直没有等到命令执行完成。会不会和”Not a microcode”有关呢。查看源码发现这个是因为u-boot给QE下载微代码的时候打印的,因为我的u-boot是没有这个微代码的。但是后面程序有设置启动微码指令,注释掉。发现还是这个问题。 10/10/2011 难道是QE输入时钟的问题,我们接的是33M的,6倍频到198M。公版是25M,8倍频到200M。而MII的时钟是25M。 换成25M时钟,修改QE PLL倍频,发现还是一样。 会不会是8309必须需要一个微码呢?google、看QE的手册,没有什么可用的资料。在次检索ltib,突然在tools_8309som下面的nor_flashing目录下面发现一个好东西”iram_mpc8309_r1.bin”。哈哈,找到了。用USB TAP烧写到指定位置。”=>”提示符有了。ping了一下地址。发现没有读到PHY ID。…

CF-Card拷贝出错——续

终于解决CF卡出错问题了。先记录如下: 当我在板子上面对主机的文件进行MD5校验的时候惊奇的发现同一个文件在板子和主机上面居然MD5也不一样。主机的目录是用NFS mount到板子的。那么就有可能有2个原因: 网络错误 内存错误 NFS服务我是相信的,不然不可能用的这么广泛。那么只有一个可能,内存有问题。 于是换了一个板子。mount后md5文件,与在主机的MD5值一样。好的。这事内存问题。那么拷贝文件出错是不是也是内存影响的呢? 重新拷贝,md5sum后发现与主机一样。KO。搞定了 做了一夜的拷贝、md5sum、删除,CF卡都依然坚挺。看来是内存问题了。折腾了我好久。郁闷~~~~~ 手头还有一个Kingston的256M的CF卡,插上去试试,发现在分区保存的时候打印下面的错误: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } hda: task_no_data_intr: error=0x04 { DriveStatusError } hda: Write Cache FAILED Flushing! 呃。难道还有问题。…

CF-Card拷贝数据出错

整理了一下前几天给客户的DOC2CF。 当我把CF卡的文件在拷贝到主机后,发现了一个问题:拷贝到CF卡中文件的MD5和拷贝前的MD5不一样。这个是一个隐患,也就是说现在的CF卡是不稳定的,很有可能出现DOC同样的错误。 首先解决的问题是,这个文件是拷进来的时候出错了还是拷出去的时候出错了。 拷贝文件到CF卡后把卡取出,通过CF卡读卡器在电脑上校验发现MD5错误 把CF卡中的文件拷贝回电脑发现CF卡的文件和电脑里文件的MD5一样 结果是CF读是没有问题的,问题在于写CF的时序。

MPC8315复位方式

MPC8315有2个复位信号管脚,PORESETn和HRESETn。 PORESETn是一个Input Only管脚。HRESETn是Input/Output管脚,并且是一个开漏输出管脚。 Power-On Reset Flow MPC8315 PORESETn 有效则开始对CPU进行复位。PORESETn必须有效持续32个输入时钟。 当PORESETn无效后,立即开始配置步骤。芯片在power-on reset过程中一直使HRESETn有效。配置时间根据配置源和SYS_CLK_IN(PCI host模式)或者PCI_CLK(PCI agent模式)的频率。首先,采样复位配置输入管脚以决定配置源和时钟分频。接下来,芯片开始加载复位配置字。系统PLL按照复位配置字的低位锁定时钟。当系统PLL锁定后,时钟模块开始在芯片内分配时钟信号。同时,核PLL开始锁定。当它锁定并且载入复位配置字后,HRESETn被释放掉。 Hard Reset Flow 当外部使能HRESETn或者内部当芯片探测到产生一个内核硬复位流程时,HRESETn开始有效。在这两种情况下,芯片保持HRESETn有效在HRESETn状态。硬复位流程时间根据配置源和SYS_CLK_IN(PCI host模式)或者PCI_CLK(PCI agent模式)的频率。硬复位不会采样复位配置输入管脚(CFG_RESET_SOURCE和CFG_CLKIN_DIVn),它们被采样仅仅在power-on reset。所以芯片立即开始加载复位配置字并且配置芯片。当配置过程完成后,芯片释放掉HRESETn并且退出HRESETn状态。一个外部的上拉电阻应该使这个信号无效。