断断续续折腾了整整4天，u-boot终于移植成功！飞思卡尔的usb-tap
+ code warrior真是调试仿真神器！帮了大忙！
把u-boot从PPC某处理器移植到新的PPC处理器，更换了DDR2的内存，整个板卡也添加了不少新功能。整个过程大可以分为两个阶段，第一阶段是编写下载u-boot的配置文件。当板卡焊好芯片后，nor
flash中没有任何程序，需要使用JTAG来下载。开发PPC肯定用到飞思卡尔而的usb-tap和code
warrior IDE，选对了合适的开发工具可以使移植事半功倍。可是麻烦的是没有正版的licence，无奈只能一次次使用试用版。Code
warrior IDE里面集成了一个叫flash programmer的flash下载工具非常好用，支持多种型号的flash擦写，我们使用的是32M的
nor flash，high boot方式，足够存储uboot以及OS。这个工具可以通过读写下载配置文件（init.cfg）初始化PPC，包括基址寄存器、LPC总线位置、flash大小、时钟、norflash读写模式、屏蔽看门狗以及外部中断等，有必要的话还可以初始化内存以及其他外设。
写好配置文件就可以下载调试u-boot了，对于u-boot代码的移植以前已经写过，这里只想记录下在调试的过程中遇到的一些问题。开始接触u-boot不要被它庞大的文件结构吓到，其实对于一直来说，需要改动的也就那么十来个文件。
start.S的移植自然不用多多说了，最重要的就是做好flash
CS0的初始化，其实这一点在之前的init.cfg文件中已经做过了，这里还这样做的目的只是为了u-boot在内存中能正确初始化flash。
都说移植好串口就等于成功的一半，与串口比起来我觉得还是把memory map写对才真的事半功倍。对于一个新的CPU来说，如果各个外设的基地址映射错了，想让内核跑起来是比登天。与BSP不同，U-boot映射了CPU的整个Memory
map，如果多写或少写了其中一两个寄存器，以后的位置就全部乱套了。一个好的办法就是在flash中仿真的时候在cpu_init.c的最后一行设置断点，程序运行到这个地方的时候检测im这个结构体，看看各个外设的地址对不对。如果的话，下一步就要检查各外设寄存器了！code
warrior IDE提供了一个查看CPU register的工具，各个寄存器的状态一目了然。
在整个移植的过程中DDR2内存最为麻烦。如果更换了新型号的内存，最好找一块用到这个内存的开发板，查看其内存初始化顺序，比自己按照内存芯片手册写参数要简单的多。我就找了一个参考板，不过开始的时候开始也走了不少弯路。参考板是nand
falsh 启动模式，在下载配置文件中就提供了内存初始化的参数与顺序，以为按照这个参数和顺序写到fix_sdram函数中就可以正常初始化DDR2，结果让我郁闷了好半天。后来看了看相应的u-boot代码发现参考板初始化的顺序和参数居然和cfg文件不一样！我尝试把u-boot中的初始化顺序和参数移植过来，竟然OK了！究其原因，我认为是仿真器下载初始化CPU时速度相对于norflash中代码执行的速度是比较慢的，所以要在u-boot中对DDR2初始化的地方加更多的NOP和延时才能初始化成功。
然后是以太网，和大部分外设一样，最重要的只有两点：时钟和IO复用。以太网外围PHY芯片电路连接很固定，一般如果不是有新的要求，升级板卡时不至于换一个没用过的PHY芯片给自己找麻烦。IO复用和时钟设置好了，发现TFTP不能下载！查了半天原来是io_ctrl_gm这个位没有使能导致所有的管脚不能按照默认的功能输出，改过以后就成功了。
经过一番折腾，真觉得还挺有意思。