Linux 内核启动挂载android根文件系统过程分析

 源代码编译来的,编译后在/out/target/product/generic/root/

其源码在/system/core/init/init.c

Init.c 主要功能:

(1)安装SIGCHLD 信号。(如果父进程不等待子进程结束,子进程将成为僵尸进程(zombie)从而占用系统资源。因此需要对SIGCHLD 信号做出处理,回收僵尸进程的资源,避免造成不必要的资源浪费。)
(2)对umask 进行清零。
        何为umask,请看http://www.szstudy.cn/showArticle/53978.shtml
(3)为rootfs 建立必要的文件夹,并挂载适当的分区。
/dev (tmpfs)
/dev/pts (devpts)
/dev/socket
/proc (proc)
/sys (sysfs)
(4)创建/dev/null 和/dev/kmsg 节点。
(5)解析/init.rc,将所有服务和操作信息加入链表。
(6)从/proc/cmdline 中提取信息内核启动参数,并保存到全局变量。
(7)先从上一步获得的全局变量中获取信息硬件信息和版本号,如果没有则从/proc/cpuinfo 中提取,并保存到全局变量。
(8)根据硬件信息选择一个/init.(硬件).rc,并解析,将服务和操作信息加入链表。
在G1 的ramdisk 根目录下有两个/init.(硬件).rc:init.goldfish.rc 和init.trout.rc,init 程序会根据上一步获得的硬件信息选择一个解析。
(9)执行链表中带有“early-init”触发的的命令。
(10)遍历/sys 文件夹,是内核产生设备添加事件(为了自动产生设备节点)。
(11)初始化属性系统,并导入初始化属性文件。
(12)从属性系统中得到ro.debuggable,若为1,則初始化keychord 監聽。
(13)打開console,如果cmdline 中沒有指定console 則打開默認的 /dev/console
(14)讀取/initlogo.rle(一張565 rle 壓縮的位圖),如果成功則在
/dev/graphics/fb0 顯示Logo,如果失敗則將/dev/tty0 設為TEXT 模式并打開/dev/tty0,輸出文“ANDROID”字樣。
(15)判斷cmdline 中的參數,并设置属性系统中的参数:
1、 如果 bootmode 為
- factory,設置ro.factorytest 值為1
- factory2,設置ro.factorytest 值為2
- 其他的設ro.factorytest 值為0
2、如果有serialno 参数,則設置ro.serialno,否則為""
3、如果有bootmod 参数,則設置ro.bootmod,否則為"unknown"
4、如果有baseband 参数,則設置ro.baseband,否則為"unknown"
5、如果有carrier 参数,則設置ro.carrier,否則為"unknown"
6、如果有bootloader 参数,則設置ro.bootloader,否則為"unknown"
7、通过全局变量(前面从/proc/cpuinfo 中提取的)設置ro.hardware 和
ro.version。
(16)執行所有触发标识为init 的action。
(17)開始property 服務,讀取一些property 文件,這一動作必須在前面
那些ro.foo 設置后做,以便/data/local.prop 不能干預到他們。
- /system/build.prop
- /system/default.prop
- /data/local.prop
- 在讀取默認的 property 后讀取 presistent propertie,在 /data/property 中
(18)為 sigchld handler 創建信號機制
(19)確認所有初始化工作完成:
device_fd(device init 完成)
property_set_fd(property server start 完成)
signal_recv_fd (信號機制建立)
(20) 執行所有触发标识为early-boot 的action
(21) 執行所有触发标识为boot 的action
(22)基于當前property 狀態,執行所有触发标识为property 的action
(23)注冊輪詢事件:
- device_fd
- property_set_fd
-signal_recv_fd
-如果有keychord,則注冊keychord_fd
(24)如果支持BOOTCHART,則初始化BOOTCHART
(25)進入主進程循環:
- 重置輪詢事件的接受狀態,revents 為0
- 查詢action 隊列,并执行。
- 重啟需要重啟的服务
- 輪詢注冊的事件
- 如果signal_recv_fd 的revents 為POLLIN,則得到一個信號,獲取并處

- 如果device_fd 的revents 為POLLIN,調用handle_device_fd
- 如果property_fd 的revents 為POLLIN,調用handle_property_set_fd
- 如果keychord_fd 的revents 為POLLIN,調用handle_keychord
到了这里,整个android 文件系统已经起来了。

初始化核心的核心init.rc文件分析

在上面红色那一行(5)解析/init.rc,将所有服务和操作信息加入链表。

       parse_config_file("/init.rc");//在init.c 中代码 (有关 /init.rc的脚本我就不贴出来了)

名词解释:
       Android 初始化語言由四大类声明组成:行为类(Actions)、命令类(Commands)、服务类(Services)、选项类(Options)。
       初始化语言以行为单位,由以空格间隔的语言符号組成。C 风格的反斜杠转义符可以用来插入空白到语言符号。双引号也可以用来防止文本被空格分成多个语言符号。当反斜杠在行末时,作为换行符。

       * 以#开始(前面允许空格)的行为注释。
       * Actions 和Services 隐含声明一个新的段落。所有该段落下Commands 或 Options 的声明属于该段落。第一段落前的Commands 或Options 被忽略。
       * Actions 和Services 拥有唯一的命名。在他们之后声明相同命名的类将被当作错误并忽略。
          Actions 是一系列命令的命名。Actions 拥有一个触发器(trigger)用来決定action 何時执行。当一个action 在符合触发条件被执行时,如果它还没被加入到待执行队列中的话,則加入到队列最后。队列中的action 依次执行,action 中的命令也依次执行。

           Init 在执行命令的中间处理其他活动(设备创建/销毁,property 设置,进程重启)。

          Actions 的表现形式:
          on <trigger>
          <command>
          <command>
          <command>

          重要的数据结构两个列表,一个队列。
static list_declare(service_list);
static list_declare(action_list);
static list_declare(action_queue);

         *.rc 脚本中所有 service 关键字定义的服务将会添加到 service_list 列表中。
         *.rc 脚本中所有 on 关键开头的项将会被会添加到 action_list 列表中。每个action 列表项都有一个列表,此列表用来保存该段落下的 Commands。

脚本解析过程:
parse_config_file("/init.rc")
int parse_config_file(const char *fn)
{
    char *data;
    data = read_file(fn, 0);
    if (!data)                                                                                                                                                     return -1;
    parse_config(fn, data);
    DUMP();
    return 0;
}
static void parse_config(const char *fn, char *s)                                                                                          {
    ...
   case T_NEWLINE:
   if (nargs) {
       int kw = lookup_keyword(args[0]);
       if (kw_is(kw, SECTION)) {
           state.parse_line(&state, 0, 0);
           parse_new_section(&state, kw, nargs, args);
       } else {
           state.parse_line(&state, nargs, args);
       }
       nargs = 0;
    }
...


parse_config 会逐行对脚本进行解析,如果关键字类型为 SECTION ,那么将会执行parse_new_section();
类型为 SECTION 的关键字有: on 和 sevice

关键字类型定义在 Parser.c (system\core\init) 文件中
Parser.c (system\core\init)
#define SECTION 0x01
#define COMMAND 0x02
#define OPTION 0x04
关键字                 属性
capability,          OPTION, 0, 0)
class,                 OPTION, 0, 0)
class_start,        COMMAND, 1, do_class_start)
class_stop,       COMMAND, 1, do_class_stop)
console,             OPTION, 0, 0)
critical,              OPTION, 0, 0)
disabled,          OPTION, 0, 0)
domainname,    COMMAND, 1, do_domainname)
exec,                 COMMAND, 1, do_exec)
export,              COMMAND, 2, do_export)
group,              OPTION, 0, 0)
hostname,         COMMAND, 1, do_hostname)
ifup,                   COMMAND, 1, do_ifup)
insmod,            COMMAND, 1, do_insmod)
import,               COMMAND, 1, do_import)
keycodes,         OPTION, 0, 0)
mkdir,               COMMAND, 1, do_mkdir)
mount,              COMMAND, 3, do_mount)
on,                   SECTION, 0, 0)
oneshot,           OPTION, 0, 0)
onrestart,         OPTION, 0, 0)
restart,             COMMAND, 1, do_restart)
service,           SECTION, 0, 0)
setenv,             OPTION, 2, 0)
setkey,             COMMAND, 0, do_setkey)
setprop,          COMMAND, 2, do_setprop)
setrlimit,           COMMAND, 3, do_setrlimit)
socket,           OPTION, 0, 0)
start,                COMMAND, 1, do_start)
stop,             COMMAND, 1, do_stop)
trigger,           COMMAND, 1, do_trigger)
symlink,           COMMAND, 1, do_symlink)
sysclktz,         COMMAND, 1, do_sysclktz)
user,             OPTION, 0, 0)
write,             COMMAND, 2, do_write)
chown,             COMMAND, 2, do_chown)
chmod,            COMMAND, 2, do_chmod)
loglevel,          COMMAND, 1, do_loglevel)
device,             COMMAND, 4, do_device)

parse_new_section() 中再分别对 service 或者 on 关键字开头的内容进行解
析。
...
case K_service:
        state->context = parse_service(state, nargs, args);
        if (state->context) {
             state->parse_line = parse_line_service;
           return;
        }
        break;
case K_on:
        state->context = parse_action(state, nargs, args);
        if (state->context) {
            state->parse_line = parse_line_action;
           return;
        }
        break;
...

对 on 关键字开头的内容进行解析
static void *parse_action(struct parse_state *state, int nargs, char **args)
{
    ...
    act = calloc(1, sizeof(*act));
    act->name = args[1];
    list_init(&act->commands);
    list_add_tail(&action_list, &act->alist);
    ...
}

对 service 关键字开头的内容进行解析
static void *parse_service(struct parse_state *state, int nargs, char **args)
{
    struct service *svc;
    if (nargs < 3) {
        parse_error(state, "services must have a name and a program\n");
        return 0;
    }
    if (!valid_name(args[1])) {
        parse_error(state, "invalid service name '%s'\n", args[1]);
        return 0;
     }
//如果服务已经存在service_list 列表中将会被忽略
    svc = service_find_by_name(args[1]);
    if (svc) {
        parse_error(state, "ignored duplicate definition of service '%s'\n", args[1]);
        return 0;
    }
    nargs -= 2;
    svc = calloc(1, sizeof(*svc) + sizeof(char*) * nargs);
     if (!svc) {
        parse_error(state, "out of memory\n");
        return 0;
    }
     svc->name = args[1];
    svc->classname = "default";
    memcpy(svc->args, args + 2, sizeof(char*) * nargs);
    svc->args[nargs] = 0;
    svc->nargs = nargs;
    svc->onrestart.name = "onrestart";
    list_init(&svc->onrestart.commands);
//添加该服务到 service_list 列表
    list_add_tail(&service_list, &svc->slist);
    return svc;
}

服务的表现形式:
service <name> <pathname> [ <argument> ]*
<option>
<option>
...

       申请一个service 结构体,然后挂接到service_list 链表上,name 为服务的名称,pathname 为执行的命令,argument为命令的参数。之后的 option 用来控制这个service 结构体的属性,parse_line_service 会对 service 关键字后的内容进行解析并填充到 service 结构中 ,当遇到下一个service 或者on 关键字的时候此service 选项解析结束。
例如:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    socket zygote stream 666
   onrestart write /sys/android_power/request_state wake
服务名称为: zygote
启动该服务执行的命令: /system/bin/app_process
命令的参数: -Xzygote /system/bin --zygote --start-system-server
socket zygote stream 666: 创建一个名为:/dev/socket/zygote 的 socket ,

类型为:stream


====

http://www.4ucode.com/Study/Topic/1307314


内核启动无法挂载根文件系统的问题

这类问题很常见,先总体介绍一下解决思路。

能出现让人激动的的控制台,那么系统移植已经接近完成;但是不少人在最后一步出现问题。

要点如下:

1. 在正确的位置烧写正确格式的文件系统映象:

2. 内核支持这种文件系统格式

3. 文件系统的内容要完备

 

上面说得简单,一个个介绍。

 

1. 在正确的位置烧写正确的文件系统映象:

 

(a). 正确的位置

嵌入式开发中,常通过bootloader烧写文件系统映象,假设写在flash的地址A处。

内核启动时,显然要从地址A处读取文件系统,内核是怎么知道的呢?通过命令行参数,比如“root=/dev/mtdblock2 ”。/dev/mtdblock2 又是怎么和地址A对应上的呢?内核将flash划分为

几个分区,这是在代码中固定的。/dev/mtdblock2是第3个分区,它的开始地址必须是A。

在内核启动时,可以看到这些分区的开始地址、结束地址,比如内核启动时会有类似下面的信息:

Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit":

0x00000000-0x00030000 : "bootloader"

0x00050000-0x00250000 : "kernel"

0x00250000-0x03ffc000 : "root"

对于上面的内核信息,/dev/mtdblock2对应root分区,开始地址为0x00250000,使用bootloader写文件系统映象时,烧写的地址必须是0x00250000

所以,要保证3点:① bootloader烧到地址A,② 地址A是内核某个分区的开始地址,③ 命令行参数“root=/dev/mtdblockXXX ”是这个分区

 

(b). 正确格式的文件系统映象

不同的bootloader支持的烧写的文件系统映象格式不同、使用的烧写命令也可能不同,请注意这点。

另外,马大哈们制作文件系统映象时,使用的工具也不要弄错了。

最后,请保证这个文件系统映象是“真的烧写了”,因为如果flash只是擦除而没有烧写,它也是“正确的、可以挂接的文件系统”──有人碰到这个问题,我和他答非所问地折腾了很久。

 

2. 内核支持这种文件系统格式

配置内核时选上要支持的文件系统格式

1、2这两个问题如果不能保证,内核启动时会出现类似如下错误:

VFS: Cannot open root device "mtdblock2" or unknown-block(2,0)

Please append a correct "root=" boot option

如果1、2能保证,就可以挂接上文件系统,出现类似下面的字样时,革命已经成功了80%:

VFS: Mounted root (cramfs filesystem) readonly.

Freeing init memory: 116K

 

3. 文件系统的内容要完备

挂接文件系统后,内核就会读取、执行文件系统中的某个文件,通过它来启动应用程序。这个文件要么通过命令行参数“init=xxxx”来指定,要么取默认的文件(下面说明)。

一般制作文件系统映象时,都是在一个目录(假设目录名为rootfs)下放好各种东西:bin/,sbin/,lib/等目录,etc/fstab等文件,然后将这个目录制作为文件系统映象。

可以想象,如果这个目录中的东西不对、不全,即使制作出了文件系统映象,也只是能识别出来,挂接上去;但是启动不了──所谓启动,不就是执行文件系统中的程序嘛?

这时会有类似以下的错误:

Failed to execute /linuxrc. Attempting defaults...

Kernel panic - not syncing: No init found. Try passing init= option to kernel.

它说得很明显,"Failed to execute /linuxrc"──执行/linuxrc失败:

它为什么要执行/linuxrc,还不是因为你在命令行中加入了“init=/linuxrc”这个参数。

 

它为什么会失败?原因有二:

一、你制作文件系统映象时,rootfs目录下有linuxrc这个文件吗?

二、rootfs目录的linuxrc文件是正确的吗?

 

请好好确定这两点,大多数是没有linuxrc文件──linuxrc是busybox自动生成的,只要配置好就可以。

如果有linuxrc,那么就是它无法执行了(解决方法在下面)。

不用linuxrc行不行?当然行!看看内核文件init/main.c,有如下字样:

run_init_process("/sbin/init");

run_init_process("/etc/init");

run_init_process("/bin/init");

run_init_process("/bin/sh");

panic("No init found. Try passing init= option to kernel.");

就是说,它会依次尝试执行/sbin/init、/etc/init、/bin/init、/bin/sh这些文件,都失败后才打印出错信息"No init found. Try passing init= option to kernel."。

所以,出现这个出错信息时,就表明了没有或是无法执行这些文件:命令行参数“init=xxxx”来指定的xxx文件、/sbin/init、/etc/init、/bin/init、/bin/sh。

 

一、请检查你的rootfs目录,看看这点些文件是否存在

二、使用file命令看看它们是什么文件类型,是否可执行。

 

使用busybox时,这些文件是到/bin/busybox文件的链接,那就看看busybox的文件类型,可以使用下面的命令:

$ file linuxrc

linuxrc: symbolic link to `bin/busybox'

$ file bin/busybox

bin/busybox: ELF 32-bit LSB executable, ARM, version 1, for GNU/Linux 2.4.3, dynamically linked (uses shared libs), stripped

注意了:如果bin/busybox 是一个动态链接的文件,还要把它用到的库复制到rootfs中。唉,越说越复杂了。这些库在交叉编译工具的相应目录下,如果不知道,查google,否则再发帖。

 

最后一点,文件系统中各种配置文件、dev目录也要正确。出现问题时再在这个帖子中说吧。这样写下去真是没完没了。

回到这个帖子,它的内核打印信息为:

VFS: Mounted root (cramfs filesystem) readonly.

Freeing init memory: 116K

Failed to execute /linuxrc. Attempting defaults...

Kernel panic - not syncing: No init found. Try passing init= option to kernel.

说明文件系统挂接成功(VFS: Mounted root (cramfs filesystem) readonly.);

还说明/linuxrc不存在或者不可执行(Failed to execute /linuxrc. Attempting defaults...);

但是楼主的意思是linuxrc已经有了,内容为:

 

#!/bin/sh

echo "mount /etc as ramfs"

/bin/mount -n -t ramfs ramfs /etc

/bin/cp -a /mnt/etc/* /etc

echo "re-create the /etc/mtab entries"

# re-create the /etc/mtab entries

/bin/mount -f -t cramfs -o remount,ro /dev/mtdblock/3 /

/bin/mount -f -t ramfs ramfs /etc

exec /sbin/init

 

它是一个脚本,它的执行依赖于/bin/sh,问题转为:/bin/sh是否存在?是否可以执行?

用file命令看看它的类型、是否需要动态库。


评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值