在高通平臺的工程中存在兩個文件夾Android 和amss 或 amss_proc ,其下有兩個文件夾 adsp_proc,cdsp_proc,那麼什麼事amss 呢？
先記住一個概念 AMSS（Advanced Mobile Subscriber Software）先進移動用戶軟件，由Dual-Mode Subscriber Software(DMSS)升級而來。
一、首先簡單介紹一下，高通平臺7&8系列平臺的軟硬件架構。
如圖：
硬件上採用的是ARM9+ARM11（最新的採用Cotex-A8或是Cotex-A9）的架構。其中Android是在ARM11上運行，而ARM9部分負責處理通信協議、射頻、GPIO等，或者可以稱作MODEM端，同樣也運行一個OS，稱爲AMSS（Advanced Mobile Subscriber Software）。他們採用共享內存的方式來通信。
MSM平臺上的AMSS
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的架構：
我們着重來看看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啓動以後運行狀態：
所有的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的執行和調用過程。