1

话说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)的过程了哈哈哈哈~


猪了个去
349 声望5 粉丝

=w=快乐的Python程序猿


引用和评论

0 条评论