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)的过程了哈哈哈哈～