原创 [博客大赛]U-Boot for AM335x (12) Linux kernel下关于ARM的DT

U-Boot for AM335x (12) Linux kernel下关于ARM的DT

之前解压内核的时候，到一半会被卡住，提示信息：
Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.

在网上找答案，发现这个错误与文件系统相关。于是将Forlinx编译好的内核和文件系统放到SD卡上（放置文件系统的时间比较长，使用Disks工具观察它确实不busy了之后再umount），重新上电启动，发现Linux Kernel正常解压，文件系统和液晶屏也能正常工作。哦耶～～～so，U-Boot的调试可以告一段落了，接下来是编译自己的Linux内核，以及编译自己的文件系统。懒得再想新的题目，so，这些部分也会放在《U-Boot for AM335x》系列里面。

另外，要portingU-Boot，除了官方手册之外，TI官网提供的这篇文章也相当有帮助：
http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide
哦耶～～～

==============================================
编译自己的Linux Kernel并不会是一件非常顺利的事情，在这之前我已经尝试了很多次，但基本都无法正常运行，有可能是因为我配置的选项不对，也有可能是因为使用的内核版本过高，但是使用最新版的内核mainline编译出镜像porting到自己的电路板上，是一种无法抵挡的诱惑。所以，这次在调试完U-Boot之后，我准备再尝试一次。

http://processors.wiki.ti.com/index.php/AMSDK_Linux_User%27s_Guide
这是TI官网提供的guide，里面的步骤并不是单纯基于mainline，而是添加了TI公司的am335x_evm板的target代码。我要做的是从mainline里面编译出来可porting的镜像，所以不会直接使用TI提供的内核包，而是从Linux Kernel官网下载的最新版本的stable内核。虽然mainline里面本来就有TI公司贡献出来的代码（除了开源社区之外，TI公司对kernel的贡献是相当大的，果然不愧是我心中的NO.1），但是作为一名有着程序猿洁癖的硬件工程师，always choose the mainline!

http://free-electrons.com/doc/training/linux-kernel/slides.pdf
另外还有这篇pdf，free-electrons的教程，very good!不过它描述模块居多，kernel编译较少。

http://elinux.org/BeagleBone_and_the_3.8_Kernel
"Famous Linux rant about ARM churn"
"What has been decreed is simple: 'No more new ARM board files'"
原来ARM在Linux内核下的分支实在是太乱了，据说Linux之父Linus还为此怒吼，怪不得现在在mainline下几乎找不到target和board，而是变得非常干净，这增加了porting的难度（实际上这几天调试的几乎毫无进展，anyway，没有希望也是得继续的。。。）另外，从这篇文章里面知道，3.8之后的内核采用了新的DT策略来描述硬件，而不是board，so这也是要学习的地方：以往board是使用probe函数以类似模块的方式加载，但是DT并不是这样工作的。

神马是DT？

在ARM machine下，比较重要的文件是arch/arm/mach-omap2/*，所有的pinmux和timer/clock驱动都在这里了，而且是所有的ARM架构共享的，其它的通用驱动还是放在drivers/*中。

以前用来描述board的文件全部不再使用，取而代之的是DTS file，每一块板子都会拥有一个*.dts文件，它通过DTC compiler来编译（所以会发现它的格式并不是传统的C），生成DTB format (flattened device tree format)，然后内核会在boot时解析它，以此创建devices。

相应的driver/*文件也是要修改的，观察drivers/gpio/gpio-omap.c文件，会发现它的格式和以前有些不太一样：
static const struct of_device_id omap_gpio_match[] = {
        {
                .compatible = "ti,omap4-gpio",
                .data = &omap4_pdata,
        },
        {
                .compatible = "ti,omap3-gpio",
                .data = &omap3_pdata,
        },
        {
                .compatible = "ti,omap2-gpio",
                .data = &omap2_pdata,
        },
        { },
};
MODULE_DEVICE_TABLE(of, omap_gpio_match);

像上面这样描述的driver，即支持platform data model，也支持DT method。虽然使用纯DT method能获得更大的灵活性，但目前还是会两种都支持。使用DT method，能够在不需要重新编译内核的情况下配置board，这是a pretty big usabiliy gain。

总而言之，DT核心的变化是：
In summary, the core of the change to DT is that logic that was previously accomplished in board files is moved into a mixture of generic frameworks, abstracted devices drivers, and data to drive that software.

怎么使用DT呢？

DT在内核中由dtc工具编译，生成*.dtb文件；这个文件不是由内核调用，而是由u-boot.img调用，在U-Boot的官方手册里面《7.2. Flattened Device Tree Blob》就专门说的这个，本系列下一节就是具体的实现步骤。