解决结果.DOC

案例描述 在调试过程中，当MPC8377把所要加载的程序通过PCIE加载到C6678相应的内存地址时，发现6678没有启动。可是按照以往的经验，只要向C6678的MAGIC_ADDR写上程序入口地址时，C6678应该就会根据写入的程序入口地址，从该地址运行程序。 首先我们怀疑的是MPC 8377没有正确的把代码拷贝到C6678的相应位置，我们随机挑选了几个内存地址存放的值，然后用仿真器连接C6678，查看相应位置的值，发现和所存放的值反了，后来想到MPC8377是PPC架构，所用的是大端数据，而6678用的是小端数据，发现错误后，在MPC 8377端改写了PCIE加载程序，改完以后加载C6678，可是加载完以后程序还是没有执行，再用仿真器查看内存地址，这下内存地址所放的值和所要加载的值一模一样了，可是为什么程序还是没有运行呢！为了进一步验证代码加载的没有错误，我们用PCIE加载C6678代码，用仿真器连接C6678，通过仿真器强行把PC指针指向程序入口地址，运行C6678，程序运行起来了。这下可以断定PCIE加载程序没有错误，到底哪里出了错？ 调试到这里想到了一开始熟悉C6678资料时，文档中有提到过IBL的存在，当时产生过怀疑，但是后来在C6678研讨会上，TI技术支持回答说在使用PCIE加载时不需要IBL。可是调试到现在确实出现了问题，发邮件给TI技术支持，他们答复说PCIE加载启动不需要IBL的参与，这下又晕了。调试了几天后来实在没办法了（调试不出来，资料上明明有IBL的存在）。在E2E网站上，询问了TI的工程师，他们解释说他们的PG1.0芯片存在PLL BUG，必须要在PCIE加载之前运行一段初始化程序（IBL）。这下好了，果真需要 IBL，什么是IBL，它到底有什么作用？ 案例分析 这里我们首先介绍一下IBL的相关知识。 2.1 IBL简介 IBL: 1st stage and 2nd stage Bootloader for booting an application from the NOR/NAND flash or Ethernet over I2C EEPROM. 在TI的EVM板上，IBL被存放在地址为0x51的EEPROM中，因为PG1.0芯片存在PLL BUG(refer to C6678 errata document, February 2011, advisory 8),IBL 做了一个PLL复位的规避程序。 我们的APU2板子，设计使用PCIE启动方式，因为芯片PG1.0存在PLL BUG，所以当PCIE把代码拷到C6678指定位置并且把代码的启动地址写入幻象地址，C6678没法自己运行代码。所以用PCIE启动时，C6678的幻象要用IBL来检测。 2.2 IBL运行流程 在EVM板上面，C6678的bootmode PIN是有FPGA控制的。用户配置启动方式的开关是连接到FPGA上的，有FPGA采集bootmode PIN的配置。 IBL流程：（这边主要介绍针对PCIE启动方式） FPAG采样bootmode pins。 FPGA 强制 DSP 从地址为0x51的EEPROM启动。 PLL通过EEPROM中的IBL正确初始化。 IBL从FPGA的寄存器中读取采集来的启动模式。 IBL判断启动模式，如果它不是I2C启动或是从地址为0X50的I2C启动，IBL写bootmode值到DEVSTAT。 然后IBL判断bootmode，如果是PCIE启动，IBL执行一些PCIE规避程序去配置PCIE寄存器，然后进入while（1）循环，侦测幻象地址。 2.3 IBL代码解读 IBL被设计为2段bootloader，iblinit.c和iblmain.c，两个文件中都有mian函数。iblinit.c主要用来进行PLL初始化，版本1.0芯片的PLL BUG规避（我们PCIE启动的话主要在这个阶段完成）。Iblmain.c主要是处理NAND/NOR/TFTP启动（The ibl main is the main bootlaoder that does pulls ELF data from the boot device (NAND/NOR/TFTP ..) and launches it.） 1.在iblinit.c中的mian（） 根据makefile的编译参数进行SPINor或I2C的初试化，然后进行C6678 PLL配置等。 然后进入iblEnterRom ()函数： 2. 在c66xinit.c中的iblEnterRom () 这个函数主要进行C6678的DEVSTAT寄存器的设置，程序读取FPGA采集到的bootmode来对DEVSTAT寄存器（描述启动方式的寄存器）的设置，并且判断