【朱兆祺带你学嵌入式】第三章第二节 mkimage工具

在上一节中，无法启动内核，导致的原因可能是加载地址、入口地址等导致的。执行./mkimage之后如下：

zhuzhaoqi@zhuzhaoqi-desktop:~/u-boot/u-boot-2013.04/u-boot-2013.04/tools$ ./mkimage

./mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image

其中-a addr指的就是镜像在内存中的加载地址，镜像下载到内存中时，要按照用mkimage制作镜像时，这个参数所指定的地址值来下载。

而-e ep 是指定镜像运行的入口点地址。

还有两个概念需要明白，即是bootm address和kernel运行地址。bootm address：通过uboot的bootm命令，从address启动kernel。kernel运行地址：在具体mach目录中的Makefile.boot中指定，是kernel启动后实际运行的物理地址。

如果bootm address和Load Address相等，在这种情况下，bootm不会对uImage header后的zImage进行memory move的动作，而会直接go到Entry Point开始执行。因此此时的Entry Point必须设置为Load Address+ 0x40。如果kernel boot过程没有到uncompressing the kernel，就可能是这里设置不对。它们之间的关系为：boom address == Load Address == Entry Point - 0x40。

如果bootm address和Load Address不相等（但需要避免出现memory move时出现覆盖导致zImage被破坏的情况）。此种情况下，bootm会把uImage header后的zImage文件move到Load Address，然后go到entry point开始执行。这段代码在common/cmd_bootm.c中bootm_load_os函数中，如下程序所示。由此知道此时的Load Address必须等于Entry Point。它们之间的关系则为：boom address != Load Address == Entry Point。

    case IH_COMP_NONE:

        if (load == blob_start || load == image_start)

{

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

            no_overlap = 1;

        }

else

{

            printf("   Loading %s ... ", type_name);

            memmove_wd((void *)load, (void *)image_start,

                    image_len, CHUNKSZ);

        }

        *load_end = load + image_len;

        puts("OK\n");

        break;

zImage的头部有地址无关的自解压程序，因此刚开始执行的时候，zImage所在的内存地址（Entry Point）不需要同编译kernel的地址相同。自解压程序会把kernel解压到编译时指定的物理地址，然后开始地址相关代码的执行。在开启MMU之前，kernel都是直接使用物理地址（可参看内核符号映射表System.map）。

通过上面的分析，大概找出了问题的根源，由于bootm address和Load Address都为50008000，属于相等情况，也就是说Entry Point:  50008000，这个地址需要修改，替换成50008040。

找到Load Address和Entry Point这两个地址的定义，存在于scripts/makefile.lib中，

zhuzhaoqi@zhuzhaoqi-desktop:~/Linux/linux-3.8.3/scripts$ gedit Makefile.lib

打开之后可以找到如下：

318    UIMAGE_LOADADDR ?= arch_must_set_this

319    UIMAGE_ENTRYADDR ?= $(UIMAGE_LOADADDR)

这里就是说Entry Point等于Load Address，那么应该修改成为Entry Point=Load Address+0x40，在GNU make中，有sed –e替换操作，如sed -e "s/..$$/40/"，就是把输出的字符串的最后两个字符删掉，并且用40来补充，也就是说把字符串最后两个字符用40来替换。

那么作如下修改：

318    UIMAGE_LOADADDR ?= arch_must_set_this

319    #UIMAGE_ENTRYADDR ?= $(UIMAGE_LOADADDR)

320    UIMAGE_ENTRYADDR  ?=$(shell echo $(UIMAGE_LOADADDR) |

sed -e "s/..$$/40/")

修改完成之后，回到linux-3.8.3根目录下进行编译，如下操作：

zhuzhaoqi@zhuzhaoqi-desktop:~/Linux/linux-3.8.3$ make uImage

如果有如下报错：

zhuzhaoqi@zhuzhaoqi-desktop:~/Linux/linux-3.8.3$ make uImage

scripts/kconfig/conf --silentoldconfig Kconfig

*** Error during update of the configuration.

make[2]: *** [silentoldconfig] 错误 1

make[1]: *** [silentoldconfig] 错误 2

make: *** 没有规则可以创建“include/config/kernel.release”需要的目标“include/config/auto.conf”。停止。

那就是权限的问题，要么修改文件权限，要么在root下编译。这样即可：

zhuzhaoqi@zhuzhaoqi-desktop:~/Linux/linux-3.8.3$ sudo make uImage

编译成功之后输出如下信息：

······

Image Name:   Linux-3.8.3

Created:      Sat Mar 16 10:38:47 2013

Image Type:   ARM Linux Kernel Image (uncompressed)

Data Size:    1664080 Bytes = 1625.08 kB = 1.59 MB

Load Address: 50008000

Entry Point:  50008040

  Image arch/arm/boot/uImage is ready

从串口输出可知，Entry Point=Load Address+0x40，依旧按照SD烧写方式进行测试，如果bootdelay延时过长，可以修改bootdelay时间，如下操作：

Hit any key to stop autoboot:  0

zzq6410 >>> set bootdelay 3

zzq6410 >>> sav

Saving Environment to NAND...

Erasing Nand...

Erasing at 0x80000 -- 100% complete.

Writing to Nand... done

zzq6410 >>>

重启OK6410开发平台，测试结果如下：

NAND read: device 0 offset 0x100000, size 0x500000

5242880 bytes read: OK

## Booting kernel from Legacy Image at 50008000 ...

   Image Name:   Linux-3.8.3

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    1664080 Bytes = 1.6 MiB

   Load Address: 50008000

   Entry Point:  50008040

   Verifying Checksum ... OK

   XIP Kernel Image ... OK

OK

Starting kernel ...

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Booting Linux on physical CPU 0x0

Linux version 3.8.3 (zhuzhaoqi@zhuzhaoqi-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 Fri Mar 15 12:56:52 CST 2013

CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387d

CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

Machine: OK6410

Memory policy: ECC disabled, Data cache writeback

CPU S3C6410 (id 0x36410101)

S3C24XX Clocks, Copyright 2004 Simtec Electronics

S3C64XX: PLL settings, A=533000000, M=533000000, E=24000000

S3C64XX: HCLK2=266500000, HCLK=133250000, PCLK=66625000

mout_apll: source is fout_apll (1), rate is 533000000

mout_epll: source is epll (1), rate is 24000000

mout_mpll: source is mpll (1), rate is 533000000

usb-bus-host: source is clk_48m (0), rate is 48000000

irda-bus: source is mout_epll (0), rate is 24000000

CPU: found DTCM0 8k @ 00000000, not enabled

CPU: moved DTCM0 8k to fffe8000, enabled

CPU: found DTCM1 8k @ 00000000, not enabled

CPU: moved DTCM1 8k to fffea000, enabled

CPU: found ITCM0 8k @ 00000000, not enabled

CPU: moved ITCM0 8k to fffe0000, enabled

CPU: found ITCM1 8k @ 00000000, not enabled

CPU: moved ITCM1 8k to fffe2000, enabled

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024

Kernel command line: root=/dev/mtdblock2 rootfstype=cramfs console=ttySAC0,115200

PID hash table entries: 1024 (order: 0, 4096 bytes)

Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)

Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)

__ex_table already sorted, skipping sort

Memory: 256MB = 256MB total

Memory: 256532k/256532k available, 5612k reserved, 0K highmem

Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    DTCM    : 0xfffe8000 - 0xfffec000   (  16 kB)

    ITCM    : 0xfffe0000 - 0xfffe4000   (  16 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)

    lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)

    modules : 0xbf000000 - 0xc0000000   (  16 MB)

      .text : 0xc0008000 - 0xc02bed88   (2780 kB)

      .init : 0xc02bf000 - 0xc02da7a4   ( 110 kB)

      .data : 0xc02dc000 - 0xc03076a0   ( 174 kB)

       .bss : 0xc0308000 - 0xc0338ef8   ( 196 kB)

SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

NR_IRQS:246

VIC @f6000000: id 0x00041192, vendor 0x41

VIC @f6010000: id 0x00041192, vendor 0x41

sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms

Console: colour dummy device 80x30

Calibrating delay loop... 353.89 BogoMIPS (lpj=1769472)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

Setting up static identity map for 0x502149a8 - 0x50214a04

DMA: preallocated 256 KiB pool for atomic coherent allocations

OK6410: Option string ok6410=0

OK6410: selected LCD display is 480x272

s3c64xx_dma_init: Registering DMA channels

PL080: IRQ 73, at d0846000, channels 0..8

PL080: IRQ 74, at d0848000, channels 8..16

S3C6410: Initialising architecture

bio: create slab at 0

usbcore: registered new interface driver usbfs

usbcore: registered new interface driver hub

usbcore: registered new device driver usb

ROMFS MTD (C) 2007 Red Hat, Inc.

io scheduler noop registered

io scheduler deadline registered

io scheduler cfq registered (default)

s3c-fb s3c-fb: window 0: fb

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

s3c6400-uart.0: ttySAC0 at MMIO 0x7f005000 (irq = 69) is a S3C6400/10

console [ttySAC0] enabled

s3c6400-uart.1: ttySAC1 at MMIO 0x7f005400 (irq = 70) is a S3C6400/10

s3c6400-uart.2: ttySAC2 at MMIO 0x7f005800 (irq = 71) is a S3C6400/10

s3c6400-uart.3: ttySAC3 at MMIO 0x7f005c00 (irq = 72) is a S3C6400/10

brd: module loaded

loop: module loaded

s3c24xx-nand s3c6400-nand: Tacls=4, 30ns Twrph0=8 60ns, Twrph1=6 45ns

s3c24xx-nand s3c6400-nand: System booted from NAND

s3c24xx-nand s3c6400-nand: NAND soft ECC

NAND device: Manufacturer ID: 0xec, Chip ID: 0xd5 (Samsung NAND 2GiB 3,3V 8-bit), 2048MiB, page size: 4096, OOB size: 218

No oob scheme defined for oobsize 218

……

Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

中间作者省去了很多信息，因为这些信息暂时对我们是没有太大关系，但是也给出了很多信息，因为可以很好地和接下来的每一步移植作对比。从串口的输出，可以得知内核是启动了。也就是说，此时u-boot已经成功将相关参数传递给linux3.8.3内核，完成了u-boot到内核的交接。并且内核已经识别了是OK6410开发平台，控制CPU是s3c6410等信息。

当然，读者不仅仅可以通过修改Entry Point使得内核启动，还可以修改启动内核的地址使得bootm address和Load Address不相等，也就是修改U-Boot源码中include/configs/目录下的s3c6410.h文件中：

#ifdef CONFIG_ENABLE_MMU

#define CONFIG_SYS_MAPPED_RAM_BASE  0xc0000000

#define CONFIG_BOOTCOMMAND"nand read 0xc0018000 0x600000x1c0000;\"bootm 0xc0018000"

#else

#define CONFIG_SYS_MAPPED_RAM_BASE  CONFIG_SYS_SDRAM_BASE

#define CONFIG_BOOTCOMMAND"nand read 0x50018000 0x100000 0x500000;"\"bootm 0x50018000"

#endif

    对于ARM处理器，内核启动大体上可以分为两个阶段：与处理器相关的汇编启动阶段和与处理器无关的C代码启动阶段。汇编启动阶段从head.S(arch/arm/kernel/head.S)文件开始，C代码启动阶段从start_kernel函数(init/main.c)开始。当然，经过压缩的内核镜像文件zImage，在进入汇编启动阶段前还要运行一段自解压代码(arch/arm/boot/compressed/head.S)。

    省略一些无关紧要的过程和编译后不运行的代码，该过程的启动流程如图3. 7所示。相对早期linux-2.6.38的版本，linux-3.8.3在汇编启动阶段并没有出现__lookup_machine_type，但这并不意味着内核不再检查bootloader传入的machine_arch_type参数(R1)，只是将检查机制推迟到了C代码阶段。

__lookup_processor_type函数的具体实现如程序清单3. 1。

程序清单3. 1查找处理器类型函数

__lookup_processor_type:

    adr r3, __lookup_processor_type_data

    ldmia r3, {r4 - r6}

    sub r3, r3, r4          @ get offset between virt&phys

    add r5, r5, r3          @ convert virt addresses to

    add r6, r6, r3          @ physical address space

1:  ldmia   r5, {r3, r4}            @ value, mask

    and r4, r4, r9          @ mask wanted bits

    teq r3, r4

    beq 2f

    add r5, r5, #PROC_INFO_SZ       @ sizeof(proc_info_list)

    cmp r5, r6

    blo 1b

    mov r5, #0              @ unknown processor

2:  mov pc, lr

ENDPROC(__lookup_processor_type)

    .align  2

    .type   __lookup_processor_type_data, %object

__lookup_processor_type_data:

    .long   .

    .long   __proc_info_begin

    .long   __proc_info_end

    .size   __lookup_processor_type_data, . - __lookup_processor_type_data

__lookup_processor_type函数的主要功能是将内核支持的所有CPU类型与通过程序实际读取的cpu id进行查表匹配。如果匹配成功，将匹配到的proc_info_list的基地址存到r5,否则，r5为0，程序将会进入一个死循环。函数传入参数r9为程序实际读取的cpu id，传出参数r5为匹配到的proc_info_list指针的地址。同时为了使C语言能够调用这个函数，根据APCS（ARM 过程调用标准）规则，简单使用以下代码就能包装成一个C语言版本__lookup_processor_type的API函数，函数的原型为struct proc_info_list *lookup_processor_type(unsigned int)。

ENTRY(lookup_processor_type)

    stmfd   sp!, {r4 - r6, r9, lr}

    mov r9, r0

    bl  __lookup_processor_type

    mov r0, r5

    ldmfd   sp!, {r4 - r6, r9, pc}

ENDPROC(lookup_processor_type)

ENTRY和ENDPROC宏的定义如下：

#define ENTRY(name)             \

    .globl name;                \

    name:

#define ENDPROC(name)

内核利用一个结构体proc_info_list来记录处理器相关的信息，在文件arch/arm/include/asm/procinfo.h声明了该结构体的类型，如下所示。

struct proc_info_list {

    unsigned int        cpu_val;

    unsigned int        cpu_mask;

    unsigned long       __cpu_mm_mmu_flags; /* used by head.S */

    unsigned long       __cpu_io_mmu_flags; /* used by head.S */

    unsigned long       __cpu_flush;        /* used by head.S */

    const char      *arch_name;

    const char      *elf_name;

    unsigned int        elf_hwcap;

    const char      *cpu_name;

    struct processor    *proc;

    struct cpu_tlb_fns  *tlb;

    struct cpu_user_fns *user;

    struct cpu_cache_fns    *cache;

};

事实上，在arch/arm/mm/proc-*.S这类文件中，程序才真正给内核所支持的arm处理器的proc_info_list分配了内存空间，例如linux/arch/arm/mm/proc-v6.S文件用汇编语言定义的__v6_proc_info结构体。.section指示符来指定这些结构体编译到.proc.info段。.proc.info的起始地址为 __proc_info_begin，终止位置为__proc_info_end，把它们作为全局变量保存在内存中，链接脚本arch/arm/kernel/vmlinux.lds部分内容参考如下：

.init.proc.info : {

  . = ALIGN(4);

__proc_info_begin = .;

*(.proc.info.init)

__proc_info_end = .;

}

2)       __vet_atags

在启动内核时, bootloader会向内核传递一些参数。通常，bootloader 有两种方法传递参数给内核：一种是旧的参数结构方式（parameter_struct)——主要是2.6 之前的内核使用的方式；另外一种是现在的内核在用的参数列表(tagged list) 的方式。这些参数主要包括，系统的根设备标志、页面大小、内存的起始地址和大小、当前内核命令参数等。而这些参数是通过struct tag结构体组织，利用指针链接成一个按顺序排放的参数列表。bootloader引导内核启动时，就会把这个列表的首地址放入R2中，传给内核，内核通过这个地址就分析出传入的所有参数。

内核要求参数列表必须存放在RAM物理地址的头16k位置，并且ATAG_CORE类型的参数需要放置在参数的列表的首位。__vet_atags的功能就是初步分析传入的参数列表，判断的方法也很简单。如果这个列表起始参数是ATAG_CORE类型，则表示这是一个有效的参数列表。如果起始参数不是ATAG_CORE，就认为bootloader没有传递参数给内核或传入的参数不正确。

1)       __create_page_tables

linux内核使用页式内存管理，应用程序给出的内存地址是虚拟地址，它需要经过若干级页表一级一级的变换，才变成真正的物理地址。32位CPU的虚拟地址大小从0x0000_0000到0xFFFF_FFFF共4G。以段(1 MB)的方式建立一级页表，可以将虚拟地址空间分割成4096个段条目(section entry)。条目也称为“描述符”(Descriptor)，每一个段描述符32位，因此一级页表占用16K(0x4000)内存空间。

s3c6410处理器DRAM的地址空间从0x5000_0000开始，上文提到bootloader传递给内核的参数列表存放在RAM物理地址的头16K位置，页表放置在内核的前16K，因此内核的偏移地址为32K(0x8000)，由此构成了如图3. 8所示的实际内存分布图。

__create_page_tables函数初始化了一个非常简单页表，仅映射了使内核能够正常启动的代码空间，更加细致的工作将会在后续阶段完善。流程如所示，获取页表物理地址、清空页表区和建立启动参数页表通过阅读源码很容易理解，不加分析。

__enable_mmu函数使能mmu后，CPU发出的地址是虚拟地址，程序正常运行需要映射得到物理地址，为了保障正常地配置mmu，需要对这段代码1:1的绝对映射，映射范围__turn_mmu_on至__turn_mmu_on_end。正常使能mmu后，不需要这段特定的映射了，在后续C代码启动阶段时被paging_init()函数删除。建立__enable_mmu函数区域的页表代码如程序清单3. 2所示。

程序清单3. 2  __enable_mmu页表的建立

//r4 =页表物理地址

//获取段描述符的默认配置flags

    ldr r7, [r10, #PROCINFO_MM_MMUFLAGS]

    adr r0, __turn_mmu_on_loc //得到__turn_mmu_on_loc的物理地址

    ldmia   r0, {r3, r5, r6}

    sub r0, r0, r3      //计算得到物理地址与虚拟地址的偏差

    add r5, r5, r0      //修正得到__turn_mmu_on的物理地址

    add r6, r6, r0      //修正得到__turn_mmu_on_end的物理地址

    mov r5, r5, lsr #SECTION_SHIFT //1M对齐

    mov r6, r6, lsr #SECTION_SHIFT //1M对齐

1:  orr r3, r7, r5, lsl #SECTION_SHIFT  //生成段描述符：flags + 段基址

    str r3, [r4, r5, lsl #PMD_ORDER]    //设置段描述绝对映射，物理地址等于虚拟地址。每个段描述符占4字节，PMD_ORDER = 2

    cmp r5, r6

    addlo   r5, r5, #1          //下一段，实际上__turn_mmu_on_end - __turn_mmu_on<  1M

    blo 1b

............................

__turn_mmu_on_loc:

    .long   .                   //__turn_mmu_on_loc当前位置的虚拟地址

    .long   __turn_mmu_on      //__turn_mmu_on的虚拟地址

    .long   __turn_mmu_on_end  //__turn_mmu_on_end的虚拟地址

建立内核的映射区页表，分析见程序清单3. 3。

程序清单3. 3内核的映射区页表的建立

//r4 =页表物理地址

mov r3, pc                  //r3 = 当前物理地址

    mov r3, r3, lsr #SECTION_SHIFT    //物理地址转化段基址

    orr r3, r7, r3, lsl #SECTION_SHIFT  //段基址 + flags = 段描述符

//KERNEL_START = 0xC000_8000  SECTION_SHIFT = 20  PMD_ORDER =  2

//由于arm 的立即数只能是8位表示，所有用两条指令实现了将r3存储到对应的页表项中

    add r0, r4,  #(KERNEL_START & 0xff000000) >> (SECTION_SHIFT - PMD_ORDER)

    str r3, [r0, #((KERNEL_START & 0x00f00000) >> SECTION_SHIFT) << PMD_ORDER]!

    ldr r6, =(KERNEL_END - 1)

    add r0, r0, #1 << PMD_ORDER

    add r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ORDER)  //内核映射页表结束的段基址

1:  cmp r0, r6

    add r3, r3, #1 << SECTION_SHIFT   //得到段描述符

    strls   r3, [r0], #1 << PMD_ORDER    //设置段描述符

    bls 1b

1)       __v6_setup

__v6_setup 函数在 proc-v6.S 文件中，在页表建立起来之后，此函数进行一些使能 MMU 之前的初始化操作。

2)       __enable_mmu

__v6_setup已经为使能 MMU做好了必要的准备，为了保证MMU启动后程序顺利返回，在进入__enable_mmu函数之前，已经将__mmap_switched的虚拟地址(链接地址)存储在R13中。

3)       __mmap_switched

程序运行到这里，MMU已经启动，__mmap_switched函数为内核进入C代码阶段做了一些准备工作：复制数据段，清楚BSS段，设置堆栈指针，保存processor ID、machine type(bootloader中传入的)、atags pointer等。最后，终于跳转到start_kernel函数，进入C代码启动阶段。