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的執行和呼叫過程。