该项目是对公司设计的基于powerpc的处理器进行FPGA仿真阶段的软件验证，以及bootloader和kernel移植，以便芯片进行投产，主要完成的工作如下：
（1）调试环境的搭建
（2）处理器核功能验证，如异常 cache TLB等
（3）bootloader以及kernel中处理器基本外设驱动调试，如USB SPI I2C MAC SDIO UART等，kernel最小系统启动进控制台。
由于该项目处于预研阶段，并且FPGA仿真板数量不多，所以公司投入人力不大，只安排让我来做这个项目。
对我来说，莫大荣幸有机会来独立完成这样一项软硬件综合调试（各种硬件问题搞得我都快要奔溃了）
由于FPGA板很久不用了不稳定，加之各种硬件问题。折腾5个月的时间总算是将FPGA阶段工作完成。
但是在最后阶段USB调试通过，整个系统调试完成时，心里却有一种怅然若失的感觉，毕业工作之后一直萦绕我脑中的一个问题：
嵌入式开发调试，最后我到底学到了什么？
工作至今三年有余，翻看自己的csdn博客发现，刚工作时写博客总结，总是会关注一些具体代码细节，如C语言的变参宏定义 某个具体驱动的实现等。
工作2年后，更多的总结是一些有意思的代码框架，以及自己对问题的见解，如kernel的时钟机制，系统调用等。
这是一种进步。
但是今天我却感觉，对于嵌入式开发调试，学到的最重要的东西并不是上述这些知识，而是积累下来的思路和经验。
记忆力是有限的，我之前有过这样的疑惑：
做过一些项目，对于处理器及各种外设都接触调试过，但是再次调试还是需要对其datasheet，涉及的specification，以及软件代码进行复习。
做过项目的一些调试，写博客总结相关知识，但是一个月后，再看博客，跟看别人写的一样，顶多混过脸熟。
但是我却发现，虽然这样，但是我再次调试，却比第一次接触时要从容很多。
以最近两星期进行的一些外设模块调试为例。
但是我知道遇到问题，首先去排查哪个过程出错，枚举？class driver？ 硬件是否正常，示波器测phy给出的clock是否正确，phy的状态引脚是否正常。
实在不行，USB协议分析仪呗，抓下USB包，一个包一个包排查。
调试mac，TCp/IP协议我也只是脸熟，mac的datasheet我也得在熟悉下。
但是遇到问题，我知道首先确定phy自动协商完成了没，再将mac以及dma寄存器全部打印出来对比，将dma descriptor queue打印出来，根据状态描述符来查，怀疑硬件问题，可以采用mac以及phy的loopback模式来进行排除。总能将问题定位出来。
调试spi i2c uart，协议需要熟悉下。
但是遇到问题，spi 3根线，i2c 2根线，uart 4根线（调试串口，非全功能串口），示波器直接抓信号，对着协议和数据手册查，一定能找出问题。
等等。。
各种奇奇怪怪的问题，总能找到解决方法。
现在遇到问题不会像刚工作时那样手忙脚乱，因为我相信，各种调试工具，示波器，万用表，逻辑分析仪，协议分析仪，抓信号，量电压，软硬件结合调试，总会找到问题所在！
这些是在调试过程中积累下来的思路和经验，当然，工作3年初学者跟大牛的经验相比，还是有很长的路，需要努力学习。
但是却说明了，工作中学习知识之外，更多的是对解决问题思路和经验的积累。
所以以后就不要纠结于知识的遗忘，而应该注重解决问题思路的培养和经验的积累。
kerneler，不仅是为表明自己是内核系统开发者，更多的是希望自己成为一个追求事物本质的人！