AMSS的source实际上是QC BREW(Binary Runtime Environment For Wireless)平台的的底层部分,去掉了为应用程序提供接口的AEE(application execution environment)部分,高通在Dual Proc芯片上的其他平台基本上都是采用的这样的架构。所以如果要了解这套source的话有必要对BREW作一个基本的了解,不需要了解它应用程序的运 作机制,只需要了解底层的操作系统,尤其是REX(Run Time Executive)的运行机制必须了解。
     首先我们来看看这套source的基本结构:
     |-- AMSS
     |   |-- platform
     |   `-- products
     `-- AMSS_CUST
         `-- products
     AMSS是我们的source,包含platform以及我们对这个芯片提供的一些服务,所有服务都以TASK的形式存在products下。现在 source的配置是针对SURF的,如果是我们自己的板子就必须配置AMSS_CUST目录下的3个配置文件,然后拷贝到AMSS相应目录下后重新编 译。3个文件都是boot相关的,陈琦同学应该很清楚其中的配置~~
    |-- modem_proc
    |   `-- drivers
    |       `-- boot
    |           |-- 7627
    |           |   `-- boot_mem_ddr.s
    |           `-- pm_vreg_target.h
    `-- secboot
       `-- cfg_data
           `-- 7627
               `-- ebi1
                   `-- ebi1.cfg
      下面我们来看看AMSS里面的内容,首先来看看platform,platform为products下的TASK提供了底层运行环境包括L4 microkernel,CS(componet service),libstd(AEE的静态库),rte(run time enviroment) :
      |-- cs
      |-- l4
      |-- libstd
      `-- rte
      L4是微内核,提供地址空间,线程,IPC等功能;component service是在L4的基础上提供了一个rte,提供了内存保护,线程创建,同步等功能,以前高通没有发布BREW的时候,要提供更多的系统服务都是在 CS添加的,QC定义了相关的接口可以让你增加RTE所能提供的功能;libstd里面包含了AEE的接口和一个静态的AEE库;rte里面主要是一些和 IPC相关的内容。platform的内容我觉得我们只需要了解就行了,一般应该是不需要修改的,除了在CS中添加服务之外,不过这个应该也是很久以后的 事情~~下面是MSM上面AMSS platform的架构:

ARCH

我们着重来看看products里面的内容,在了解这部分source之前必须了解REX的一些特性。REX是一个抢占式,多任务的RTOS,所有 的任务都以task的形式存在,REX提供包括任务创建,同步,互斥,计时器,中断控制等功能的API,这里的task实际上就是我们的线程,每个 task对应着一个线程。REX维护一个task list(双向链表),始终运行高优先级的task。products里面所有的服务包括3g协议栈等都是以task的形式跑在rex之上的。
     了解了REX的基本特性,我们先overview一下products下面的类容:
`-- 76XX
    |-- 1x                              // Source code for CDMA 1X protocol
    |-- apps                          // Source code for some Brew apps such as core and ui
    |-- apps_proc                 // Applications boot loader
    |-- build                          // Trace32 JTAG script for building, build image, and log
    |-- core                           // Shared APIs folder
    |-- dal                             // Device abstract layer code
    |-- data                          // Source code for data services
    |-- drivers                      // Driver s for LCD, peripherals, etc.
    |-- hal                            // Hardware abstract layer code
    |-- hdr                           // Source code for high data rate protocol
    |-- modem                     // Modem AMSS source code
    |-- modem_proc            // Modem AMSS boot files
    |-- multimedia               // Multimedia files, including audio, video, etc.
    |-- nas                          // Source code for NAS layer protocol
    |-- secboot                   // Boot loaders, from PBL to OEMSBL
    |-- services                   // Source code for services
    |-- tools                        // Code for Flash operations
    |-- wcdma                     // Source code for WCDMA protocol
    `-- wconnect                // BT soc config and ftm(factory test mode)
    上面这些介绍只是给大家一个整体的印象,所有这些source都是通过Rex将其组织起来的,我们看看AMSS启动以后运行状态:
     

 PROCESS


     所有的AMSS task以线程的方式运行在CS kernel process中,包括CS的核心服务,都是以task的形式运行在REX之上的。这里的user process我猜测就是products/apps里面的类容。看完这个图以后我们再来详细一下AMSS source的启动流程:qcsbl_main_ctl会跳到l4 kernel,l4 kernel启动好以后会启动igunar server,然后启动rex进程(执行 /service/tmc/mobile.c 里的main函数 ),amss/rex以一个进程的方式运行在l4 microkernel之上,所有的task都是L4的一个线程。
     下面我们就仔细看看这个main函数,在这个main函数里面首先会调用rex_init来初始化REX,这里Qualcomm实现了一个 tmc(task manager controler)来作为rex启动好以后的第一个TASK,最后由这个task启动其他所有需要的task,并调用rex的系统函数对这些task进 行管理,通过跟踪这些task我们就能很完整地看到一个功能是如何从最上层的task到底层的驱动的,比如说pmic,nv,sim等这些服务都是以 task的形式运行在rex之上的。
      products/76xx/services/tmc.c 里面的tmc_define_tasks这个函数通过的宏的判断来决定需要启动哪些task,而这些宏的控制又是通过products/76xx /build/ms/cust*******.h 和 products/76xx/build/ms/target******.h来控制的,在编译的时候通过配置tsncjnlym.cmd之类的来控制一 些编译环境选项,以及那些模块需要编译,通过这些cust或者target头文件控制系统启动以后哪些task会被系统启动。我们看 products/76xx/services/tmc.c 下的tmc_define_tasks这个函数可以知道现在AMSS里面支持多少TASK,这个4000多行的函数里面全部都是调用rex系统函数 rex_def_task对task的定义,举个nv的例子:
     5374       rex_def_task(&nv_tcb,
     5375                    (rex_stack_word_type*) nv_stack,
     5376                    NV_STACK_SIZ,
     5377                    (rex_priority_type) NV_PRI,
     5378                    nv_task,
     5379                    0L);  
     其中nv_task就是这个task的入口函数,我们跟踪这个函数就能找到这个task的执行和调用过程。

原文地址:http://blog.csdn.net/yili_xie/article/details/5129469