嵌入式Linux开发必懂：基于ARM64的init用户进程究竟如何启动？

嵌入式ARM 2020-04-08 00:00

【应用手册】TI 全新MCU及C29内核的电动汽车应用方案 如何增强能源基础设施的实时控制？

[导读] 前面的文章有提到linux启动的第一个进程为init，那么该进程究竟是如何从内核启动入口一步一步运行起来的，而该进程又有些什么作用呢？做嵌入式Linux开发，有必要对这些概念了解清楚。本文基于ARM体系的内核启动做出解析。

跳转内核前基本准备

参考./Documentation/arm64/booting.txt

Bootloader至少完成以下基本的初始化准备：

设置并初始化RAM（必须），引导加载程序应找到并初始化内核将用于系统中易失性数据存储的所有RAM。它以机器相关的方式执行此操作。（它可以使用内部算法来自动定位和调整所有RAM的大小，或者可以使用机器中RAM的知识或引导加载程序设计者认为合适的任何其他方法。）
设置设备树dtb（必须） , 设备树blob（dtb）必须8字节对齐，并且大小不能超过2兆字节。由于dtb将使用最大2 MB的块进行映射以可缓存，因此它不能放置在必须使用任何特定属性进行映射的任何2M区域内。注意：v4.2之前的版本还要求将DTB放置在512 MB区域内，从内核映像下方的text_offset字节开始计算。
解压缩内核映像(可选)，AArch64内核当前不提供解压缩器，因此如果使用压缩的Image目标（例如Image.gz），则需要由引导加载程序执行解压缩（gzip等）。对于未实现此要求的引导加载程序，可以使用未经压缩内核编译。

调用内核映像（必须）。压缩内核头部如下：

u32 code0;              /* 可执行code   */
u32 code1;              /* 可执行code   */
u64 text_offset;        /* 加载偏移，小端 */
u64 image_size;         /* 有效映象尺寸，小端 */
u64 flags;              /* 内核标志, 小端    */
u64 res2  = 0;          /* 保留 */
u64 res3  = 0;          /* 保留 */
u64 res4  = 0;          /* 保留 */
u32 magic = 0x644d5241; /* 幻数，小端, "ARM\x64"  */
u32 res5;               /* 保留（用于PE COFF偏移量） */

进入内核之前，必须满足以下条件：

禁止所有具有DMA功能的设备，以免内存被虚假错误的网络数据包或磁盘数据损坏。
主CPU通用寄存器设置：

x0 =系统RAM中设备树Blob（dtb）的物理地址。
x1/x2/x3 = 0（保留供将来使用）

CPU模式

所有形式的中断都必须在PSTATE.DAIF中屏蔽（调试，SError，IRQ和FIQ）。
CPU必须位于EL2（推荐使用，以便可以访问虚拟化扩展）或非安全EL1中。

Caches, MMUs

MMU必须关闭。
指令缓存可以打开或关闭。
与加载的内核映像相对应的地址范围必须清除到PoC。如果存在系统缓存或启用了缓存的其他相关主服务器，则通常需要通过VA而不是通过设置/方式操作来维护缓存。
遵循VA对架构化缓存维护的系统缓存。必须配置并启用操作。
不遵循VA对架构化混存维护的系统缓存，必须配置和禁用操作（不推荐）。

架构定时器

必须在所有CPU上以定时器频率设置CNTFRQ，并且必须以一致的值设置CNTVOFF。如果在EL1处进入内核，则CNTHCTL_EL2必须在可用时设置EL1PCTEN（位0）。

连贯性

内核启动时，所有要由内核引导的CPU都必须属于同一一致性域。需要初始化定义的实现，才能在每个CPU上接收维护操作。

系统寄存器

所有将在其中输入内核映像的异常级别的可写体系结构系统寄存器都必须由更高级别的异常级别的软件初始化，以防止在UNKNOWN状态下执行。
对CPU模式，高速缓存，MMU，架构计时器，一致性和系统寄存器的要求适用于所有CPU。所有CPU必须以相同的异常级别进入内核。

主CPU必须直接跳转到内核映像的第一条指令。此CPU传递的设备树Blob必须为每个cpu节点包含一个“启用方法”属性。支持的启用方法如下所述。引导加载程序将生成这些设备树属性，并将其插入内核入口之前的blob中。
具有“旋转表”启用方法的CPU在其cpu节点中必须具有“ cpu-release-addr”属性。此属性标识自然对齐的64位零初始化内存位置。
具有“ psci”启用方法的CPU应该保留在内核之外（即，在内存节点中描述给内核的内存区域之外，或者在内核中通过/ memreserve /描述给内核描述的内存保留区域之外）。设备树）。内核将按照ARM文档编号ARM DEN 0022A（“ ARM处理器上的电源状态协调接口系统软件”）中的说明发出CPU_ON调用，以将CPU带入内核。设备树应包含一个“ psci”节点，参考/bindings/arm/psci.txt.
第二CPU通用寄存器设置的x0/x1/x2/x3都为0，保留。

内核启动init总过程

内核启动有两种方式，压缩格式或不压缩格式，压缩模式所不同的就是其入口位于arch/ /boot/compressed/head.S,为与该路径下的代码主要负责执行执行前期的初始化为解压内核做准备。当完成解压内核后，就跳转到./arm/kernel/head.S开始启动内核。

本文仅分析不压缩方式启动内核，通过分析内核代码，整理出内核启动过程的部分顺序如下：

内核的启动与U-Boot一样，前面一段是汇编代码，然后跳转到C代码。汇编的入口在

./arm/kernel/head.S中，符号名为__HEAD，该文件包含了head-common.S。

所以从启动用户首进程init而言，我将其分成大致分为四大步：

head.S ,初始化通用部分环境，与芯片无关
start_kernel, head.S完成后，调准到start_kernel，进入C函数执行，该函数为于./init/main.c中
rest_init,创建init进程，以及kthredd进程，其中Init进程号为1，kthredd为内核进程。
启动调度器，执行kernel_init，该函数将调用根文件系统中的init执行文件，至此用户空间的init进程就启动起来了。

head.S/head-common.S作用

剖析汇编代码比较枯燥，这里就不进行描述了。仅就其作用进行总结：

检查架构，处理器和机器类型。
配置MMU，创建页表条目并启用虚拟内存。
在init / main.c中调用start_kernel函数。
所有架构的代码相同。这也是为什么采用汇编代码的原因，规避针对不同芯片管理大量重复代码。

start_kernel阶段

该函数主要完成以下以下工作：

lockdep 死锁检测模块初始化，
RCU机制初始化：RCU(Read-Copy Update)，顾名思义就是读-拷贝修改，它是基于其原理命名的。对于被RCU保护的共享数据结构，读者不需要获得任何锁就可以访问它，但写者在访问它时首先拷贝一个副本，然后对副本进行修改，最后使用一个回调（callback）机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。
SMP初始化，对称多处理"（Symmetrical Multi-Processing）简称SMP，完成CPU ID的创建。
debug_objects_early_init，负责调试对象初始化，以便于内核调试
lockdep死锁检测模块初始化，lockdep的工作方式是在内核中的锁定调用包起来。每次采用或释放特定类型的锁时，都会记录该事实以及辅助详细信息，例如处理器当时是否正在处理中断。Lockdep还记录了使用新锁时还持有哪些其他锁；这是lockdep能够执行的许多检查的关键。
调用setup_arch(&command_line)，该函数位于arch/
/kernel/setup.c，用于解析从bootloader传入的引导命令行。
初始化控制台，以打印启动日志。
初始化其他各子系统，如VFS,trace,内存管理子系统，FORK子系统，cgroup,acpi，proc文件系统，内核服务，缓存等等。
……
调用rest_init，以创建init进程以及内核进程，并启动内核调度器。

rest_init阶段

代码如下，其注释如下，主要作用就是先创建init进程使其进程号为1，这是第一个用户空间进程，该进程执行后在衍生出一系列的应用进程。具体取决于启动脚本或者Init的具体实现。然后创建内核进程kthreadd，该进程用于管理内核进程。该进程进程号为2。所有内核进程都是kthreadd的后代， kthreadd枚举其他内核线程；它提供了接口例程，内核服务可以在运行时动态生成其他内核进程。通过kthread_create_list维护其他内核进程。可以使用ps -ef命令从命令行查看内核线程-它们显示在[方括号]中：

static noinline void __init_refok rest_init(void)
{
    int pid;

    rcu_scheduler_starting();
    smpboot_thread_init();

    /*创建init进程，第一个用户空间进程我们
    *需要首先生成init，以便它获得pid 1，但是
    *init任务最终将要创建kthread，如果在创建
    *kthreadd之前对其进行调度，则OOPS。*/
    kernel_thread(kernel_init, NULL, CLONE_FS);
    numa_default_policy();

    /*创建kthreadd用于管理内核线程*/
    pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);

    /*RCU 锁*/
    rcu_read_lock();
    kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
    rcu_read_unlock();
    /*让内核进程kthreadd处于就绪态TASK_NORMAL*/
    complete(&kthreadd_done);

    /* 启动调度器      */
    init_idle_bootup_task(current);
    schedule_preempt_disabled();
    /* 禁用抢占的情况下调用cpu_idle */
    cpu_startup_entry(CPUHP_ONLINE);
}

kernel_init阶段

当内核调度器运行后，就会执行kernel_init函数：

static int __ref kernel_init(void *unused)
{
    int ret;

    kernel_init_freeable();
    /* 同步完成所有初始化操作 */
    async_synchronize_full();
#ifndef CONFIG_INITCALLS_THREAD
    free_initmem();
#endif
    mark_readonly();
    system_state = SYSTEM_RUNNING;
    numa_default_policy();

    flush_delayed_fput();

    /*如果使能了ramdisk执行命令启动init*/
    if (ramdisk_execute_command) {
        ret = run_init_process(ramdisk_execute_command);
        if (!ret)
            return 0;
        pr_err("Failed to execute %s (error %d)\n",
               ramdisk_execute_command, ret);
    }

    /* 如果execute_command使能，则按命令启动init*/
    if (execute_command) {
        ret = run_init_process(execute_command);
        if (!ret)
            return 0;
        panic("Requested init %s failed (error %d).",
              execute_command, ret);
    }

    /*如果前面两项都没有使能，则依次在根文件系统下寻找并启动Init*/
    if (!try_to_run_init_process("/sbin/init") ||
        !try_to_run_init_process("/etc/init") ||
        !try_to_run_init_process("/bin/init") ||
        !try_to_run_init_process("/bin/sh"))
        return 0;

    panic("No working init found.  Try passing init= option to kernel. "
          "See Linux Documentation/init.txt for guidance.");
}