Posted inCrossCompile

Cross-compile pciutils

目前busybox的lspci不能显示足够可用的信息，需要重新交叉编译一个lspci。 下载pciutils源码 make 修改Makefile CROSS_COMPILE => ppc-linux- ZLIB => no DNS => no SHARED => no 修改lib/config.h和lib/config.mk 注释掉 PCI_ARCH_I386 PCI_HAVE_PM_INTEL_CONF PCI_HAVE_64BIT_ADDRESS 删掉lib下面所有的.o文件 重新make 搞定。
Posted inDebug PowerPC

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。…
Posted inDebug

Debug SK2000L

给客户做的一款低端板子，其实就是8241+5*DM9000。之前用的Intel的82551太贵了，而且已经停产。市面上其他网络芯片的厂商基本上也没有PCI总线的网络芯片。 板子到手后，5V、3V3、1V8，测量均无短路。 好的，上电电压正常，烧写CPLD，但是串口打印信息并没有按照想象的出现。问题麻烦了。 重新烧了一块FLASH，换了依然没有打印。 看来要动用重武器了。 测量复位、时钟输入、SDRAM时钟均无问题。看来PLL应该发挥作用了。 接着测量Boot Flash的CS，复位后有波形，但是会一直保持。难道是DM9000前面总线驱动的逻辑错了。 审阅了以下CPLD逻辑，果然有错误，改掉后在量CS，发现每次复位后只出现13次。 这个是不应该的，因为前面读u-boot应该会保持一段时间。拿公司另外一块同平台的板子测试印证了我的想法。 然后给郑州的一位同事电话，希望得到一些提示。结果很遗憾，答曰看启动配置。。。。。 这个是Copy的图，应该是不会有问题的。 难道还是CPLD逻辑的问题？我改了以后又用示波器测了一遍，应该没问题的啊。不会是开始烧坏了吧。算了，还是把不用的逻辑禁掉吧。 奇迹出现了，久违的启动信息出来了。看来就是逻辑问题。   接着配置了一路DM9000，probe成功，发送超时，cat /proc/interrupts无中断，量中断管脚是有的。怀疑是发送设置定时器，结果没有中断清除定时器。改回并行中断，ok。在改回去串行中断，ok。估计是'/IRQ1/S_CLK'在拷逻辑的时候忘了加反向。 之后5片DM9000全部找到。   TODO：u-boot下无法配置RCS2，准备飞线将RCS1和RCS2对调。   Added on 08/01/2011 PS: 悲剧，今天测量网卡速度只有30Mbps。
Posted inNXP

使用Keil编译NXP 2366的I2C问题

今天同事发现使用Keil编译器编译NXP 2366后，原本在用ADS编译可以正常跑通的I2C出现了错误。 访问RX8025的时候，写寄存器0为0xA0是没问题的，读RTC寄存器也没有问题，但是当写其他寄存器或者写寄存器0为其他数值时，总是会超时。加了一些调试信息，发现在写完第一个数据后，I2C总线无响应（既没有应答也没有无应答）。 怎么测试都不行。最后google之，发现有篇文章也是使用Keil编译后出错，解决方法是去掉优化。 于是……设置Keil不优化程序。 问题解决。
Posted inMicriμm

Micriμm TCP/IP收数据跑死

同事遇到的。 现象是使用Micriμm的TCP/IP协议栈接收网络数据时，接收任务跑死，但是其他任务，如一个定时打印的任务仍然可以正常运行。所以判定如下： 程序不会有取指或取数据异常，有的话程序会什么信息都不会有； 程序不会死在中断里，理由同上； 接收任务一定是pend在一个信号量上面了，不然不会出不来； 最后发现原来Micriμm使用单独的一个进程处理网络报文，类似与linux的Tasklet。而为这个进程开辟的堆栈空间太小，导致堆栈溢出，无法post信号量。   Q：Micriμm μCOS II的任务在堆栈溢出的时候不会导致整个系统跑死？还是溢出的时候正好没有干扰到其他进程？
Posted inDebug

BUG Fixed：中断上下文申请内存

今天客户反应我们的驱动在运行中还是会Oops，奇怪了。因为这个驱动我们之前是在我们自己的一个板子上做的，稳定性之类的已经验证过了，虽然现在的运行环境不是我们自己的版本，既然驱动正常加载，怎么还会出问题呢。 下面的是Oops信息： BUG: scheduling while atomic: swapper/0/0x40010100 Modules linked in: drv Pid: 0, comm:              swapper CPU: 0    Not tainted  (2.6.33.5 #19) PC is at __rcu_process_callbacks+0x68/0x3a0 LR is at __rcu_process_callbacks+0x68/0x3a0 pc…
Posted inCF-Card Debug PowerPC

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! 呃。难道还有问题。…
Posted inCF-Card PowerPC

CF-Card拷贝数据出错

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

Solution of GDB issue "Program received signal SIG32, Real-time event 32."

今天客户使用gdb调试程序的时候出现问题。先是“no debugging symbols found"，google下发现是因为程序使用strip去掉了debug信息。 然后gdb显示"Program received signal SIG32, Real-time event 32." 继续google后，发现是因为用到的lib库被strip掉了。但是可以使用下面折中的方法： 在dbg prompt后键入"handle SIG32 pass noprint nostop"即可。