MSM平台上的AMSS
AMSS的source实际上是QC BREW(Binary Runtime Environment ForWireless)平台的的底层部分，去掉了为应用程序提供接口的AEE(application executionenvironment)部分，高通在DualProc芯片上的其他平台基本上都是采用的这样的架构。所以如果要了解这套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提供了底层运行环境包括L4microkernel，CS(componet service)，libstd(AEE的静态库)，rte(run timeenviroment) ：
|-- cs
|-- l4
|-- libstd
`-- rte
L4是微内核，提供地址空间，线程，IPC等功能；componentservice是在L4的基础上提供了一个rte，提供了内存保护，线程创建，同步等功能，以前高通没有发布BREW的时候，要提供更多的系统服务都是在CS添加的，QC定义了相关的接口可以让你增加RTE所能提供的功能；libstd里面包含了AEE的接口和一个静态的AEE库；rte里面主要是一些和IPC相关的内容。platform的内容我觉得我们只需要了解就行了，一般应该是不需要修改的，除了在CS中添加服务之外，不过这个应该也是很久以后的事情～～下面是MSM上面AMSS platform的架构：
我们着重来看看products里面的内容，在了解这部分source之前必须了解REX的一些特性。REX是一个抢占式，多任务的RTOS，所有的任务都以task的形式存在，REX提供包括任务创建，同步，互斥，计时器，中断控制等功能的API，这里的task实际上就是我们的线程，每个task对应着一个线程。REX维护一个tasklist(双向链表)，始终运行高优先级的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 // Drivers 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启动以后运行状态：
所有的AMSS task以线程的方式运行在CS kernelprocess中，包括CS的核心服务，都是以task的形式运行在REX之上的。这里的userprocess我猜测就是products/apps里面的类容。看完这个图以后我们再来详细一下AMSSsource的启动流程：qcsbl_main_ctl会跳到l4 kernel，l4 kernel启动好以后会启动igunarserver，然后启动rex进程(执行 /service/tmc/mobile.c 里的main函数)，amss/rex以一个进程的方式运行在l4 microkernel之上，所有的task都是L4的一个线程。
下面我们就仔细看看这个main函数，在这个main函数里面首先会调用rex_init来初始化REX，这里Qualcomm实现了一个tmc(task managercontroler)来作为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的执行和调用过程。
