u-boot-2009.08移植笔记六，平台TQ2440 .

六，添加對yaffs2根文件系統的支持，由於我們使用的是NAND flash存儲器，而Yaffs2文件系統

就是專門為這個使用的。至於移植的具體步驟這裡先省略了

七，引導Linux系統

1.在CM2440.h中添加宏

/* for tag(s) to transfer message to kernel */

#define CONFIG_SETUP_MEMORY_TAGS    1

#define CONFIG_CMDLINE_TAG        1

#define CONFIG_INITRD_TAG        1

#define CONFIG_BOOTARGS                 "noinitrd root=/dev/mtdblock2 init=/linuxrc console=ttySAC0,115200 mem=64M"

Linux内核的启动参数可以由内核默认设定，也可以通过u-boot传递。相对来说，

u-boot传递的灵活性更强，只须设置bootargs环境变量即可。

程序先判断是否定义了CONFIG_CMDLINE_TAG等，才决定是否给内核传递参数

這裡定義了由U-BOOT傳遞啟動參數給Linux

2、更改 mach_type 参数,修改 include/asm-arm/mach_types.h,

#define MACH_TYPE_S3C2440    168

将数值改为和内核的 mach_type 一至。至于内核的 mach_type 可以在内核 linux 源代

码下的 arch/arm/tools 中的 mach_types 文件查看到。

3、用 mkzImage 给 zImage 加头信息

mkimage -n 'linux-2.6.25.8' -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008000

-d zImage.bin zImage.img

4.還要增加bootm命令

#define CONFIG_BOOTCOMMAND "nand read 0x30008000 0x200000 0x300000; bootm 0x30008000"

編譯下載到NAND，並保存saveenv環境變量，重啟如果成功了，

那就是人品了，呵呵

修改的就這麼多，但是移植過程中卡在這裡的時間也最多

大致出現問題有下面兩種

1.Uncompressing Linux.................................

...... done, booting the kernel.

啟動到這裡停止

2.undefined instruction  

pc : [<30008028>]         ....

Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  

Resetting CPU ...  

然後又複位了

對於第一種情況：

查了些資料，

出现卡死在这里只有三种情况,如下:

1）. console设置没有传递到内核

2）. u-boot的时钟设置不在405MHz，与Kernel的不一致

3）. Machine ID设置的与Kernel不一致

第一種情況我完整的定義了宏，參數應該沒問題，

第三種情況，在nclude/asm-arm/mach-types.h

修改#define MACH_TYPE_S3C2440 168 與TQ提供內核一樣

那可能出現的情況就在第二種了，我查看了TQ的源碼，時鐘設置在400MHZ是可以啟動的

這個問題糾結了 ,結果在在解決下面的問題后這個問題也解決了。

第二種狀況，就更糾結了。系統根本就不能引導

系統不斷複位提示指令出錯

注意看這個宏

#define CONFIG_BOOTCOMMAND "nand read 0x30008000 0x200000 0x300000; bootm 0x30008000"

沒錯啊，搬運Linux內核到鏈接指定0x30008000 運行

    為什麼當時移植U-BOOT-1.1.6到TQ2440時沒有出現這種情況，分析了下源碼

他在EmbedSky.h中有這樣的定義

#define CONFIG_BOOTCOMMAND        "boot_zImage"

而這個命令在lib_arm/boot_zImage.c文件中

函數題如下

int boot_zImage(ulong from, size_t size)

{

    int ret;

    ulong boot_mem_base;    /* base address of bootable memory */

    ulong to;

    ulong mach_type;

   

boot_mem_base = 0x30000000;

   

/* copy kerne image */

   

to = boot_mem_base + LINUX_KERNEL_OFFSET;

    printf("Copy linux kernel from 0x%08lx to 0x%08lx, size = 0x%08lx ... ",

        from, to, size);

    ret = copy_kernel_img(to, (char *)from, size);

........

........

........

}

TQ的源碼中他也是將內核搬運到

to = boot_mem_base + LINUX_KERNEL_OFFSET;//to=0x30008000

這個地址運行的阿

困惑的好久，問題在這

bootm命令只能用来引导经过mkimage构建了镜像头的内核镜像文件以及根文件镜像

，对于没有用mkimage对内核进行处理的话，那直接把内核下载到连接脚本中指定的

加载地址0x30008000再运行就行，内核会自解压运行（不过内核运行需要一个tag

来传递参数，而这个tag是由bootloader提供的，在u-boot下默认是由bootm命

令建立的）。

TQ提供的內核沒有經過mkimage加上頭信息，所以可以直接下載到0x30008000這個地址

運行，而我使用了bootm命令，並且給linux加上了頭信息，在u-boot目錄下tools目錄

命令如下：

mkimage -n 'linux-2.6.25.8' -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008000

-d zImage.bin zImage.img

加載地址是0x30008000 入口地址也0x30008000 但加上頭信息的內核前面要加上

64B，故實際內核入口地址應該是0x30008040

在以為兄弟博客里找到對bootm命令的分析：
http://blog.csdn.net/liangkaiming/archive/2010/11/04/5986680.aspx

ulong load_addr = CFG_LOAD_ADDR;  /* Default Load Address */

int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])

{

       ......

        if (argc < 2) {

             addr = load_addr;//当bootm命令后面不带地址参数时，将默认的加载地址赋值给addr

        } else {

             addr = simple_strtoul(argv[1], NULL, 16); //如果bootm命令后面带了加载地址，则将该地址赋值给addr,所以最终有用的地址还是bootm命令后附带的地址

        }

        ......

       

        //

        switch (hdr->ih_comp) { //开始判断利用mkimage命令后是否对内核镜像进行了压缩

        case IH_COMP_NONE:  //如果没有被压缩，只是在原有的内核镜像前加了一个头

                 if(ntohl(hdr->ih_load) == addr) { //这步很重要，涉及到我们要讨论的两个地址，我们知道在利用mkimage时指定-a选项后面就是指定的内核加载的地址，这个地址会被存放到镜像头结构的ih_load成员变量中如在smdk2410中ih_load为0x30008000,在这里开始作地址的判断，如果指定的加载地址和之前的addr也就是bootm后面附带的地址相同，则不用将内核镜像搬到其他地方，就在这个地址上执行，这样内核的入口地址就要在加载地址之后的64个字节(因为镜像头占了64个字节)，所以入口地址为0x30008040

                       printf ("   XIP %s ... ", name);

                 } else {//如果指定的加载地址和bootm命令后的附加地址不相同，我们看看下面data此时表示的是什么地址：data = addr + sizeof(image_header_t);可以看到如果指定加载地址与bootm命令后地址不相同，则从bootm命令后面地址所在地取出内核镜像的头进行检验，检验完后data指向真正的内核，然后将内核拷贝到指定的加载地址处来进行自解压运行，这个时候内核的入口地址就和加载地址一样，不需要加上40个字节，因为内核镜像前面的40个字节的头已经被取出来了。

                       memmove ((void *) ntohl(hdr->ih_load), (uchar *)data, len);

                  }

        case IH_COMP_GZIP://如果利用mkimage时对内核镜像进行了压缩，则需要在u-boot内进行第一阶段的解压缩，将解压后的内核镜像存放到指定的加载地址ih_load，然后内核镜像自解压启动

                 printf ("   Uncompressing %s ... ", name);

                 if (gunzip ((void *)ntohl(hdr->ih_load), unc_len,(uchar *)data, &len) != 0) {

                       puts ("GUNZIP ERROR - must RESET board to recover\n");

                       SHOW_BOOT_PROGRESS (-6);

                      do_reset (cmdtp, flag, argc, argv);

                 }

                 break;

     

}

以上對bootm後面帶的參數進行的比較，如果不帶地址參數，就如TQ提供的u-boot源碼

直接將将默认的加载地址赋值给addr

而對於加了頭信息的內核，bootm命令后面带了加载地址，则将该地址赋值给addr,所以

最终有用的地址还是bootm命令后附带的地址

bootm命令会首先判断bootm xxxx 这个指定的地址xxxx是否与-a指定的加载地址是否相同

(1)如果不同的话会从这个地址开始提取出这个64byte的头部，对其进行分析，然后把去掉头部的内核复制到-a指定的load地址中去运行之

(2)如果相同的话那就让其原封不同的放在那，但-e指定的入口地址会推后64byte，以跳过这64byte的头部。

好了到這裡問題已經清楚了

我們bootm後面跟的是0x30008000，與入口地址是相同的，由於加了頭信息所以這個地址

根本不是我們內核的入口地址

解決方法來了

修改bootm命令，u-boot控制台下

#set bootcmd 'nand read 0x30001000 0x200000 0x300000;bootm 0x30001000'

#saveenv

這個0x30001000地址我隨意給的，試過在其他幾個地址也可以（但覺得也不是任意的）

這個方法就是在0x30001000處提取頭信息，然後將內核複製到0x30008000這個地址開始運行

還有一個辦法就是修改頭信息的的地址

mkimage -n 'linux-2.6.25.8' -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008040

-d zImage.bin zImage.img

#tftp 0x30008000 zImage.img

#bootm 0x30008000

到此頭痛好幾天的問題解決了

臨近期末，四級又來了。。悲催咯，U-BOOT基本部分完成了，至於源碼還沒仔細分析過，

等考完了才來完善USB，

SD卡，最好做個命令菜單哈哈