摘要
要写优质的教程，让别人看得懂的教程，才有价值。
而关于如何写教程，举个例子：
看了这个：
后，所想到的：
如果我去写对应的该部分的内容，那么应该是：
- 先去解释说明，当没有Linux，Uboot等各种框架时，裸的驱动，是如何实现的
最好把全部代码贴出来
或者至少把驱动核心部分框架和核心代码贴出来。
- 然后再去说，对于这样的裸驱动来说，其全部的活，被（Linux，Uboot等）框架，做了哪些
只有搞懂了，框架帮你做了哪些了
然后你才懂，余下来的事情，就是自己需要实现的了。
- 搞懂需要实现哪些接口函数
再去一点点，搞懂函数的接口和内部实现的逻辑
然后再去写代码，一点点实现
再去边调试边写驱动的代码
网上有很多嵌入式教程写的都不够透彻，没将明白要修改文件背后的逻辑，为何要这么修改。
比如：mini2440 u-boot-2009.03 移植最详细攻略
说实话，已经写的，算是步骤相对比较详细了。
但是：
最核心的，最根本的：
如何移植，为何要改这些文件
以及背后的逻辑，都没有解释
导致的结果：
除非本身对这方面的移植已经有概念的
否则，很容易看着一头雾水：
感觉就是：
这个文件改改
那个文件改改
而且为何这么修改，往往解释的也不够清楚和详细
使得：
如果自己拿到对应的源码，对应的硬件
对于如何移植，还是一头雾水
所以，抽空自己去：
亲自折腾一遍移植
并且详细记录步骤
如果要修改文件或其他地方
一定要解释清楚背后的逻辑
然后等移植完毕
再花时间，搞懂uboot的框架
搞懂如果从头到尾，自己亲力亲为，从无到有的，去移植Uboot
背后的逻辑是啥
需要关心哪些功能
这些功能Uboot中已经有了什么（框架，驱动）了。
还需要我们去实现哪些东西
以及，具体再解释，针对每个要改的功能模块
自己应该如何去改
所以要：
思路清晰
再去下手
否则：
永远都是：只能照葫芦画瓢，而且画的还不像
只有：
自己搞懂逻辑和概念了，
才能：
不仅可以快速高效的，照葫芦画瓢，而且如果需要，也可以自己从无到有的去涉及一个葫芦或一个瓢（可供别人当参考）
结论：
抽空先自己搞懂如何移植Uboot，然后再抽空整理出思路和有参考价值的教程。
 |  | |
| 16.1.1. Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers |  | 参考书目 |
