MSM8909+Android5.1.1启动流程(5)---apps_init()
调用关系
kmain()--->bootstrap2()--->apps_init()
/* one time setup */ void apps_init(void) { conststruct app_descriptor *app; /*call all the init routines */ for(app = &__apps_start; app != &__apps_end; app++) { if(app->init) app->init(app); } /*start any that want to start on boot */ for(app = &__apps_start; app != &__apps_end; app++) { if(app->entry && (app->flags & APP_FLAG_DONT_START_ON_BOOT) ==0) { start_app(app); } } }
遍历所有在__apps_start 到__apps_end段里的函数,并调用LK中所谓的app的init函数,然后调用start_app(app),哪些app被放入 boot thread section, 则定义在 include/app.h 中的 APP_START(appname),app.h文件中相关定义:
#define APP_START(appname) structapp_descriptor _app_##appname __SECTION(".apps") = { .name =#appname,
#define APP_END };
aboot_init 就将在这里开始被运行,androidlinux 内核的加载工作就在 aboot_init 中完成的 。aboot.c中的定义如下:
APP_START(aboot)
.init= aboot_init,
APP_END
为了更好理解,看对应的system-onesegment.ld文件(该文件在”bootable\bootloader\lk\ build-目标平台”目录下),
system-onesegment.ld
.rodata : { *(.rodata.rodata.* .gnu.linkonce.r.*) .= ALIGN(4); __commands_start= .; KEEP(*(.commands)) __commands_end= .; .= ALIGN(4); __apps_start= .; KEEP(*(.apps)) __apps_end= .; .= ALIGN(4); __rodata_end= . ; }
原来,在其最终的连接文件里,是将需要启动的apps括在了SECTIONS下的.rodata段中,且以__apps_start为开头,以__apps_end标志结束(这里涉及到文件结构的部分内容,内容拓展可以看《程序员的自我修养—链接、装载与库》一书)。
正如网上所说“在 app 中只要像 app/aboot/aboot.c 指定就会在 bootloader bootup 时放入 thread section 中被执行”。这点我们可以直接在整个lk中搜索关键字“APP_START”会发现我们的bootloader中到底有多少个类似这样的app(不同的bootloader情况有所不同):
图1
可知满足条件的app有pcitests、stringtests、tests、aboot、clocktests和shell
后面我们接着学习aboot_init()
参考:
平述factory reset ——从main system到重引导流程
http://blog.csdn.net/loongembedded/article/details/51635999