Android arm linux kernel启动流程

发布者:EtherealLove最新更新时间:2016-06-16 来源: eefocus关键字:Android  arm  linux  kernel  启动流程 手机看文章 扫描二维码
随时随地手机看文章
虽然这里的Arm Linux kernel前面加上了Android,但实际上还是和普遍Arm linux kernel启动的过程一样的,这里只是结合一下Android的Makefile,讲一下bootimage生成的一个过程。这篇文档主要描述 bootimage的构造,以及kernel真正执行前的解压过程。

     在了解这些之前我们首先需要了解几个名词,这些名词定义在/Documentation/arm/Porting里面,这里首先提到其中的几个,其余几个会在后面kernel的执行过程中讲述:

     1)ZTEXTADDR  boot.img运行时候zImage的起始地址,即kernel解压代码的地址。这里没有虚拟地址的概念,因为没有开启MMU,所以这个地址是物理内存的地址。解压代码不一定需要载入RAM才能运行,在FLASH或者其他可寻址的媒体上都可以运行。

     2)ZBSSADDR  解压代码的BSS段的地址,这里也是物理地址。

     3)ZRELADDR  这个是kernel解压以后存放的内存物理地址,解压代码执行完成以后会跳到这个地址执行kernel的启动,这个地址和后面kernel运行时候的虚拟地址满足:__virt_to_phys(TEXTADDR) = ZRELADDR。

     4)INITRD_PHYS  Initial Ram Disk存放在内存中的物理地址,这里就是我们的ramdisk.img。

     5)INITRD_VIRT  Initial Ram Disk运行时候虚拟地址。

     6)PARAMS_PHYS 内核启动的初始化参数在内存上的物理地址。

 

     下面我们首先来看看boot.img的构造,了解其中的内容对我们了解kernel的启动过程是很有帮助的。首先来看看Makefile是如何产生我们的boot.img的:

      out/host/linux-x86/bin/mkbootimg-msm7627_ffa  --kernel out/target/product/msm7627_ffa/kernel --ramdisk out/target/product/msm7627_ffa/ramdisk.img --cmdline "mem=203M console=ttyMSM2,115200n8 androidboot.hardware=qcom" --output out/target/product/msm7627_ffa/boot.img

      根据上面的命令我们可以首先看看mkbootimg-msm7627ffa这个工具的源文件:system/core/mkbootimg.c。看完之后我们就能很清晰地看到boot.img的内部构造,它是由boot header /kernel  /ramdisk /second stage构成的,其中前3项是必须的,最后一项是可选的。

      

view plainprint?
  1. /* 
  2.  +-----------------+  
  3.  | boot header     | 1 page 
  4.  +-----------------+ 
  5.  | kernel          | n pages   
  6.  +-----------------+ 
  7.  | ramdisk         | m pages   
  8.  +-----------------+ 
  9.  | second stage    | o pages 
  10.  +-----------------+ 
  11.  
  12.  n = (kernel_size + page_size - 1) / page_size 
  13.  m = (ramdisk_size + page_size - 1) / page_size 
  14.  o = (second_size + page_size - 1) / page_size 
  15.  
  16.  0. all entities are page_size aligned in flash 
  17.  1. kernel and ramdisk are required (size != 0) 
  18.  2. second is optional (second_size == 0 -> no second) 
  19.  3. load each element (kernel, ramdisk, second) at 
  20.     the specified physical address (kernel_addr, etc) 
  21.  4. prepare tags at tag_addr.  kernel_args[] is 
  22.     appended to the kernel commandline in the tags. 
  23.  5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr 
  24.  6. if second_size != 0: jump to second_addr 
  25.     else: jump to kernel_addr 
  26. */  
/* +-----------------+ | boot header | 1 page +-----------------+ | kernel | n pages +-----------------+ | ramdisk | m pages +-----------------+ | second stage | o pages +-----------------+ n = (kernel_size + page_size - 1) / page_size m = (ramdisk_size + page_size - 1) / page_size o = (second_size + page_size - 1) / page_size 0. all entities are page_size aligned in flash 1. kernel and ramdisk are required (size != 0) 2. second is optional (second_size == 0 -> no second) 3. load each element (kernel, ramdisk, second) at the specified physical address (kernel_addr, etc) 4. prepare tags at tag_addr. kernel_args[] is appended to the kernel commandline in the tags. 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr 6. if second_size != 0: jump to second_addr else: jump to kernel_addr */  

      关于boot header这个数据结构我们需要重点注意,在这里我们关注其中几个比较重要的值,这些值定义在boot/boardconfig.h里面,不同的芯片对应vendor下不同的boardconfig,在这里我们的值分别是(分别是kernel/ramdis/tags载入ram的物理地址):

      

view plainprint?
  1. #define PHYSICAL_DRAM_BASE   0x00200000  
  2. #define KERNEL_ADDR          (PHYSICAL_DRAM_BASE + 0x00008000)  
  3. #define RAMDISK_ADDR         (PHYSICAL_DRAM_BASE + 0x01000000)  
  4. #define TAGS_ADDR            (PHYSICAL_DRAM_BASE + 0x00000100)  
  5. #define NEWTAGS_ADDR         (PHYSICAL_DRAM_BASE + 0x00004000)  
#define PHYSICAL_DRAM_BASE 0x00200000 #define KERNEL_ADDR (PHYSICAL_DRAM_BASE + 0x00008000) #define RAMDISK_ADDR (PHYSICAL_DRAM_BASE + 0x01000000) #define TAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00000100) #define NEWTAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00004000)  

      上面这些值分别和我们开篇时候提到的那几个名词相对应,比如kernel_addr就是ZTEXTADDR,RAMDISK_ADDR就是 INITRD_PHYS,而TAGS_ADDR就是PARAMS_PHYS。bootloader会从boot.img的分区中将kernel和 ramdisk分别读入RAM上面定义的地址中,然后就会跳到ZTEXTADDR开始执行。

      基本了解boot.img的内容之后我们来分别看看里面的ramdisk.img和kernel又是如何产生的,以及其包含的内容。从简单的说起,我们先看看ramdisk.img,这里首先要强调一下这个ramdisk.img在arm linux中的作用。它在kernel启动过程中充当着第一阶段的文件系统,是一个CPIO格式打成的包。通俗上来讲他就是我们将生成的root目录,用 CPIO方式进行了打包,然后在kernel启动过程中会被mount作为文件系统,当kernel启动完成以后会执行init,然后将 system.img再mount进来作为Android的文件系统。在这里稍微解释下这个mount的概念,所谓mount实际上就是告诉linux虚拟文件系统它的根目录在哪,就是说我这个虚拟文件系统需要操作的那块区域在哪,比如说ramdisk实际上是我们在内存中的一块区域,把它作为文件系统的意思实际上就是告诉虚拟文件系统你的根目录就在我这里,我的起始地址赋给你,你以后就能对我进行操作了。实际上我们也可以使用rom上的一块区域作为根文件系统,但是rom相对ram慢,所以这里使用ramdisk。然后我们在把system.img mount到ramdisk的system目录,实际上就是将system.img的地址给了虚拟文件系统,然后虚拟文件系统访问system目录的时候会重新定位到对system.img的访问。我们可以看看makefile是如何生成它的:

      out/host/linux-x86/bin/mkbootfs  out/target/product/msm7627_ffa/root | out/host/linux-x86/bin/minigzip > out/target/product/msm7627_ffa/ramdisk.img    

      下面我们来看看kernel产生的过程,老方法,从Makefile开始/arch/arm/boot/Makefile ~

      

view plainprint?
  1. $(obj)/Image: vmlinux FORCE  
  2.     $(call if_changed,objcopy)  
  3.     @echo '  Kernel: $@ is ready'  
  4. $(obj)/compressed/vmlinux: $(obj)/Image FORCE  
  5.     $(Q)$(MAKE) $(build)=$(obj)/compressed $@  
  6. $(obj)/zImage:  $(obj)/compressed/vmlinux FORCE  
  7.     $(call if_changed,objcopy)  
  8.     @echo '  Kernel: $@ is ready'  
$(obj)/Image: vmlinux FORCE $(call if_changed,objcopy) @echo ' Kernel: $@ is ready' $(obj)/compressed/vmlinux: $(obj)/Image FORCE $(Q)$(MAKE) $(build)=$(obj)/compressed $@ $(obj)/zImage: $(obj)/compressed/vmlinux FORCE $(call if_changed,objcopy) @echo ' Kernel: $@ is ready'       

      我们分解地来看各个步骤,第一个是将vmlinux经过objcopy后生成一个未经压缩的raw binary(Image 4M左右),这里的vmlinux是我们编译链接以后生成的vmlinx,大概60多M。这里稍微说一下这个objcopy,在启动的时候ELF格式是没法执行的,ELF格式的解析是在kernel启动以后有了操作系统之后才能进行的。因为虽然我们编出的img虽然被编成ELF格式,但要想启动起来必须将其转化成原始的二进制格式,我们可以多照着man objcopy和OBJCOPYFLAGS    :=-O binary -R .note -R .note.gnu.build-id -R .comment -S(arch/arm/Makefile)来看看这些objcopy具体做了什么事情 ~

      得到Image以后,再将这个Image跟解压代码合成一个vmlinux,具体的我们可以看看arch/arm/boot/compressed/Makefile:

      

view plainprint?
  1. $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o /  
  2.         $(addprefix $(obj)/, $(OBJS)) FORCE  
  3.     $(call if_changed,ld)  
  4.     @:  
  5. $(obj)/piggy.gz: $(obj)/../Image FORCE  
  6.     $(call if_changed,gzip)  
  7. $(obj)/piggy.o:  $(obj)/piggy.gz FORCE  
$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o / $(addprefix $(obj)/, $(OBJS)) FORCE $(call if_changed,ld) @: $(obj)/piggy.gz: $(obj)/../Image FORCE $(call if_changed,gzip) $(obj)/piggy.o: $(obj)/piggy.gz FORCE  

      从这里我们就可以看出来实际上这个vmlinux就是将Image压缩以后根据vmlinux.lds与解压代码head.o和misc.o链接以后生成的一个elf,而且用readelf或者objdump可以很明显地看到解压代码是PIC的,所有的虚拟地址都是相对的,没有绝对地址。这里的 vmlinx.lds可以对照着后面的head.s稍微看一下~得到压缩以后的vmlinx以后再将这个vmlinx经过objcopy以后就得到我们的 zImage了,然后拷贝到out目录下就是我们的kernel了~~

      在这里要强调几个地址,这些地址定义在arch/arm/mach-msm/makefile.boot里面,被arch/arm/boot /Makefile调用,其中zreladdr-y就是我们的kernel被解压以后要释放的地址了,解压代码跑完以后就会跳到这个地址来执行 kernel的启动。不过这里还有其他两个PHYS,跟前面定义在boardconfig.h里面的值重复了,不知道这两个值在这里定义跟前面的值是一种什么关系???

 

       好啦,讲到这里我们基本就知道boot.img的构成了,下面我们就从解压的代码开始看看arm linux kernel启动的一个过程,这个解压的source就是/arch/arm/boot/compressed/head.S。要看懂这个汇编需要了解 GNU ASM以及ARM汇编指令,ARM指令就不说了,ARM RVCT里面的文档有得下,至于GNU ASM,不需要消息了解的话主要是看一下一些伪指令的含义(http://sources.redhat.com/binutils/docs-2.12 /as.info/Pseudo-Ops.html#Pseudo%20Ops)

       那么我们现在就开始分析这个解压的过程:

       1)bootloader会传递2个参数过来,分别是r1=architecture ID, r2=atags pointer。head.S从哪部分开始执行呢,这个我们可以看看vmlinx.lds:

      

view plainprint?
  1. ENTRY(_start)  
  2. SECTIONS  
  3. {  
  4.   . = 0;  
  5.   _text = .;  
  6.   .text : {   
  7.     _start = .;  
  8.     *(.start)  
  9.     *(.text)  
  10.     *(.text.*)  
  11.     *(.fixup)  
  12.     *(.gnu.warning)  
  13.     *(.rodata)  
  14.     *(.rodata.*)  
  15.     *(.glue_7)  
  16.     *(.glue_7t)  
  17.     *(.piggydata)  
  18.     . = ALIGN(4);  
  19.   }  
ENTRY(_start) SECTIONS { . = 0; _text = .; .text : { _start = .; *(.start) *(.text) *(.text.*) *(.fixup) *(.gnu.warning) *(.rodata) *(.rodata.*) *(.glue_7) *(.glue_7t) *(.piggydata) . = ALIGN(4); }  

      可以看到我们最开始的section就是.start,所以我们是从start段开始执行的。ELF对程序的入口地址是有定义的,这可以参照*.lds 的语法规则里面有描述,分别是GNU LD的-E ---> *.lds里面的ENTRY定义  ---> start Symbol  ---> .text section --->0。在这里是没有这些判断的,因为还没有操作系统,bootloader会直接跳到这个start的地址开始执行。

       在这里稍微带一句,如果觉得head.S看的不太舒服的话,比如有些跳转并不知道意思,可以直接objdump vmlinx来看,dump出来的汇编的流程就比较清晰了。

      

view plainprint?
  1. 1:      mov r7, r1          @ save architecture ID  
  2.         mov r8, r2          @ save atags pointer  
  3. #ifndef __ARM_ARCH_2__  
  4.         /* 
  5.          * Booting from Angel - need to enter SVC mode and disable 
  6.          * FIQs/IRQs (numeric definitions from angel arm.h source). 
  7.          * We only do this if we were in user mode on entry. 
  8.          */  
  9.         mrs r2, cpsr        @ get current mode  
  10.         tst r2, #3          @ not user?  
  11.         bne not_angel       @ 如果不是  
  12.         mov r0, #0x17       @ angel_SWIreason_EnterSVC  
  13.         swi 0x123456        @ angel_SWI_ARM  
  14. not_angel:  
  15.         mrs r2, cpsr        @ turn off interrupts to  
  16.         orr r2, r2, #0xc0       @ prevent angel from running  
  17.         msr cpsr_c, r2  
1: mov r7, r1 @ save architecture ID mov r8, r2 @ save atags pointer #ifndef __ARM_ARCH_2__ /* * Booting from Angel - need to enter SVC mode and disable * FIQs/IRQs (numeric definitions from angel arm.h source). * We only do this if we were in user mode on entry. */ mrs r2, cpsr @ get current mode tst r2, #3 @ not user? bne not_angel @ 如果不是 mov r0, #0x17 @ angel_SWIreason_EnterSVC swi 0x123456 @ angel_SWI_ARM not_angel: mrs r2, cpsr @ turn off interrupts to orr r2, r2, #0xc0 @ prevent angel from running msr cpsr_c, r2  

       上面首先保存r1和r2的值,然后进入超级用户模式,并关闭中断。

        

view plainprint?
  1. .text  
  2. adr r0, LC0  
  3. ldmia   r0, {r1, r2, r3, r4, r5, r6, ip, sp}  
  4. subs    r0, r0, r1      @ calculate the delta offset  
  5.                 @ if delta is zero, we are  
  6. beq not_relocated       @ running at the address we  
  7.                 @ were linked at.  
.text adr r0, LC0 ldmia r0, {r1, r2, r3, r4, r5, r6, ip, sp} subs r0, r0, r1 @ calculate the delta offset @ if delta is zero, we are beq not_relocated @ running at the address we @ were linked at.  

      这里首先判断LC0当前的运行地址和链接地址是否一样,如果一样就不需要重定位,如果不一样则需要进行重定位。这里肯定是不相等的,因为我们可以通过 objdump看到LC0的地址是0x00000138,是一个相对地址,然后adr r0, LC0 实际上就是将LC0当前的运行地址,而我们直接跳到ZTEXTADDR跑的,实际上PC里面现在的地址肯定是0x00208000以后的一个值,adr r0, LC0编译之后实际上为add r0, pc, #208,这个208就是LC0到.text段头部的偏移。

      

view plainprint?
  1. add r5, r5, r0  
  2. add r6, r6, r0  
  3. add ip, ip, r0  
add r5, r5, r0 add r6, r6, r0 add ip, ip, r0  

      然后就是重定位了,即都加上一个偏移,经过重定位以后就都是绝对地址了。

      

view plainprint?
  1. not_relocated:  mov r0, #0  
  2. 1:      str r0, [r2], #4        @ clear bss  
  3.         str r0, [r2], #4  
  4.         str r0, [r2], #4  
  5.         str r0, [r2], #4  
  6.         cmp r2, r3  
  7.         blo 1b  
  8.         /* 
  9.          * The C runtime environment should now be setup 
  10.          * sufficiently.  Turn the cache on, set up some 
  11.          * pointers, and start decompressing. 
  12.          */  
  13.         bl  cache_on  
not_relocated: mov r0, #0 1: str r0, [r2], #4 @ clear bss str r0, [r2], #4 str r0, [r2], #4 str r0, [r2], #4 cmp r2, r3 blo 1b /* * The C runtime environment should now be setup * sufficiently. Turn the cache on, set up some * pointers, and start decompressing. */ bl cache_on 

      重定位完成以后打开cache,具体这个打开cache的过程咱没仔细研究过,大致过程是先从C0里面读到processor ID,然后根据ID来进行cache_on。

      

view plainprint?
  1. mov r1, sp          @ malloc space above stack  
  2. add r2, sp, #0x10000    @ 64k max  
mov r1, sp @ malloc space above stack add r2, sp, #0x10000 @ 64k max 

       解压的过程首先是在堆栈之上申请一个空间

      

view plainprint?
  1. /* 
  2.  * Check to see if we will overwrite ourselves. 
  3.  *   r4 = final kernel address 
  4.  *   r5 = start of this image 
  5.  *   r2 = end of malloc space (and therefore this image) 
  6.  * We basically want: 
  7.  *   r4 >= r2 -> OK 
  8.  *   r4 + image length <= r5 -> OK 
  9.  */  
  10.         cmp r4, r2  
  11.         bhs wont_overwrite  
  12.         sub r3, sp, r5      @ > compressed kernel size  
  13.         add r0, r4, r3, lsl #2  @ allow for 4x expansion  
  14.         cmp r0, r5  
  15.         bls wont_overwrite  
  16.         mov r5, r2          @ decompress after malloc space  
  17.         mov r0, r5  
  18.         mov r3, r7  
  19.         bl  decompress_kernel  
  20.         add r0, r0, #127 + 128  @ alignment + stack  
  21.         bic r0, r0, #127        @ align the kernel length  
/* * Check to see if we will overwrite ourselves. * r4 = final kernel address * r5 = start of this image * r2 = end of malloc space (and therefore this image) * We basically want: * r4 >= r2 -> OK * r4 + image length <= r5 -> OK */ cmp r4, r2 bhs wont_overwrite sub r3, sp, r5 @ > compressed kernel size add r0, r4, r3, lsl #2 @ allow for 4x expansion cmp r0, r5 bls wont_overwrite mov r5, r2 @ decompress after malloc space mov r0, r5 mov r3, r7 bl decompress_kernel add r0, r0, #127 + 128 @ alignment + stack bic r0, r0, #127 @ align the kernel length  

        这个过程是判断我们解压出的vmlinx会不会覆盖原来的zImage,这里的final kernel address就是解压后的kernel要存放的地址,而start of this image则是zImage在内存中的地址。根据我们前面的分析,现在这两个地址是重复的,即都是0x00208000。同样r2是我们申请的一段内存空间,因为他是在sp上申请的,而根据vmlinx.lds我们知道stack实际上处与vmlinx的最上面,所以r4>=r2是不可能的,这里首先计算zImage的大小,然后判断r4+r3是不是比r5小,很明显r4和r5的值是一样的,所以这里先将r2的值赋给r0,经kernel先解压到s 申请的内存空间上面,具体的解压过程就不描述了,定义在misc.c里面。(这里我所说的上面是指内存地址的高地址,默认载入的时候从低地址往高地址写,所以从内存低地址开始运行,stack处于最后面,所以成说是最上面)

      

view plainprint?
  1. * r0     = decompressed kernel length  
  2. * r1-r3  = unused  
  3. * r4     = kernel execution address  
  4. * r5     = decompressed kernel start  
  5. * r6     = processor ID  
  6. * r7     = architecture ID  
  7. * r8     = atags pointer  
  8. * r9-r14 = corrupted  
  9. */  
  10.        add r1, r5, r0      @ end of decompressed kernel  
  11.        adr r2, reloc_start  
  12.        ldr r3, LC1  
  13.        add r3, r2, r3  
  14. :      ldmia   r2!, {r9 - r14}     @ copy relocation code  
  15.        stmia   r1!, {r9 - r14}  
  16.        ldmia   r2!, {r9 - r14}  
  17.        stmia   r1!, {r9 - r14}  
  18.        cmp r2, r3  
  19.        blo 1b  
  20.        add sp, r1, #128        @ relocate the stack  
  21.        bl  cache_clean_flush  
  22.        add pc, r5, r0      @ call relocation code  
* r0 = decompressed kernel length * r1-r3 = unused * r4 = kernel execution address * r5 = decompressed kernel start * r6 = processor ID * r7 = architecture ID * r8 = atags pointer * r9-r14 = corrupted */ add r1, r5, r0 @ end of decompressed kernel adr r2, reloc_start ldr r3, LC1 add r3, r2, r3 1: ldmia r2!, {r9 - r14} @ copy relocation code stmia r1!, {r9 - r14} ldmia r2!, {r9 - r14} stmia r1!, {r9 - r14} cmp r2, r3 blo 1b add sp, r1, #128 @ relocate the stack bl cache_clean_flush add pc, r5, r0 @ call relocation code  

      因为没有将kernel解压在要求的地址,所以必须重定向,说穿了就是要将解压的kernel拷贝到正确的地址,因为正确的地址与zImage的地址是重合的,而要拷贝我们又要执行zImage的重定位代码,所以这里首先将重定位代码reloc_start拷贝到vmlinx上面,然后再将vmlinx 拷贝到正确的地址并覆盖掉zImage。这里首先计算出解压后的vmlinux的高地址放在r1里面,r2存放着重定位代码的首地址,r3存放着重定位代码的size,这样通过拷贝就将reloc_start移动到vmlinx后面去了,然后跳转到重定位代码开始执行。

      

view plainprint?
  1. /* 
  2.  * All code following this line is relocatable.  It is relocated by 
  3.  * the above code to the end of the decompressed kernel image and 
  4.  * executed there.  During this time, we have no stacks. 
  5.  * 
  6.  * r0     = decompressed kernel length 
  7.  * r1-r3  = unused 
  8.  * r4     = kernel execution address 
  9.  * r5     = decompressed kernel start 
  10.  * r6     = processor ID 
  11.  * r7     = architecture ID 
  12.  * r8     = atags pointer 
  13.  * r9-r14 = corrupted 
  14.  */  
  15.         .align  5  
  16. reloc_start:    add r9, r5, r0  
  17.         sub r9, r9, #128        @ do not copy the stack  
  18.         debug_reloc_start  
  19.         mov r1, r4  
  20. 1:  
  21.         .rept   4  
  22.         ldmia   r5!, {r0, r2, r3, r10 - r14}    @ relocate kernel  
  23.         stmia   r1!, {r0, r2, r3, r10 - r14}  
  24.         .endr  
  25.         cmp r5, r9  
  26.         blo 1b  
  27.         add sp, r1, #128        @ relocate the stack  
  28.         debug_reloc_end  
  29. call_kernel:    bl  cache_clean_flush  
  30.         bl  cache_off  
  31.         mov r0, #0          @ must be zero  
  32.         mov r1, r7          @ restore architecture number  
  33.         mov r2, r8          @ restore atags pointer  
  34.         mov pc, r4          @ call kernel  
/* * All code following this line is relocatable. It is relocated by * the above code to the end of the decompressed kernel image and * executed there. During this time, we have no stacks. * * r0 = decompressed kernel length * r1-r3 = unused * r4 = kernel execution address * r5 = decompressed kernel start * r6 = processor ID * r7 = architecture ID * r8 = atags pointer * r9-r14 = corrupted */ .align 5 reloc_start: add r9, r5, r0 sub r9, r9, #128 @ do not copy the stack debug_reloc_start mov r1, r4 1: .rept 4 ldmia r5!, {r0, r2, r3, r10 - r14} @ relocate kernel stmia r1!, {r0, r2, r3, r10 - r14} .endr cmp r5, r9 blo 1b add sp, r1, #128 @ relocate the stack debug_reloc_end call_kernel: bl cache_clean_flush bl cache_off mov r0, #0 @ must be zero mov r1, r7 @ restore architecture number mov r2, r8 @ restore atags pointer mov pc, r4 @ call kernel  

       这里就是将vmlinx拷贝到正确的地址了,拷贝到正确的位置以后,就将kernel的首地址赋给PC,然后就跳转到真正kernel启动的过程~~

 

      最后我们来总结一下一个基本的过程:

      1)当bootloader要从分区中数据读到内存中来的时候,这里涉及最重要的两个地址,一个就是ZTEXTADDR还有一个是 INITRD_PHYS。不管用什么方式来生成IMG都要让bootloader有方法知道这些参数,不然就不知道应该将数据从FLASH读入以后放在什么地方,下一步也不知道从哪个地方开始执行了;

      2)bootloader将IMG载入RAM以后,并跳到zImage的地址开始解压的时候,这里就涉及到另外一个重要的参数,那就是 ZRELADDR,就是解压后的kernel应该放在哪。这个参数一般都是arch/arm/mach-xxx下面的Makefile.boot来提供的;

      3)另外现在解压的代码head.S和misc.c一般都会以PIC的方式来编译,这样载入RAM在任何地方都可以运行,这里涉及到两次冲定位的过程,基本上这个重定位的过程在ARM上都是差不多一样的。

写这个总结的时候咱的心情是沉重的,因为还有好多东西没弄明白。。。感叹自己的知识还是浅薄得很,前途钱途漫漫阿~~不过基本脉络是清楚的,具体的细节只能留在以后有时间再啃了。这里的第二部分启动流程指的是解压后kernel开始执行的一部分代码,这部分代码和ARM体系结构是紧密联系在一起的,所以最好是将ARM ARCHITECTURE REFERENCE MANUL仔细读读,尤其里面关于控制寄存器啊,MMU方面的内容~

      前面说过解压以后,代码会跳到解压完成以后的vmlinux开始执行,具体从什么地方开始执行我们可以看看生成的vmlinux.lds(arch/arm/kernel/)这个文件:

      

view plainprint?
  1. OUTPUT_ARCH(arm)  
  2. ENTRY(stext)  
  3. jiffies = jiffies_64;  
  4. SECTIONS  
  5. {  
  6.  . = 0x80000000 + 0x00008000;  
  7.  .text.head : {   
  8.   _stext = .;  
  9.   _sinittext = .;  
  10.   *(.text.h  
OUTPUT_ARCH(arm) ENTRY(stext) jiffies = jiffies_64; SECTIONS { . = 0x80000000 + 0x00008000; .text.head : { _stext = .; _sinittext = .; *(.text.h

      很明显我们的vmlinx最开头的section是.text.head,这里我们不能看ENTRY的内容,以为这时候我们没有操作系统,根本不知道如何来解析这里的入口地址,我们只能来分析他的section(不过一般来说这里的ENTRY和我们从seciton分析的结果是一样的),这里的.text.head section我们很容易就能在arch/arm/kernel/head.S里面找到,而且它里面的第一个符号就是我们的stext:

      

view plainprint?
  1. .section ".text.head", "ax"  
  2. Y(stext)  
  3. msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode  
  4.                     @ and irqs disabled  
  5. mrc p15, 0, r9, c0, c0      @ get processor id  
  6. bl  __lookup_processor_type     @ r5=procinfo r9=cpuid  
.section ".text.head", "ax" ENTRY(stext) msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode @ and irqs disabled mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid  

      这里的ENTRY这个宏实际我们可以在include/linux/linkage.h里面找到,可以看到他实际上就是声明一个GLOBAL Symbol,后面的ENDPROC和END唯一的区别是前面的声明了一个函数,可以在c里面被调用。

      

view plainprint?
  1. #ifndef ENTRY  
  2. #define ENTRY(name) /  
  3.   .globl name; /  
  4.   ALIGN; /  
  5.   name:  
  6. #endif  
  7. #ifndef WEAK  
  8. #define WEAK(name)     /  
  9.     .weak name;    /  
  10.     name:  
  11. #endif  
  12. #ifndef END  
  13. #define END(name) /  
  14.   .size name, .-name  
  15. #endif  
  16. /* If symbol 'name' is treated as a subroutine (gets called, and returns) 
  17.  * then please use ENDPROC to mark 'name' as STT_FUNC for the benefit of 
  18.  * static analysis tools such as stack depth analyzer. 
  19.  */  
  20. #ifndef ENDPROC  
  21. #define ENDPROC(name) /  
  22.   .type name, @function; /  
  23.   END(name)  
  24. #endif  
#ifndef ENTRY #define ENTRY(name) / .globl name; / ALIGN; / name: #endif #ifndef WEAK #define WEAK(name) / .weak name; / name: #endif #ifndef END #define END(name) / .size name, .-name #endif /* If symbol 'name' is treated as a subroutine (gets called, and returns) * then please use ENDPROC to mark 'name' as STT_FUNC for the benefit of * static analysis tools such as stack depth analyzer. */ #ifndef ENDPROC #define ENDPROC(name) / .type name, @function; / END(name) #endif 

 

      找到了vmlinux的起始代码我们就来进行分析了,先总体概括一下这部分代码所完成的功能,head.S会首先检查proc和arch以及atag的有效性,然后会建立初始化页表,并进行CPU必要的处理以后打开MMU,并跳转到start_kernel这个symbol开始执行后面的C代码。这里有很多变量都是我们进行kernel移植时需要特别注意的,下面会一一讲到。

      在这里我们首先看看这段汇编开始跑的时候的寄存器信息,这里的寄存器内容实际上是同bootloader跳转到解压代码是一样的,就是r1=arch  r2=atag addr。下面我们就具体来看看这个head.S跑的过程:

      

view plainprint?
  1. msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode  
  2.                     @ and irqs disabled  
  3. mrc p15, 0, r9, c0, c0      @ get processor id  
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode @ and irqs disabled mrc p15, 0, r9, c0, c0 @ get processor id  

      首先进入SVC模式并关闭所有中断,并从arm协处理器里面读到CPU ID,这里的CPU主要是指arm架构相关的CPU型号,比如ARM9,ARM11等等。

      

view plainprint?
  1.   
 

       然后跳转到__lookup_processor_type,这个函数定义在head-common.S里面,这里的bl指令会保存当前的pc在lr里面,最后__lookup_processor_type会从这个函数返回,我们具体看看这个函数:      

       

view plainprint?
  1. __lookup_processor_type:  
  2.     adr r3, 3f  
  3.     ldmda   r3, {r5 - r7}  
  4.     sub r3, r3, r7          @ get offset between virt&phys  
  5.     add r5, r5, r3          @ convert virt addresses to  
  6.     add r6, r6, r3          @ physical address space  
  7. 1:  ldmia   r5, {r3, r4}            @ value, mask  
  8.     and r4, r4, r9          @ mask wanted bits  
  9.     teq r3, r4  
  10.     beq 2f  
  11.     add r5, r5, #PROC_INFO_SZ       @ sizeof(proc_info_list)  
  12.     cmp r5, r6  
  13.     blo 1b  
  14.     mov r5, #0              @ unknown processor  
  15. 2:  mov pc, lr  
  16. ENDPROC(__lookup_processor_type)  
__lookup_processor_type: adr r3, 3f ldmda r3, {r5 - r7} sub r3, r3, r7 @ 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)  

       他这里的执行过程其实比较简单就是在__proc_info_begin和__proc_info_end这个段里面里面去读取我们注册在里面的 proc_info_list这个结构体,这个结构体的定义在arch/arm/include/asm/procinfo.h,具体实现根据你使用的 cpu的架构在arch/arm/mm/里面找到具体的实现,这里我们使用的ARM11是proc-v6.S,我们可以看看这个结构体:

      

view plainprint?
  1. .section ".proc.info.init", #alloc, #execinstr  
  2. /*  
  3.  * Match any ARMv6 processor core. 
  4.  */  
  5. .type   __v6_proc_info, #object  
  6. _proc_info:  
  7. .long   0x0007b000  
  8. .long   0x0007f000  
  9. .long   PMD_TYPE_SECT | /  
  10.     PMD_SECT_BUFFERABLE | /          
  11.     PMD_SECT_CACHEABLE | /  
  12.     PMD_SECT_AP_WRITE | /  
  13.     PMD_SECT_AP_READ  
  14. .long   PMD_TYPE_SECT | /  
  15.     PMD_SECT_XN | /  
  16.     PMD_SECT_AP_WRITE | /  
  17.     PMD_SECT_AP_READ  
  18. b   __v6_setup  
  19. .long   cpu_arch_name  
  20. .long   cpu_elf_name  
  21. .long   HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA  
  22. .long   cpu_v6_name  
  23. .long   v6_processor_functions   
  24. .long   v6wbi_tlb_fns  
  25. .long   v6_user_fns  
  26. .long   v6_cache_fns  
  27. .size   __v6_proc_info, . - __v6_proc_info  
.section ".proc.info.init", #alloc, #execinstr /* * Match any ARMv6 processor core. */ .type __v6_proc_info, #object __v6_proc_info: .long 0x0007b000 .long 0x0007f000 .long PMD_TYPE_SECT | / PMD_SECT_BUFFERABLE | / PMD_SECT_CACHEABLE | / PMD_SECT_AP_WRITE | / PMD_SECT_AP_READ .long PMD_TYPE_SECT | / PMD_SECT_XN | / PMD_SECT_AP_WRITE | / PMD_SECT_AP_READ b __v6_setup .long cpu_arch_name .long cpu_elf_name .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA .long cpu_v6_name .long v6_processor_functions .long v6wbi_tlb_fns .long v6_user_fns .long v6_cache_fns .size __v6_proc_info, . - __v6_proc_info 

       对着.h我们就知道各个成员变量的含义了,他这里lookup的过程实际上是先求出这个proc_info_list的实际物理地址,并将其内容读出,然后将其中的mask也就是我们这里的0x007f000与寄存器与之后与0x007b00进行比较,如果一样的话呢就校验成功了,如果不一样呢就会读下一个proc_info的信息,因为proc一般都是只有一个的,所以这里一般不会循环,如果检测正确寄存器就会将正确的proc_info_list的物理地址赋给寄存器,如果检测不到就会将寄存器值赋0,然后通过LR返回。

        

view plainprint?
  1. bl  __lookup_machine_type       @ r5=machinfo  
  2. movs    r8, r5              @ invalid machine (r5=0)?        
  3. beq __error_a           @ yes, error 'a'  
bl __lookup_machine_type @ r5=machinfo movs r8, r5 @ invalid machine (r5=0)? beq __error_a @ yes, error 'a' 

       检测完proc_info_list以后就开始检测machine_type了,这个函数的实现也在head-common.S里面,我们看看它具体的实现:

        

view plainprint?
  1. __lookup_machine_type:  
  2.     adr r3, 3b  
  3.     ldmia   r3, {r4, r5, r6}  
  4.     sub r3, r3, r4          @ get offset between virt&phys   
  5.     add r5, r5, r3          @ convert virt addresses to      
  6.     add r6, r6, r3          @ physical address space         
  7. 1:  ldr r3, [r5, #MACHINFO_TYPE]    @ get machine type  
  8.     teq r3, r1              @ matches loader number?         
  9.     beq 2f              @ found      
  10.     add r5, r5, #SIZEOF_MACHINE_DESC    @ next machine_desc  
  11.     cmp r5, r6  
  12.     blo 1b  
  13.     mov r5, #0              @ unknown machine  
  14. 2:  mov pc, lr  
  15. ENDPROC(__lookup_machine_type)  
__lookup_machine_type: adr r3, 3b ldmia r3, {r4, r5, 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: ldr r3, [r5, #MACHINFO_TYPE] @ get machine type teq r3, r1 @ matches loader number? beq 2f @ found add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc cmp r5, r6 blo 1b mov r5, #0 @ unknown machine 2: mov pc, lr ENDPROC(__lookup_machine_type)  

        这里的过程基本上是同proc的检查是一样的,这里主要检查芯片的类型,比如我们现在的芯片是MSM7X27FFA,这也是一个结构体,它的头文件在 arch/arm/include/asm/arch/arch.h里面(machine_desc),它具体的实现根据你对芯片类型的选择而不同,这里我们使用的是高通的7x27,具体实现在arch/arm/mach-msm/board-msm7x27.c里面,这些结构体最后都会注册到 _arch_info_begin和_arch_info_end段里面,具体的大家可以看看vmlinux.lds或者system.map,这里的 lookup会根据bootloader传过来的nr来在__arch_info里面的相匹配的类型,没有的话就寻找下一个machin_desk结构体,直到找到相应的结构体,并会将结构体的地址赋值给寄存器,如果没有的话就会赋值为0的。一般来说这里的machine_type会有好几个,因为不同的芯片类型可能使用的都是同一个cpu架构。

       对processor和machine的检查完以后就会检查atags parameter的有效性,关于这个atag具体的定义我们可以在./include/asm/setup.h里面看到,它实际是一个结构体和一个联合体构成的结合体,里面的size都是以字来计算的。这里的atags param是bootloader创建的,里面包含了ramdisk以及其他memory分配的一些信息,存储在boot.img头部结构体定义的地址中,具体的大家可以看咱以后对bootloader的分析~ 

      

view plainprint?
  1. __vet_atags:  
  2.     tst r2, #0x3            @ aligned?   
  3.     bne 1f  
  4.     ldr r5, [r2, #0]            @ is first tag ATAG_CORE?        
  5.     cmp r5, #ATAG_CORE_SIZE  
  6.     cmpne   r5, #ATAG_CORE_SIZE_EMPTY  
  7.     bne 1f  
  8.     ldr r5, [r2, #4]  
  9.     ldr r6, =ATAG_CORE  
  10.     cmp r5, r6  
  11.     bne 1f  
  12.     mov pc, lr              @ atag pointer is ok             
  13. 1:  mov r2, #0  
  14.     mov pc, lr  
  15. ENDPROC(__vet_atags)  
__vet_atags: tst r2, #0x3 @ aligned? bne 1f ldr r5, [r2, #0] @ is first tag ATAG_CORE? cmp r5, #ATAG_CORE_SIZE cmpne r5, #ATAG_CORE_SIZE_EMPTY bne 1f ldr r5, [r2, #4] ldr r6, =ATAG_CORE cmp r5, r6 bne 1f mov pc, lr @ atag pointer is ok 1: mov r2, #0 mov pc, lr ENDPROC(__vet_atags)  

       这里对atag的检查主要检查其是不是以ATAG_CORE开头,size对不对,基本没什么好分析的,代码也比较好看~ 下面我们来看后面一个重头戏,就是创建初始化页表,说实话这段内容我没弄清楚,它需要对ARM VIRT MMU具有相当的理解,这里我没有太多的时间去分析spec,只是粗略了翻了ARM V7的manu,知道这里建立的页表是arm的secition页表,完成内存开始1m内存的映射,这个页表建立在kernel和atag paramert之间,一般是4000-8000之间~具体的代码和过程我这里就不贴了,大家可以看看参考的链接,看看其他大虾的分析,我还没怎么看明白,等以后仔细研究ARM MMU的时候再回头来仔细研究了,不过代码虽然不分析,这里有几个重要的地址需要特别分析下~

      这几个地址都定义在arch/arm/include/asm/memory.h,我们来稍微分析下这个头文件,首先它包含了arch /memory.h,我们来看看arch/arm/mach-msm/include/mach/memory.h,在这个里面定义了#define PHYS_OFFSET     UL(0x00200000) 这个实际上是memory的物理内存初始地址,这个地址和我们以前在boardconfig.h里面定义的是一致的。然后我们再看 asm/memory.h,他里面定义了我们的memory虚拟地址的首地址#define PAGE_OFFSET     UL(CONFIG_PAGE_OFFSET)。      

      另外我们在head.S里面看到kernel的物理或者虚拟地址的定义都有一个偏移,这个偏移又是从哪来的呢,实际我们可以从arch/arm /Makefile里面找到:textofs-y   := 0x00008000     TEXT_OFFSET := $(textofs-y) 这样我们再看kernel启动时候的物理地址和链接地址,实际上它和我们前面在boardconfig.h和 Makefile.boot里面定义的都是一致的~

      建立初始化页表以后,会首先将__switch_data这个symbol的链接地址放在sp里面,然后获得__enable_mmu的物理地址,然后会跳到__proc_info_list里面的INITFUNC执行,这个偏移是定义在arch/arm/kernel/asm-offset.c里面,实际上就是取得__proc_info_list里面的__cpu_flush这个函数执行。

      

view plainprint?
  1. ldr r13, __switch_data      @ address to jump to after       
  2.                     @ mmu has been enabled           
  3. adr lr, __enable_mmu        @ return (PIC) address  
  4. add pc, r10, #PROCINFO_INITFUNC  
ldr r13, __switch_data @ address to jump to after @ mmu has been enabled adr lr, __enable_mmu @ return (PIC) address add pc, r10, #PROCINFO_INITFUNC  

      这个__cpu_flush在这里就是我们proc-v6.S里面的__v6_setup函数了,具体它的实现我就不分析了,都是对arm控制寄存器的操作,这里转一下它对这部分操作的注释,看完之后就基本知道它完成的功能了。

 /*

 *  __v6_setup

 *

 *  Initialise TLB, Caches, and MMU state ready to switch the MMU

 *  on.  Return in r0 the new CP15 C1 control register setting.

 *

 *  We automatically detect if we have a Harvard cache, and use the

 *  Harvard cache control instructions insead of the unified cache

 *  control instructions.

 *

 *  This should be able to cover all ARMv6 cores.

 *

 *  It is assumed that:       

 *  - cache type register is implemented

 */    

        完成这部分关于CPU的操作以后,下面就是打开MMU了,这部分内容也没什么好说的,也是对arm控制寄存器的操作,打开MMU以后我们就可以使用虚拟地址了,而不需要我们自己来进行地址的重定位,ARM硬件会完成这部分的工作。打开MMU以后,会将SP的值赋给PC,这样代码就会跳到 __switch_data来运行,这个__switch_data是一个定义在head-common.S里面的结构体,我们实际上是跳到它地一个函数指针__mmap_switched处执行的。

        这个switch的执行过程我们只是简单看一下,前面的copy data_loc段以及清空.bss段就不用说了,它后面会将proc的信息和machine的信息保存在__switch_data这个结构体里面,而这个结构体将来会在start_kernel的setup_arch里面被使用到。这个在后面的对start_kernel的详细分析中会讲到。另外这个 switch还涉及到控制寄存器的一些操作,这里我不没仔细研究spec,不懂也就不说了~

        好啦,switch操作完成以后就会b start_kernel了~ 这样就进入了c代码的运行了,下一篇文章仔细研究这个start_kernel的函数~~

 

Ref:

http://linux.chinaunix.net/bbs/thread-1021226-1-1.html

http://blog.csdn.net/yhmhappy2006/archive/2008/08/06/2775239.aspx

http://blog.csdn.net/sustzombie/archive/2010/06/12/5667607.aspx


关键字:Android  arm  linux  kernel  启动流程 引用地址:Android arm linux kernel启动流程

上一篇:arm linux kernel 从入口到start_kernel 的代码分析
下一篇:Android arm linux kernel启动流程二

推荐阅读最新更新时间:2024-03-16 14:57

基于S3C2440的嵌入式Linux驱动——SPI子系统解读(二)
本文属于第二部分。 4. 主控制器驱动程序 4.1 定义 platform device 下列数据结构位于arch/arm/plat-s3c24XX/devs.c /* SPI (0) */ static struct resource s3c_spi0_resource = { = { .start = S3C24XX_PA_SPI, .end = S3C24XX_PA_SPI + 0x1f, .flags = IORESOURCE_MEM, }, = { .start = IRQ_SPI0, .end = IRQ_S
[单片机]
基于S3C2440的嵌入式<font color='red'>Linux</font>驱动——SPI子系统解读(二)
STM32高级开发(5)-gcc-arm-none-eabi
在完成对ubuntu的基本操作和指令的学习后,我们下面正式的进入有关于我们stm32/ARM单片机的软件安装过程。首先我们就要介绍这个会贯穿我们整个开发过程中的软件gcc-arm-none-eabi。 gcc-arm-none-eabi是什么 最直接的当我说出这个软件的时候,大部分童鞋可能会奇怪他到底是个什么呢?首先他是个软件这就不用多说了,做什么的软件呢?编译软件,或是准确点叫工具链。那么听起来是不是和keil、IAR感觉一样呢?我们是不是安装好他以后,打开获得一个界面导入代码就可以编译hex文件呢?答案是否定的。 又我们国内Keil+IAR环境教育出来的童靴们,很少会理解IDE其本质的含义。也许查询百度,他会告诉你ID
[单片机]
STM32高级开发(5)-gcc-<font color='red'>arm</font>-none-eabi
ARM中断向量表重定位到片外RAM方法
由于ARM CPU产生中断或者异常后,PC指针自动跳转到0x00地址执行(同时执行一些CPSR寄存器的保存、运行模式的转换等),所以要在0x00地址处存放中断向量表。而如果我们想将中断向量表重定位到片外ram的 话, 有2中方法: 1、启用MMU 将片外RAM空间隐射到0x00处 2、在0x00(片内RAM)地址处存放一份和片外RAM一模一样的中断向量表 标准做法是将程序存放在NAND FLASH里面,S3C2440 CPU启动后,会将程序复制到片内RAM里面,此时中断向量表也复制到了IRAM里 3、有部分CPU支持设置中断向量表的寄存器 这样也可以实现重定位
[单片机]
OK6410A 开发板 (八) 34 linux-5.11 OK6410A 内存管理第二阶段
B __turn_mmu_on符号 - setup_arch- paging_init- bootmem_init- memblock_allow_resize返回 ----此时memblock初始化完成,开启了基于虚拟内时代的 memblock内存管理器时代 流程 __turn_mmu_on mcr p15, 0, r0, c1, c0, 0 @ write control reg // 内存管理相关1 // 上句执行之后,mmu开启 ret r3 // 调用到 __mmap_switched __mmap_switched adr r4, __mmap_switched_data /
[单片机]
浅析Arm Linux操作系统调用流程详细解析 .
系统调用是os操作系统提供的服务,用户程序通过各种系统调用,来引用内核提供的各种服务,系统调用的执行让用户程序陷入内核,该陷入动作由swi软中断完成. At91rm9200处理器对应的linux2.4.19内核系统调用对应的软中断定义如下: #if defined(__thumb__) //thumb模式 #define __syscall(name)/ push {r7}/n/t / mov r7, # __sys1(__NR_##name) /n/t / swi 0/n/t / pop {r7} #else //arm模式 #define __syscal
[单片机]
11-S3C2440驱动学习(八)嵌入式linux-块设备驱动程序
一、回顾字符设备驱动 主要分为简单字符设备驱动程序,和复杂字符设备驱动 1、简单字符设备驱动 对于简单的字符设备驱动,不需要采用分离分层的思想,主要包括以下几个部分。 2、复杂字符设备驱动 对于复杂的字符设备驱动,采用分离分层的思想,内核中已经实现好了核心层部分,我们只需要实现与硬件相关的部分就可以,最后形成一个总体。这样就是一个通用的字符驱动框架。如LCD驱动、V4L2驱动,当然有时候我们可以选择不采用分离分层的思想,按简单驱动程序的框架来实现一个驱动。 3、字符设备驱动常用技巧 (1) 查询方式 (2) 休眠唤醒,APP-read drv_read (3) poll机制 (4) 异步通知发信号
[单片机]
11-S3C2440驱动学习(八)嵌入式<font color='red'>linux</font>-块设备驱动程序
移植linux-2.6.30.4到S3C2440
一、下载linux-2.6.30.4源码,并解压 ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.4.tar.gz tar zxvf linux-2.6.30.4.tar.gz 二、在系统中添加对ARM的支持 $vim Makefile 193#ARCH ?= $(SUBARCH) 194#CROSS_COMPILE ?= 195 ARCH=arm 196 CROSS_COMPILE=arm-linux- 三、修改系统时钟 $vim arch/arm/mach-s3c2440/mach-smdk2440.c 系统的外部时钟为12MHz 160static
[单片机]
ARM-Intel大战即将上演,好戏还会在后头
  “消费计算器件”这个词涵盖的范围很广,但是大多指笔记本电脑和手机。具体怎么称呼手机和电脑这两类器件,业界目前存在很大争议。“移动互连设备(MID)”一词在业界通常指手机一类器件,但OEM(如DELL)趋向于用“移动互连设备(MID)”一词指笔记本电脑这一类设备。而Qualcomm(高通)则采用完全不同的术语:用“个人计算装置”(personal computing device,PCD)定义手机产品,用“移动计算装置(mobile computing device ,MCD)”来定义笔记本电脑产品。为了避免混淆,文中采用“手机类设备” 和“笔记本电脑设备”这两个更直观的术语。   Intel当前推出的Atom Centrin
[工业控制]
小广播
添点儿料...
无论热点新闻、行业分析、技术干货……
热门活动
换一批
更多
设计资源 培训 开发板 精华推荐

最新单片机文章
何立民专栏 单片机及嵌入式宝典

北京航空航天大学教授,20余年来致力于单片机与嵌入式系统推广工作。

更多精选电路图
换一换 更多 相关热搜器件
更多每日新闻
随便看看
电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved