高通开机流程(brew方案)

摘要:
    本文试图通过代码来深入剖析Qualcomm手机开机的整个过程,即从按下开机键一直到出现待机界面,Qualcomm的手机软件在整个流程中究竟完成了哪些工作。本文的主要目标是理清手机的初始化流程,并为今后Amoi定做初始化工作提供一个参考。
关键字:开机、Rex、TMC、ui_task、CoreApp

一、开机的简要流程分析
    Qualcomm的平台软件支持两种启动方式:一种是Nor Flash启动方式,另外一种就是Nand Flash启动方式。Nor Flash启动方式就相当于硬件直接找到一个入口点开始执行代码,相比较而言会 比较简单,且Amoi没有采用此种方式,所以本文对于这种方式不做详细分析。另外一种就是Nand Flash启动方式,这种方式和PC的启动方式比较相像,也是Amoi采用的Boot方式,下面将详细分析在此方式下面的开机过程。
    按下开机键之后,将产生一个时钟中断,从而通知AMSS主芯片的Boot Load硬件去将放置于Nand Flash上面的第一个Block(8K)里面的Boot代码Copy到内核内存(RAM,这个内存应该是CPU自带的内存,同后面提到的SDRAM有一定区别,可以把它当作CPU的Cache)的0xFFFF0000地址,并开始执行Boot代码。Boot的主要任务是完成整个系统的硬件初始化工作(类似于PC上面的BIOS所完成的硬件自检工作,至于Boot的详细工作机制,后文会有详细描述)。Boot所完成的工作里面,最重要的一件事就是会将整个手机软件代码(AMSS软件包)拷贝到SDRAM中,并最后将控制权交给AMSS软件。说白了,就是Boot执行完成之后,代码的执行点将由Boot跳转到AMSS软件的的入口点函数main().(此函数在mobile.c里实现)。
    代码运行到了Main()之后,在这个函数里面将完成操作系统(rex)的初始化工作,其实现方法是调用    rex_init()。

Rex_init()完成的工作很简单:
    1.完成操作系统必要的一些数据结构(timer链表、任务链表等)的初始化;
    2.接下来,它创建了三个任务,分别是:rex_idle_task、rex_dpc_task和tmc_task。
    Idle任务没什么好解释的,目前这个任务为空,什么也没做,dpc_task目前不知道是做什么的,暂时可以不用管。前面的这两个任务都属于操作系统层面的,由操作系统来维护,和手机软件关系不大。哪一个和手机软件关系大呢?答案是:tmc_task。大家可以把这个当作操作系统的入口(主)任务,也可以把它当作整个手机软件的入口任务。即AMSS软件里的所有其它任务的创建和维护就是由这个tmc_task来完成的。
    到此为止,整个AMSS软件还并没有跑起来,只是跑到了tmc_task里面了。在tmc_task里面,会调用tmc_init()来完成整个AMSS软件包的初始化工作,其中最重要的一项工作就是调用tmc_define_tasks()将AMSS软件包所有需要的任务都创建起来了。比如说slee_task、dog_task、cm_task、wms_task、ui_task等。这些任务,一般不需要直接和AL(Application Layer)层软件打交道,但请大家记住,手机上所有功能的实现最根本点就是由这些服务组件(Service Task)来完成的。将来大家跟踪一个具体的功能模块时,比如说通话模块,如果需要,可以再去深入研究它的具体实现。
    好了,到现在为止,所有的AMSS核心软件就全部跑起来了(手机的功能模块,在软件方面就体现为OS层面的一个任务)。但现在大家还根本看不到Brew和AEE的影子。呵呵,各位不要急。到了这个层面之后,我想稍微多说几句。最早的Qualcomm平台,比如说5xxx系列,是根本没有Brew的,那个时候的AL(Application Layer)层软件开发,是直接调用底层Service task所提供的API来完成相应的工作的。从这种角度来看的话,显然那时的开发是比较郁闷和难度较高的。不过,到了65xx之后,Qualcomm平台引入了Brew,手机开发商就没必要去从这么底层(Service API)的层面进行手机开发了,他们完全可以基于Brew来实现一台手机的所有功能(Qualcomm给我们的参考代码,就是全Brew平台的)。
    Brew的运行环境AEE是如何跑起来的呢?关键在于ui_task(),由于ui_task和我们手机开发的关系非常密切,其地位也相当重要,所以,后文我将单独对它进行一个深入的研究与分析。到目前为止,大家只需要知道ui_task将AEE加载起来了,并且,它起到了一个中间层的作用,即所有AMSS底层服务组件的消息,都将经由ui_task而转到AEE,并最终转到具体的App(Applet)的执行代码里面(HandleEvent())。
    注意:
    1.上述的开机过程,在每一次按开机键都需要走一遍,即关机之后,整个系统的所有功能都将消失,而不像有些手机,看起来是关了机,但实际上底层还是有一些软件模块在跑。为什么可以肯定地说上述开机过程每次都必须走一遍,原因很简单,因为我们的平台软件是基于Nand Flash启动的,所有的代码都需要Copy到SDRAM才能运行,而关机断电之后,SDRAM里的东东会全部丢失,所以,毫无疑问,上述的过程必须每次开机都执行;
    2.关机的过程相对比较简单,系统检测到关机中断之后,将调用tmc_powerdown_handler()来完成关机动作,它将把所有AMSS的任务都Stop掉,并最后调用rex_exit()退出Rex,从而完成整个关机动作。
    3.显然,关机动作前,如果有必要,每一个任务必须将它希望保存的信息保存到Flash上面,以便下次开机时可以得到这些信息;

    说明:
    1.Tmc是操作系统层面和AMSS软件关系最密切的一个任务,不过需要OEM商在此处修改的地方应该不多;
    2.ui_task是在操作系统层面,OEM商需要重点研究清楚的一个任务,它是连接底层Task和上层AL的一个中间层,有可能需要加入OEM商的操作流程;
    3.CoreApp是在Brew层面的一个AL层的入口Applet,它其着管理整个上层AL层软件的作用,根据产品需求,这个App需要定做;
    4.AEE是整个上层App的运行环境,目前Qualcomm没有公开它的源码,但它的运行机制,Amoi需要好好研究清楚,我将在另外一篇《Qualcomm平台AEE运行机制深入分析与研究》中探讨它的运行机理和调度机制,大家有兴趣可以参考此文;

猜你喜欢

转载自blog.csdn.net/yedushu/article/details/83009477