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