cubietruck在uboot的dram驱动创(chao)造(xi)过程

话说armv7以上的芯片，本身提供了硬件虚拟化的指令集，也就是VT指令。要开启硬件虚拟化，最开始要从引导程序开始设置。
唔，我使用的是u-boot，u-boot项目的地址是https://github.com/linux-sunxi/u-boot-sunxi/
支持硬件虚拟化技术的u-boot项目地址（应该）是：https://github.com/jwrdegoede/u-boot-sunxi
如果不确定下的项目是不是正确的，下下来之后首先看看configs/sun7i.h里面，应当有：

#define CONFIG_ARMV7_VIRT

这一句。
这个u-boot目前支持到cubieboard2，哎，老夫买的是cubietruck，这么高端大气的设备为什么不能够支持呢？
uboot在编译时，通过根目录下的boards.cfg设定了编译规则，可以看到果然支持硬件虚拟化的uboot没有提供cubietruck的规则。。。

用meld查看一下两个项目之间的差异吧～
当然差异非常多，我们的关心没有那么大
按照meld指示把boards.cfg改了，这样我们编译就可以使用

 make Cubietruck CROSS_COMPILE=arm-linux-gnueabihf- -j8

了～

事情当然不会这么简单，编译很显然报错了。
这是为什么呢？引导程序加载时，很显然一切存储都没有到位，此时是通过一个DRAM的设备读取加载信息的，话说DRAM，也经历NorFlash啊SDRAM啊的发展更迭，这个是题外话我就不说（不懂）了

编译时候根据报错（我就不贴了），发现board/sunxi/文件夹下，需要对不同的设备的dram进行编写，比如里面有dram_cubieboard2.c，就是没有dram_cubietruck.c，这个文件提供了一个sunxi_dram_init的函数，将会在同一目录下的board.c中用到。那么我们加一个就好了。
同样用meld把不支持虚拟化那边的uboot搞过来一个dram_cubietruck.c，瞅了一瞅，发现两边的差不多都是一个道理，直接加上，不需要什么修改。

board/sunxi文件夹下还有个Makefile，随手那么一搜，发现

COBJS-$(CONFIG_CUBIEBOARD2) += dram_cubieboard2.o

下面果然没有cubietruck，
所以加上一条：

COBJS-$(CONFIG_CUBIETRUCK)  += dram_cubietruck.o

好了。。这样uboot就可以正常编译以及工作了=w=

但是xen依然还不能启动。。因为老师告诉我，uboot没有mmc驱动，所以从nand读取根目录，而dom0又没有nand驱动，linux-sunxi有nand驱动但又没有xen驱动，因此就又是一个创(chao)造(xi)的过程了哈哈哈哈～