uboot启动流程详解(5)-_main

已于 2024-03-13 17:29:32 修改
阅读量90 收藏
点赞数
分类专栏： uboot 转载记录 文章标签： uboot
于 2024-03-13 17:02:16 首次发布
原文链接：https://blog.csdn.net/silent123go/article/details/53198125
版权

目录

前言

1、代码注释

2、board_init_f

3、relocate_code

3.1 原理介绍

3.2 调试过程

3.3 代码分析

前言

　　_main标号中主要调用的函数有三个，board_init_f，relocate_code，board_init_r，这里先贴出_main的代码并注释，然后对这三个函数的流程及原理进行详细介绍。

1、代码注释

ENTRY(_main)

/*
 * Set up initial C runtime environment and call board_init_f(0).
 */
/*
*这里首先为调用board_init_f准备一个临时堆栈，CONFIG_SYS_INIT_SP_ADDR这个宏
*就是cpu片上内存的高地址（片上内存的大小减去GD_SIZE）。然后将堆栈初始的地址保存在
*r9，所以r9就是gd的起始地址，后面需要靠r9访问gd中的成员。然后将r0赋值成0，r0就是
*要调用的board_init_f函数的第一个参数！
*/
#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
    ldr sp, =(CONFIG_SPL_STACK)
#else
    ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
#endif
    bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
    sub sp, sp, #GD_SIZE    /* allocate one GD above SP */
    bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
    mov r9, sp      /* GD is above SP */
    mov r0, #0
    bl  board_init_f

#if ! defined(CONFIG_SPL_BUILD)

/*
 * Set up intermediate environment (new sp and gd) and call
 * relocate_code(addr_moni). Trick here is that we'll return
 * 'here' but relocated.
 */

/*
*这段代码的主要功能就是将uboot搬移到内存的高地址去执行，为kernel腾出低端空间，
*防止kernel解压覆盖uboot。
*adr这个指令非常有意识，可以自己问度娘了解以下。这里这三行代码
*adr    lr, here
*ldr    r0, [r9, #GD_RELOC_OFF]
*add    lr, lr, r0
*的功能就是，将relocate后的here标号的地址保存到lr寄存器，这样等到relocate
*完成后，就可以直接跳到relocate后的here标号去执行了。
*relocate_code函数的原理及流程，是uboot的重要代码，下面详解！
*/
    ldr sp, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */
    bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
    ldr r9, [r9, #GD_BD]        /* r9 = gd->bd */
    sub r9, r9, #GD_SIZE        /* new GD is below bd */

    adr lr, here
    ldr r0, [r9, #GD_RELOC_OFF]     /* r0 = gd->reloc_off */
    add lr, lr, r0
    ldr r0, [r9, #GD_RELOCADDR]     /* r0 = gd->relocaddr */
    b   relocate_code
here:

/* Set up final (full) environment */
　　　　　/*
　　　　　*relocate完成后，uboot的代码被搬到了内存的顶部，所以必须重新设置异常向量表的
　　　　　*地址，c_runtime_cpu_setup这个函数的主要功能就是重新设置异常向量表的地址。
　　　　　*/
    bl  c_runtime_cpu_setup /* we still call old routine here */
　　　　　
　　　　　/*
　　　　　*在relocate的过程中，并没有去搬移bss段。bss段是auto-relocated的！为什么？
　　　　　*可以自己思考一下，又或许看完我后面介绍的relocate的原理后你会明白！
　　　　　*/
    ldr r0, =__bss_start    /* this is auto-relocated! */
    ldr r1, =__bss_end      /* this is auto-relocated! */

    mov r2, #0x00000000     /* prepare zero to clear BSS */
　　　　　
　　　　　/*
　　　　　*清空bss段。
　　　　　*/
clbss_l:cmp r0, r1          /* while not at end of BSS */
    strlo   r2, [r0]        /* clear 32-bit BSS word */
    addlo   r0, r0, #4      /* move to next */
    blo clbss_l
　　　　　
　　　　　/*
　　　　　*这两行代码无视之，点灯什么的，和这里要讲的uboot的原理及过程没有半毛钱关系。
　　　　　*/
    bl coloured_LED_init
    bl red_led_on
　　　　　/*
　　　　　*将relocate后的gd的地址保存到r1，然后调用board_init_r函数，进入uboot的新天地！
　　　　　*/
    /* call board_init_r(gd_t *id, ulong dest_addr) */
    mov     r0, r9                  /* gd_t */
    ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
    /* call board_init_r */
    ldr pc, =board_init_r   /* this is auto-relocated! */

    /* we should not return here. */

#endif

ENDPROC(_main)


 


2、board_init_f

　　这个函数的主要功能就是初始化一些硬件设备(串口、定时器等)并且设置gd结构体中的成员。执行完后，gd中一些重要成员的指向如下图所示：
　　
　　刚开始uboot在编译地址TEXT_BASE处执行，relocate完成后，uboot会被搬移到gd->relocaddr这个地址执行。gd->start_addr_sp是relocate完成后新的堆栈起始地址。接下来对其调用到的主要函数进行介绍。
　　
　　1、获取整个uboot的大小到gd->mon_len

static int setup_mon_len(void)
{
#ifdef __ARM__
    gd->mon_len = (ulong)&__bss_end - (ulong)_start;
#elif defined(CONFIG_SANDBOX)
    gd->mon_len = (ulong)&_end - (ulong)_init;
#else
    /* TODO: use (ulong)&__bss_end - (ulong)&__text_start; ? */
    gd->mon_len = (ulong)&__bss_end - CONFIG_SYS_MONITOR_BASE;
#endif
    return 0;
}



　　__bss_end ，_start这两个标号在链接脚本u-boot.lds中定义。__bss_end -_start uboot就是整个uboot的大小。如果对链接脚本不了解，可以参考《编译及连接过程 》。
　　
　　2、获取环境变量的起始地址到gd->env_addr

int env_init(void)
{
    /* use default */
    gd->env_addr = (ulong)&default_environment[0];
    gd->env_valid = 1;

    return 0;
}


　　default_environment是全局初始化变量，保存在uboot的data段中！

　　3、设置gd->baudrate
　　从环境变量中获取波特率到gd->baudrate成员中。

static int init_baud_rate(void)
{
    gd->baudrate = getenv_ulong("baudrate", 10, CONFIG_BAUDRATE);
    return 0;
}

　
　　4、获取内存的实际大小到gd->ram_size

int dram_init(void)
{
    gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);

    return 0;
}


　　5、获取gd->relocaddr
　　重新设置内存大小，预留出内存顶部的4K不用。　　

static int setup_dest_addr(void)
{
    debug("Monitor len: %08lX\n", gd->mon_len);
    /*
     * Ram is setup, size stored in gd !!
     */
    debug("Ram size: %08lX\n", (ulong)gd->ram_size);
#if defined(CONFIG_SYS_MEM_TOP_HIDE)
    /*
     * Subtract specified amount of memory to hide so that it won't
     * get "touched" at all by U-Boot. By fixing up gd->ram_size
     * the Linux kernel should now get passed the now "corrected"
     * memory size and won't touch it either. This should work
     * for arch/ppc and arch/powerpc. Only Linux board ports in
     * arch/powerpc with bootwrapper support, that recalculate the
     * memory size from the SDRAM controller setup will have to
     * get fixed.
     */
    gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
#endif
#ifdef CONFIG_SYS_SDRAM_BASE
    gd->ram_top = CONFIG_SYS_SDRAM_BASE;
#endif
    gd->ram_top += get_effective_memsize();
    gd->ram_top = board_get_usable_ram_top(gd->mon_len);
    gd->relocaddr = gd->ram_top;
    debug("Ram top: %08lX\n", (ulong)gd->ram_top);
#if defined(CONFIG_MP) && (defined(CONFIG_MPC86xx) || defined(CONFIG_E500))
    /*
     * We need to make sure the location we intend to put secondary core
     * boot code is reserved and not used by any part of u-boot
     */
    if (gd->relocaddr > determine_mp_bootpg(NULL)) {
        gd->relocaddr = determine_mp_bootpg(NULL);
        debug("Reserving MP boot page to %08lx\n", gd->relocaddr);
    }
#endif
    return 0;
}

　　6、设置gd->reloc_off
　　设置relocate的偏移量，并将旧gd中的内容拷贝到新gd中。
 

static int setup_reloc(void)
{
    gd->reloc_off = gd->relocaddr - CONFIG_SYS_TEXT_BASE;
    memcpy(gd->new_gd, (char *)gd, sizeof(gd_t));

    debug("Relocation Offset is: %08lx\n", gd->reloc_off);
    debug("Relocating to %08lx, new gd at %08lx, sp at %08lx\n",
          gd->relocaddr, (ulong)map_to_sysmem(gd->new_gd),
          gd->start_addr_sp);

    return 0;
}


3、relocate_code

3.1 原理介绍

　　u-boot在启动过程中，会把自己拷贝到RAM的顶端去执行。这一拷贝带来的问题是执行地址的混乱。代码的执行地址通常都是在编译时有链接地址指定的，如何保证拷贝前后都可以执行呢？
　　一个办法是使用拷贝到RAM后的地址作为编译时的链接地址，拷贝前所有函数与全局变量的调用都增加偏移量。（如VxWorks的bootloader）尽量减少拷贝前需要执行的代码量。
　　另一个办法是把image编译成与地址无关的程序，也就是PIC - Position independent code。编译器无法保证代码的独立性，它需要与加载器配合起来。U-boot自己加载自己，所以它自己就是加载器。PIC依赖于下面两种技术：
1） 使用相对地址
2） 加载器可以自动更新涉及到绝对地址的指令
　　对于PowerPC架构，u-boot只是在编译时使用了-fpic，这种方式会生成一个.got段来存储绝对地址符号。对于ARM架构，则是在编译时使用-mword-relocations，生成与位置无关代码，链接时使用-pie生成.rel.dyn段，该段中的每个条目被称为一个LABEL，用来存储绝对地址符号的地址。

3.2 调试过程

　　为了理解rel.dyn段的作用，在uboot源代码的common/main.c文件中，加入如下代码，并在main_loop函数中调用rel_dyn_test。

void test_func(void)  
{  
    printf("test func\n");  
}  

static void * test_func_val = test_func;  
static int test_val = 10;   

void rel_dyn_test()  
{  
    test_val = 20; 
    test_func(); 

    printf("test = 0x%x\n", test_func);  
    printf("test_func = 0x%x\n", test_func_val);       
} 


　　然后重新编译uboot，并且对新生成的elf文件(u-boot)进行反汇编：
arm-fsl-linux-gnueabi-objdump -D u-boot > u-boot.huibian。然后在反汇编文件中找到对应的代码段、数据段以及rel.dyn段。如下：
代码段：

/*这里是test_func()函数的反汇编*/
87802fe0 <test_func>:
87802fe0:   e59f300c    ldr r3, [pc, #12]   ; 87802ff4 <test_func+0x14>
87802fe4:   e3a01007    mov r1, #7
87802fe8:   e59f0008    ldr r0, [pc, #8]    ; 87802ff8 <test_func+0x18>
87802fec:   e5831000    str r1, [r3]
87802ff0:   ea003a4a    b   87811920 <printf>/*注：以下两行为Lable1*/
87802ff4:   8784004c    strhi   r0, [r4, ip, asr #32]
87802ff8:   8783127f            ; <UNDEFINED> instruction: 0x8783127f


/*这里是rel_dyn_test函数的反汇编*/
878031c0 <rel_dyn_test>:
878031c0:   e59f302c    ldr r3, [pc, #44]   ; 878031f4 <rel_dyn_test+0x34>
878031c4:   e3a02014    mov r2, #20
878031c8:   e92d4010    push    {r4, lr}
878031cc:   e59f4024    ldr r4, [pc, #36]   ; 878031f8 <rel_dyn_test+0x38>
878031d0:   e5832000    str r2, [r3]
878031d4:   ebffff81    bl  87802fe0 <test_func>
878031d8:   e59f001c    ldr r0, [pc, #28]   ; 878031fc <rel_dyn_test+0x3c>
878031dc:   e1a01004    mov r1, r4
878031e0:   eb0039ce    bl  87811920 <printf>
878031e4:   e59f0014    ldr r0, [pc, #20]   ; 87803200 <rel_dyn_test+0x40>
878031e8:   e1a01004    mov r1, r4
878031ec:   e8bd4010    pop {r4, lr}
878031f0:   ea0039ca    b   87811920 <printf> /*注：以下四行为Lable2*/
878031f4:   87838c3c            ; <UNDEFINED> instruction: 0x87838c3c
878031f8:   87802fe0    strhi   r2, [r0, r0, ror #31]
878031fc:   8783129b            ; <UNDEFINED> instruction: 0x8783129b
87803200:   878312a8    strhi   r1, [r3, r8, lsr #5]

　　这些函数末尾存储变量地址的内存空间称为Label（编译器自动分配），这里记<test_func>的最后两行为Lable1，<rel_dyn_test>的最后四行为Lable2。等一下可以看到这些Lable的地址是存储在rel.dyn段中的。
数据段

87838c3c <test_val>:
87838c3c:   0000000a    andeq   r0, r0, sl

8784004c <jimmy_val>:
8784004c:   00000000    andeq   r0, r0, r0



rel.dyn段

/*Lable1的rel.dyn段*/
8783b4a0:   87802ff4            ; <UNDEFINED> instruction: 0x87802ff4
8783b4a4:   00000017    andeq   r0, r0, r7, lsl r0
8783b4a8:   87802ff8            ; <UNDEFINED> instruction: 0x87802ff8
8783b4ac:   00000017    andeq   r0, r0, r7, lsl r0

/*Lable2的rel.dyn段*/
8783b4c8:   878031f4            ; <UNDEFINED> instruction: 0x878031f4
8783b4cc:   00000017    andeq   r0, r0, r7, lsl r0
8783b4d0:   878031f8            ; <UNDEFINED> instruction: 0x878031f8
8783b4d4:   00000017    andeq   r0, r0, r7, lsl r0
8783b4d8:   878031fc            ; <UNDEFINED> instruction: 0x878031fc
8783b4dc:   00000017    andeq   r0, r0, r7, lsl r0
8783b4e0:   87803200    strhi   r3, [r0, r0, lsl #4]
8783b4e4:   00000017    andeq   r0, r0, r7, lsl r0


　　接下来看一下test_val = 20;这条c语句对应的汇编代码为：

ldr r3, [pc, #44] -----(1)
mov r2, #20       -----(2)
str r2, [r3]      -----(3)



　　由于arm的流水线架构，所以执行第(1)条指令时pc是指向第(3)条指令的，再加上44(也就是再往下数11条指令，因为一条指令4个字节)，即指向了地址为<878031f4>的语句，然后将其内容加载到r3中(即r3=0x87838c3c，对照上面的数据段，可知这就是变量test_val的地址)；接着将立即数20放到r2；最后将r2的内容放到以r3为地址的空间。
　　也就是说，代码在取符号(全局变量、函数等)的时候，会使用相对地址的方法去函数末尾的Lable中取到该符号的地址(说明白点，就是这些Lable存储了要查找符号的地址)，然后再根据该地址读取符号的内容。所以当data段搬移时，Lable中的内容也要跟着改变！而这些Lable的地址保存在rel.dyn段中，所以代码relocate时要用到rel.dyn段，对Lable中的内容进行修改！

3.3 代码分析

ENTRY(relocate_code)
        /*
        *拷贝__image_copy_start到__image_copy_end之间的内容到新地址，即只拷贝了代码段
        *和data段，没有拷贝bss段和rel.dyn段。
        */
    ldr r1, =__image_copy_start /* r1 <- SRC &__image_copy_start */
    subs    r4, r0, r1      /* r4 <- relocation offset */
    beq relocate_done       /* skip relocation */
    ldr r2, =__image_copy_end   /* r2 <- SRC &__image_copy_end */

copy_loop:
    ldmia   r1!, {r10-r11}      /* copy from source address [r1]    */
    stmia   r0!, {r10-r11}      /* copy to   target address [r0]    */
    cmp r1, r2          /* until source end address [r2]    */
    blo copy_loop

    /*
     * fix .rel.dyn relocations
     */
    /*
    *根据rel.dyn段设置Lable的内容，relocate后运行地址和编译地址不一致还能跑，
    *全靠这里啦。
    */
    ldr r2, =__rel_dyn_start    /* r2 <- SRC &__rel_dyn_start */
    ldr r3, =__rel_dyn_end  /* r3 <- SRC &__rel_dyn_end */
fixloop:
    ldmia   r2!, {r0-r1}        /* (r0,r1) <- (SRC location,fixup) */
    and r1, r1, #0xff
    cmp r1, #23         /* relative fixup? */
    bne fixnext

    /* relative fix: increase location by offset */
    add r0, r0, r4
    ldr r1, [r0]
    add r1, r1, r4
    str r1, [r0]
fixnext:
    cmp r2, r3
    blo fixloop

relocate_done:

#ifdef __XSCALE__
    /*
     * On xscale, icache must be invalidated and write buffers drained,
     * even with cache disabled - 4.2.7 of xscale core developer's manual
     */
    mcr p15, 0, r0, c7, c7, 0   /* invalidate icache */
    mcr p15, 0, r0, c7, c10, 4  /* drain write buffer */
#endif

    /* ARMv4- don't know bx lr but the assembler fails to see that */

#ifdef __ARM_ARCH_4__
    mov        pc, lr
#else
    bx        lr
#endif

ENDPROC(relocate_code)

it潮人
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
UBOOT之main.c分析
GameIT
12-21 4765
main.c这个文件在common/main.c中定义 /*******设置环境变量ver**************/ #ifdef CONFIG_VERSION_VARIABLE { extern char version_string[ ]; setenv ("ver", version_string);      //设置环境变量ver的值 } #endi
uboot-imx-rel_imx_4.1.15_2.1.0_ga.tar.bz2
03-18
NXP官网的IMX6ULL U-BOOT，版本：2016.03-2.1.0，可移值到正点原子开发板，百问网开发板等
uboot中main_loop分析
咕唧咕唧shubo.lk的专栏
06-21 2628
终于分析完了main_loop，发文纪念一下。1。main_loop common/main.cmain_loop又臭又长，去掉宏注释掉的部分就只剩下一点点了。如下：void main_loop (void){#ifndef CONFIG_SYS_HUSH_PARSER    static char lastcommand[CONFIG_SYS_CBSIZE] = { 0, }; 
Uboot启动分析--__main分析(1)
Muggle的博客
11-03 1040
arch/arm/lib/crt0_64.S 上一节start.S主要做了以下工作： reset初始化，save_boot_params（nxp定义）保存参数到大小256byte的sram中 设置cpu状态：小端模式，MMU 、 i/d cache 都关闭，段定义； 判断当前的异常等级并将中断向量的地址写到各个EL3/2/1对应的VBAR寄存器中； 打开EA、FIQ、IRQ、NS四种中断； 打开SIMD和FP浮点运算功能； 配置cntfrq_el0 系统时钟计数器的频率。 最后主核跳转_main，从核等
uboot启动流程分析5 - _main
AIoT技术栈的博客
07-05 277
_main 76行，sp重新赋值为0X0091FF00 83行，sp八字节对齐 85行，sp赋值给r0 86行，跳转到这个函数，r0作为参数传递 board_init_f_alloc_reserve 预留早期malloc和gd区域，top的指向 top = top - 0X400 - 248 = 0X0091FA00 87行，r0存放上边函数的返回值，赋值给sp，更新sp指针 ...
u-boot分析（三）：main函数分析、uboot自拷贝和重定位
weixin_44322720的博客
04-15 1270
uboot分析三：main函数分析、uboot自拷贝和重定位 /* * Set up
Uboot启动过程详解.zip_ARM Linux_UBOOT移植_uboot_uboot 分析_uboot 移植
07-15
Uboot启动过程分析，学习，需要移植uboot的可以看下
Uboot启动流程详解笔记.docx
09-09
_main函数是Uboot启动流程的核心函数，该函数将执行一系列的初始化操作，例如设置Uboot的版本号、初始化板级硬件等。 5. board_init_f函数 board_init_f函数是一个板级初始化函数，该函数将初始化板级硬件，例如...
UBoot_最终版2015-04-27_刷后可直刷不死Breed.zip
09-18
这是H大最后一个U-Boot版本，时间2015-04-27的u-boot，，可直接刷不死breed,其它u-boot版会有64整数的文件大小验证不能直接刷breed,其它版u-boot可先刷最后这版u-boot后再刷breed。此版u-boot和breed可互刷，十分...
uboot-imx-rel_imx_4.1.15_2.1.0_ga.rar
05-12
uboot-imx-rel_imx_4.1.15_2.1.0_ga.rar
U-Boot学习(6)：初始化之_main函数源码分析
最新发布
主要分享硬件、嵌入式软件部分知识
01-30 1186
ARM中函数使用到的全局变量，会在每个函数的最后留一段内存空间来保存使用到的变量的地址。如果我们要让重定位后的代码可以正常访问全局变量的话，我们只需要修改函数最后这段内存空间里对应的全局变量的地址，给这个地址加上重定位偏移即可。
Uboot35之uboot命令集及main_loop
wangdapao12138的博客
05-05 584
1.Uboot：Start.s -&gt; start_armboot ()-&gt; main_loop () main_loop()会调用abortboot (bootdelay)判断在delay time内有没有键按下，并给出prompt"Hit any key to stop autoboot"，若没有键按下则run_command (s, 0)(s为默认的bootcmd)。...
【linux 系统移植④】uboot 进入 main_loop() 前
Jia ming 的日常学习笔记
05-12 350
uboot 进入 main_loop() 前
U-Boot编译过程分析
Young_Xu的专栏
08-14 4872
来自： singleboy的博客： http://singleboy.blog.163.com/blog/static/5490019420112371822974/ U-Boot编译过程分析   2011-03-09 19:04:39|  分类：Bootloader
从U-Boot relocation所展开的探索（二）
流水
03-19 1104
ARM  Architecture C语言寻址解析—— 从U-Boot relocation所展开的探索（二） by蔡于清 ARMArchitecture C语言PIC寻址方式解析 承前文所述，可不可以产生一种可以运行在任意地址段的代码呢？可以，这种代码被称之为Position-IndependentCode，简称 PIC（windows DLL，Linux  ShareObject，
uboot代码重定位
evenness的专栏
05-14 2993
(mips) 进入函数board_init_f后，首先做一系列初始化：                 timer_init    时钟初始化                 env_init    环境变量初始化（取得环境变量存放的地址）                 init_baudrate    串口速率                 serial_init        串
uboot源码分析六 uboot启动流程三 lowlevel_init 函数 s_init 函数 _main 函数
monkea123的博客
11-16 1646
lowlevel_init 函数 函数 lowlevel_init 在文件 arch/arm/cpu/armv7/lowlevel_init.S 中定义， /* * A lowlevel_init function that sets up the stack to call a C function to * perform further init. * * (C) Copyright...
uboot启动流程-涉及_main汇编函数
wojiaxiaohuang2014的博客
09-30 1466
uboot启动流程涉及的 _main汇编函数
uboot启动linux过程详解
06-28
### 回答1： Uboot启动Linux过程详解： 1. Uboot加载内核镜像：Uboot首先会从存储设备（如SD卡、NAND Flash等）中加载内核镜像到内存中。 2. 设置内核启动参数：Uboot会设置内核启动参数，包括内核镜像在内存中的位置、根文件系统的位置、启动参数等。 3. 启动内核：Uboot会将控制权交给内核，让内核开始执行。内核会进行一系列初始化操作，包括初始化CPU、内存、设备驱动等。 4. 挂载根文件系统：内核会挂载根文件系统，使得用户可以访问文件系统中的文件和目录。 5. 启动用户空间：内核会启动用户空间，即启动init进程。init进程会读取配置文件，启动各种系统服务和应用程序。 6. 用户空间运行：一旦用户空间启动成功，系统就进入了正常的运行状态，用户可以使用各种应用程序和系统服务。 总之，Uboot启动Linux的过程是一个复杂的过程，需要多个组件协同工作，才能让系统正常启动并运行。 ### 回答2： Uboot是嵌入式系统中常用的一个开源启动加载程序，其主要功能是在嵌入式操作系统中启动Linux系统，并初始化系统硬件资源。Uboot在整个Linux系统启动过程中起到很关键的作用，下面就来详细介绍一下Uboot启动Linux过程. 一、Uboot的加载 第一个引导程序（Bootloader）需要存放在系统的闪存中，是Linux系统启动的重要组成部分。当开机后CPU默认开始执行闪存芯片0的地址，此时Uboot就被加载到RAM中，并执行。由于Uboot同样位于一块桥接器和一个NOR Flash的四接口ARM微控制器总线上，因此Uboot在存储器刚刚发挥了重要作用。 在Uboot的启动过程中，系统会根据用户的选择进行环境的设置，比如启动选项、串口设置等。同时，Uboot还会初始化内存，并将内核镜像加载到内存中，准备启动内核。 二、内核的启动 Linux内核启动主要分为五个过程，分别是: 1.内核加载 当Uboot初始化完成后，系统进入内核加载阶段。Uboot会将存放在NOR Flash中的内核镜像加载到系统主内存中。在加载内核时，会有一个fdt文件，该文件是系统在启动时加载设备树的重要文件，在设备树的启动阶段，大部分设备驱动程序都是通过fdt中的节点进行解析。 2.内核装载初始化 在内核镜像成功加载到内存中后，Linux内核开始进入装载初始化，该阶段主要进行一些内部的初始化工作，比如初始化调度程序、内存管理、文件系统等；此外还会启动ELF文件解析程序，解析各个驱动模块，以便后续的设备树解析和驱动程序的加载。 3.设备树解析 在内核镜像加载到内存中之后，Linux会对设备树进行解析。设备树是在启动时由Uboot加载、传递给内核的一种数据结构，主要用于描述系统的硬件资源分布情况，是操作系统启动过程中很关键的一环，因为设备树可以为操作系统提供有关系统硬件的信息，便于操作系统启动后初始化对应的硬件资源。 4.初始化进程 在设备树解析完成之后，Linux会进入初始化进程的阶段。在这个过程中，系统会完成一系列的启动脚本，完成基本系统的初始化，并启动基本服务。 5.用户空间启动 当初始化进程执行完毕后，系统进入用户空间启动阶段。此时可以执行用户的应用程序，系统也正式进入了可用状态了。 三、总结 以上就是Uboot启动Linux过程的详解了。在整个启动过程中，Uboot不仅完成了硬件资源初始化，还实现了内核和用户空间的启动，是整个系统的重要组成部分。对于嵌入式设备的开发者来说，深入了解Uboot的启动过程，对于准确定位问题和有序开发代码具有很大的帮助。 ### 回答3： uboot是嵌入式系统中常用的一个启动引导程序，其作用是加载Linux内核文件到系统中，并启动该内核从而让系统正常运行。本文就uboot启动linux的过程进行详细的分析。 uboot启动linux的过程： 1. CPU从复位向量开始执行： 当CPU启动时，会首先寻找复位向量所在的地址，并执行该地址中存储的指令。在嵌入式系统中，这个复位向量通常被配置为uboot程序的起始地址。 2. 加载uboot程序： uboot启动后会先加载自身的程序代码。uboot的程序包括bootloader和一些工具函数，它们可以执行一些用户定制的任务，比如读写参数、显示系统信息等操作，然后才会加载Linux内核。 3. 加载Linux内核： 在uboot加载内核时，它首先要根据指定的地址和大小，从存储介质中读取内核文件，并将其存储到内存中。在读取内核文件期间，uboot会进行一些配置操作，比如初始化内存、配置内存映射等操作。 4. 启动Linux内核： Linux内核启动时需要设置一些参数，这些参数通常由uboot传递给内核。例如，uboot会告诉内核内存的位置和大小、设备树等信息。接着，内核会根据这些参数进一步初始化系统，比如建立内存映射表、配置硬件设备等操作。这些操作完成后，Linux内核会开始执行用户空间程序，使得系统正常运行。 总结： 通过上述分析可知，uboot启动Linux的过程涉及到多个环节，其中包括uboot程序的加载、Linux内核的加载以及启动Linux内核时传递参数等操作。在实际系统中，这些过程需要针对具体的硬件平台进行适当的定制，才能保证系统正常启动和运行。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值