u-boot,linux,文件系統移植筆記1

　　今天把u-boot,linux,yaffs2文件系統的移植所有搞定了，在個人mini2440板子上跑起來了，呵呵，興奮啊！如今回頭看看本身花了這麼長時間所做的工做，結論就是，只要堅持下去就必定會成功的。

　　下面就把我移植過程當中的步驟記錄下來，留着之後看看，也許還會用到的。

　　先是u-boot部分：

　　我用的是

　　　　　　　　       開發環境：fedora 14

                             開發板：mini2440  256M NandFlash   64M SDRAM

                             交叉編譯器：arm-linux-gcc 4.4.3

                             BusyBox版本：busybox-1.7.0

                             yaffs製做工具：mkyaffsimage

                            yaffs2製做工具:mkyaffs2image（適合64M）、mkyaffs2image-128（適合128M以上，個人256M的用這個）

對於u-boot的修改有不少，參考了韋東山大神寫的那本《嵌入式Linux應用開發徹底手冊》一步步作的，建議這部分你們也都本身動手作作，會有很多收穫，對於那種文件的樹形結構分佈，程序設計的能力都會有很大的提升。

　　當u-boot移植可以在板子跑了，在看下面內容：

　　我一直困惑在MTD那部分，對於NAND flash分區那一直不是很清楚，先看我如今的mtd分區：

Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":

0x000000000000-0x000000500000 : "kernel"

0x000000500000-0x000000d00000 : "jffs2"

0x000000d00000-0x000010000000 : "yaffs"

我建立了3的分區，分別做爲 uImage,jffs2,yaffs2文件存放的地址，在u-boot運行後，使用tftp下載kernel及文件系統到內存，接着寫入flash中，具體以下：

tftp 0x31000000 uImage

nand erase 0 0x500000

nand write.jffs2 0x31000000 0 0x300000

　　要注意的是，這裏寫到flash中的地址對應着咱們的MTD分區表地址，個人0地址處存放的是kernel，因此下載到0地址處。

static struct mtd_partition friendly_arm_default_nand_part[] = {  

[0] = {   .name = "supervivi",   .size = 0x00040000,   .offset = 0,  },  

[1] = {   .name = "param",   .offset = 0x00040000,   .size = 0x00020000,  },

 [2] = {   .name = "Kernel",   .offset = 0x00060000,   .size = 0x00500000,  },  

[3] = {   .name = "root",   .offset = 0x00560000,   .size = 1024 * 1024 * 1024,  },

 [4] = {   .name = "nand",   .offset = 0x00000000,   .size = 1024 * 1024 * 1024,  }

};

這是以前的mtd分區，修改後以下：(在 arch/arm/mach-s3c2440/mach-mini2440.c中)

static struct mtd_partition friendly_arm_default_nand_part[] = {  

[0] = {   .name = "kernel",   .size = 0x00050000,   .offset = 0,  },  

[1] = {   .name = "jaffs",   .offset = MTDPART_OFS_APPEND,   .size = 0x00080000,  },

 [2] = {   .name = "yaffs",   .offset = MTDPART_OFS_APPEND,   .size = MTDPART_SIZ_FULL,  

}

};

固然在寫入flash以前最後先下載到內存裏跑一下，看可否運行，否則來回擦除flash太費事，並且也有損於它。

使用：

tftp 0x32000000 uImage bootm 0x32000000

看看能不能打印出這句：

Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":

0x000000000000-0x000000500000 : "kernel"

0x000000500000-0x000000d00000 : "jffs2"

0x000000d00000-0x000010000000 : "yaffs"

若是能夠那說明這一步實現了。因爲開發板上尚未寫入文件系統，也沒有設置nfs掛接網絡文件系統，因此內核啓動後還會出現panic信息。不急， 咱們下一步來解決它。 在這以前，先解釋一下幾個概念：

1.uImage

使用 make uImage編譯 咱們編譯linux結束後會在arch/arm/boot/目錄下生成zImage,uImage內核文件，這有什麼區別呢？ 以前一直沒有去研究他們，如今明白了，簡單的說一下區別：  uImage是U-boot專用的映像文件，它是在zImage以前加上一個長度爲0x40的tag。vmlinuz是bzImage/zImage文件的拷貝或指向bzImage/zImage的 連接。initrd是「initialramdisk」的簡寫。通常被用來臨時的引導硬件到實際內核vmlinuz可以接管並繼續引導的狀態。 vmlinux是內核文件，zImage是通常狀況下默認的壓縮內核映像文件，壓縮vmlinux，加上一段解壓啓動代碼獲得，只能從0X0地址運行。 uImage是u-boot使用bootm命令引導的Linux壓縮內核映像文件格式，使用工具mkimage對普通的壓縮內核映像文件（zImage）加工而得。 能夠由bootm命令從任意地址解壓啓動內核。因爲bootloader通常要佔用0X0地址，因此，uImage相比zImage的好處就是能夠和bootloader共存。 當咱們使用ls -l 查看這兩個文件大小時會發現，uImage比zImage大了64字節，也就是多了0x40長度的tag.

2.bootm

下載到內存後，使用bootm引導uImage,那爲何不用go命令呢？ 緣由是，咱們上面所說的多出64字節的uImage,bootm你能夠把它理解爲專爲它引導的命令。go命令是用來跳轉的二進制可執行文件的命令。這些，咱們 在mini2440裸機開發那想必大多數人都接觸過，再也不細說了!

3.MTDPART_OFS_APPEND

是表明着接着上一個分區地址向下分區，offset偏移。

4.MTDPART_SIZ_FULL flash

分區剩下的全部大小空間都分配出去。

 接着上面說的，寫入flash後，保存引導參數。我這裏是在u-boot中代碼固定的。

#define CONFIG_BOOTDELAY 5

#define CONFIG_BOOTARGS     "noinitrd root=/dev/mtdblock2 init=/linuxrc console=ttySAC0"

#define CONFIG_ETHADDR     08:00:3e:26:0a:5b

#define CONFIG_NETMASK      255.255.255.0

#define CONFIG_IPADDR  192.168.1.230

#define CONFIG_SERVERIP  192.168.1.10 /*#define CONFIG_BOOTFILE "elinos-lart" */

#define CONFIG_BOOTCOMMAND "nboot 0x31000000 0 0; bootm 0x31000000"

這樣開機後,不打斷即可進入kernel。

下一節介紹文件系統部分！