porting

我们在[1][2]中提到过，鉴于gpio的特殊性，pinctrlsubsystem特意留了一个后门（gpiorange），gpiodriver可以通过这个后门直接向pinctrlsubsystem申请将某个pin用作gpio功能。本文将根据一个简单的示例，介绍这个后门的使用方法，以加深对相关机制的理解。

注1：本文的测试方法和[3]中的一致，即：通过gpiolibsysfsapi控制LED0（GPIOA19）的亮灭，因而不再罗列详细步骤。

本文将基于本站GPIOsubsystem[1]相关的文章，结合”XProject”的开发过程，实现一个简单的gpiodriver，并利用gpiolib提供的sysfsapi进行简单的测试，进而加深对gpio相关概念的理解。

注1：本文后续的描述，kernel基于本站“XProject”所使用的kernel版本，硬件基于”XProject”所使用的“Bubbugum-96”平台[2]。

本文是“linux内核中的GPIO系统之
（4）：pinctrl驱动的理解和总结”的一个实例，结合”XProject”的开发过程，介绍pinctrldriver的移植步骤，进而加深对pinctrlframework的理解。

注1：本文后续的描述，kernel基于本站“XProject”所使用的kernel版本[4]，硬件基于”XProject”所使用的“Bubbugum-96”平台。

本文将基于“Linux时间子系统之（十七）：ARMgenerictimer驱动代码分析[1]”，以bubblegum-96平台为例，介绍ARMgenerictimer的移植步骤。

另外，我们在[2]中完成了ARMGIC驱动的移植，但还没有测试是否可用。刚好借助timer驱动，测试GIC是否可以正常工作，顺便理解Interrupt的使用方法。

“XProject”完成“X-012-KERNEL-serialearlyconsole的移植”之后，终止在如下的kernelpanic中：

NR_IRQS:64nr_irqs:640Kernelpanic-notsyncing:Nointerruptcontrollerfound.---[endKernelpanic-notsyncing:Nointerruptcontrollerfound.

结果很明显，系统中没有注册中断控制器。因此，本文将以“Bubbugum-96”平台为例，介绍ARMGIC驱动的移植步骤，顺便继续加深对devicetree的理解和认识。

注1：由于“Bubbugum-96”的GIC符合ARM标准，Linuxkernel中相关的驱动是现成的，因此GIC驱动的移植就非常简单了，只要配置一下devicetree即可。

本文将以“XProject”的“【任务3】Linuxkernel的配置、编译、加载与启动”为契机，介绍将Linuxkernel移植到一个新的平台上的基本步骤，包括kernel以及devicetree的配置、编译、二进制文件的生成等。

注1：本文的硬件基于ARM64架构，kernel基于“XProject”初始的“Linux4.6-rc5”版本

wowo觉得，在linuxkernel新引入的众多子系统中，pinctrlsubsystem是一个特别晦涩难懂的子系统，它所解决的问题，和它所引入的困扰，不相上下。在平时工作的过程中，年轻工程师问的最多的，就是在驱动中要怎么使用pinctrl？这样配置pinctrl到底是什么意思？等等。

对一个子系统来说，如果不能让它的使用者（consumer）很容易的理解和掌握，就宣告了它的失败。更不用说让它的提供者（provider）简单、快速地编写驱动程序了。

为什么会这样呢？通俗一点讲，就是“大炮打蚊子”。从技术的角度看，pinctrl是一个非常优秀的子系统，有着复杂而巧妙的封装和抽象，但它所要解决的问题，实际上非常简单、直白。这就造成了一个落差，从而带来了各种理解上的困惑。

正因为此，u-boot在照搬linuxkernelpinctrl的同时，额外提供了一种简洁的方法。本文将借助“XProject”u-boot中pincontroldriver的移植过程，介绍、分析这种方法，并以此理解pinctrl的本质。

与此同时，我们会基于“X-005-UBOOT-devicetree移植(Bubblegum-96平台)”，扩展对devicetree的使用，以加深对devicetree的理解和掌握。

我们在“X-004-UBOOT-串口驱动移植(Bubblegum-96平台)”中，简单介绍了u-boot中serialdriver的移植过程。由于serialdriver是u-boot移植中的第一个driver，为了方便debug，并没有引入devicetree。在serialdriverready之后，基本的console功能已经okay，基于此，我们可以着手增加devicetree功能。

很久以前，我们在博客上写了三篇devicetree的分析文章（DeviceTree（一）：背景介绍、DeviceTree（二）：基本概念、DeviceTree（三）：代码分析），这些文章的目的是介绍devicetree背后的思想、原理、实现方法、等等，偏重于理论，相信给大家制造了不小的“心里压力”。

因此，本文将以“XProject”为契机，从实践的角度，以使用者的视角，介绍devicetree使用方法。相信通过本文，大家对devicetree的理解会上一个新台阶，达到化繁为简、随心所欲的境地。

话说现在的u-boot长得和linuxkernel越来越像，设备模型（drivermodel）、devicetree、各种framework（gpio、pinctrl、clock、i2c、regulator、等等），各种概念，均和linuxkernel保持一致。这对工程师（特别是linux驱动工程师）来说，是一个利好，因为熟悉了linuxkernel相关子系统之后，去搞u-boot基本上就毫无压力了。

不过，对“蜗窝”来说，压力（或者说矛盾）就来了：要不要为u-boot中相关的子系统写分析文章？写吧，实在提不起兴趣，毕竟和kernel类似，我们的重点又在kernel分析上。不写吧，不符合我们的风格啊！

对于“XProject”u-boot移植过程所涉及的driver模块，只写一篇移植说明，至于其它的，只能战略性放弃（当然，如果有同学有兴趣帮忙补上，我们还是很欢迎的）。

本文是这类文章的第一篇，介绍串口驱动（serialdriver）的移植过程。因为u-boot跑起来之后，第一件事就是要把串口输出（console）准备好，以便后续模块的debug。