首先,我们要知道在zImage的生成过程中,是把arch/arm/boot/compressed/head.s 和解压代码misc.c,decompress.c加在压缩内核的最前面最终生成zImage的,那么它的启动过程就是从这个head.s开始的,并且如果代码从RAM运行的话,是与位置无关的,可以加载到内存的任何地方。
下面以arch/arm/boot/compressed/head.s为主线进行启动过程解析。
1.
最开始的一段都是head.s的debug宏定义部分,这部分可以方便我们调试时使用。
如下:
#ifdef DEBUG
#if defined(CONFIG_DEBUG_ICEDCC)
#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7)
#elif defined(CONFIG_CPU_XSCALE)
#else
#endif
#else
#include <mach/debug-macro.S>
#if defined(CONFIG_ARCH_SA1100)
#ifdef CONFIG_DEBUG_LL_SER3
#else
#endif
#elif defined(CONFIG_ARCH_S3C2410)
#else
#endif
#endif
#endif
如果开启DEBUGging宏的话,这部分代码分两段CONFIG_DEBUG_ICEDCC是用ARMv6以上的加构支持的ICEDCC技术进行调试,DCC(Debug Communications Channel)是ARM的一个调试通信通道,在串口无法使用的时候可以使用这个通道进行数据的通信,具体的技术参前ARM公司文档《ARM Architecture Reference Manual》。
第二部分首先#include <mach/debug-macro.S>,这个文件定义位于arch/arm/mach-xxxx/include/mach/debug-macro.S里面,所以这个是和平台相关的,里面定义了每个平台的相关的串口操作,因这个时候系统还没有起来,所以它所用的串口配置参数是依赖于前一级bootloader所设置好的,如我们使用的u-boot设置好所有的参数。如我们的EVB板ARM的实现如下:
#include <mach/hardware.h>
#include <mach/platform.h>
1001:
1001:
主要实现 addruart,senduart,waituart,busyuart这四个函数的具体实施。这个是调试函数打印的基础。
下面是调试打印用到的kputc和kphex
它所调用的putc 和phex是在head.s最后的一段定义的,如下
#ifdef DEBUG
phexbuf:
上面是分配打印hex的buffer,下面是具体的实现:
@ phex corrupts {r0, r1, r2, r3}
phex:
1:
@ puts corrupts {r0, r1, r2, r3}
puts:
1:
2:
3:
@ putc corrupts {r0, r1, r2, r3}
putc:
@ memdump corrupts {r0, r1, r2, r3, r10, r11, r12, lr}
memdump:
2:
1:
#endif
嘿嘿,还有memdump 这个函数可以用,不错。
好了,言归正传,再往下看,代码如下:
#ifdef DEBUG
#ifdef CONFIG_CPU_CP15
#endif
#endif
#ifdef DEBUG
#endif
debug_reloc_start
用来打印出一些代码重定位后的信息,关于重定位,后面会说,
用来把解压后的内核的256字节的数据dump出来,查看是否正确。很不幸的是,这个不是必须调用的,调试的时候,这些都是要自己把这些调试函数加上去的。好debug部分到这里就完了。
2.
继续向下分析,下面是定义.start段,这段在链接时被链接到代码的最开头,那么zImage启动时,最先执行的代码也就是下面这段代码start开始的,如下:
start:
1:
#ifndef __ARM_ARCH_2__
not_angel:
#else
#endif
为何这个会先执行呢?问的好。那么来个中断吧:这个是由arch/arm/boot/compressed/vmlinux.lds的链接脚本决定的,如下:
怎么样,看到没,.text段最开始的一部分就是.start段,所以这就注定了它就是最先执行的代码。
好了,中断结束,再回到先前面的代码,这段代码的最开始是会被编译器编译成8个nop, 这个是为了留给ARM的中断向量表的,但是整个head.s都没有用到中断啊,谁知道告诉我一下,谢了。
然后呢,把u-boot 传过来的放在r1,r2的值,存在r7,r8中,r1存是的evb板的ID号,而r2存的是内核要用的参数地址,这两个参数在解压内核的时候不要用到,所以暂时保存一下,解压内枋完了,再传给linux内核。
再然后是几个宏定义的解释,ARM(),BSYM(),THUMB(),再加上 W()吧,这几个个宏定义都是在arch/arm/include/asm/unified.h里面定义的,好了,这里也算个中断吧,如下:
#ifdef CONFIG_THUMB2_KERNEL
......
#define ARM(x...)
#define THUMB(x...)
#ifdef __ASSEMBLY__
#define W(instr)
#endif
#define BSYM(sym)
#else
......
#define ARM(x...)
#define THUMB(x...)
#ifdef __ASSEMBLY__
#define W(instr)
#endif
#define BSYM(sym)
#endif
好的看到上面的定义你就会明白了,这里是为了兼容THUMB2指令的内核。
关于#define ARM(x...) 里面的“...”,没有见过吧,这个是C语言的C99的新标准,变参宏,就是在x里,你可以随便你输入多少个参数。别急还没有完,因为没有看见文件里有什么方包含这个头文件。是的文件中确实没有包含,它的定义是在:arch/arm/makefile中加上的:
KBUILD_AFLAGS
行,这些宏解释到此,下面再出现,我就无视它了。
好了,再回来,读取cpsr并判断是否处理器处于supervisor模式——从u-boot进入kernel,系统已经处于SVC32模式;而利用angel进入则处于user模式,还需要额外两条指令。之后是再次确认中断关闭,并完成cpsr写入。
注:Angel是ARM公司的一种调试方法,它本身就是一个调试监控程序,是一组运行在目标机上的程序,可以接收主机上调试器发送的命令,执行诸如设置断点、单步执行目标程序、观察或修改寄存器、存储器内容之类的操作。与基于jtag的调试代理不同,Angel调试监控程序需要占用一定的系统资源,如内存、串行端口等。使用angel调试监控程序可以调试在目标系统运行的arm程序或thumb程序。
好了,里面有一句:teqp
是否很奇怪,不过大家千万不要纠结它,因为它是ARMv2架构以前的汇编方法,用于模式变换,和中断关闭的,看不明白也没关系,因为我们以后也用不到。这里知道一下有这个事就行了。