AMSS - Advanced Mobile Subscriber Software

 AMSS - Advanced Mobile Subscriber Software

         在高通7系列的架构中，一个IC内部集成有两个ARM处理器，一个ARM9，专门负责处理通信协议，射频以及GPIO等，另外一个是ARM11，用来处理多媒体，以及其他的一些任务。在ARM9端，有一个自己的操作系统，我们称之为AMSS (Advanced Mobile Subscriber Software)，在ARM11端，可以执行我们熟知的一些操作一些，例如linux。这两个处理器之间通过shared memory的硬件方式来沟通，操作系统之间通过RPC - remote procedure call的方式交互数据。表面看看起来二者之间的通信很容易理解，但其实在实际开发上却是不同的。由于ARM9是负责最直接的硬件IO的控制，因此处理默认的PIN定义可以有AMSS先做好之外，如果在linux执行的时候改变的话，必须通过RPC去请求ARM9上面的AMSS来处理。然而，RPC是利用Shared memory driver来forward，由于shared memory driver是没有原始码的，因此对于linux kernel里面的driver来讲，有部分的API等同于是没有源码与追踪的。只能假设share memory里面的程序是没有问题的。
下面来看看AMSS的软件架构
|-- 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的架构：

AMSS里面的就是amss的源码，包含platform以及我们对这个芯片提供的一些服务，这些服务都以task的形式存在products下。
在/AMSS/platform下包含有l4， cs， libstd， 与rte。这些为/AMSS/products下的task提供了底层运行环境。L4是内核，提供地址空间、线程、IPC等功能；cs(component service)实在L4的基础上提供了一个rte(run time environment)，提供了内存保护，线程创建、同步等功能，高通定义了相关的接口可以让我们增加RTE所能提供的功能；libstd里面包含了AEE(application executive)的接口和一个静态的AEE库；rte里面包含一些与IPC有关的内容。
在/AMSS/products下包含很多内容，详情如下：
|-- 76XX
     |-- 1x                      // Source code for CDMA 1x protocol
     |-- apps                  // Source code for some BREW apps, such as core and UI
     |-- apps_proc         // Application 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 protocal
     |-- modem             // Modem AMSS source code
     |-- modem_proc    // Modem AMSS boot files
     |-- multimedia       // Multimedia files, including audio, video, etc.
     |-- nas                  // Source code for NAS layer protocal
     |-- 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 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