qualcomm amss 文件結構以及編譯流程分析

AMSS的source實際上是Qualcomm平臺的的底層部分，去掉了爲應用程序提供接口的AEE(application execution environment)部分，高通在DualProc芯片上的其他平臺基本上都是採用的這樣的架構。所以如果要了解這套source的話有必要對BREW作一個基本的瞭解，不需要了解它應用程序的運作機制，只需要瞭解底層的操作系統，尤其是REX(Run Time Executive)的運行機制必須瞭解。在6K平臺只有單芯片（ARM9或者ARM11）。在7K&8K平臺硬件上採用的是ARM9+ARM11（最新的採用Cotex-A8或是Cotex-A9）的架構。其中ANDROID是在ARM11上運行，而ARM9部分負責處理通信協議、射頻、GPIO等，或者可以稱作MODEM端，同樣也運行一個OS，稱爲AMSS（Advanced Mobile Subscriber Software）

如圖爲7x&8x平臺

1. amss 文件結構

1.1  amss的文結構目錄

不通的平臺會有些差別的

--7627

    |-- 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
    |--brewmp           //platform
    |--bsp              //board support packag
    |-- 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)

qualcomm 原意：AMSS 7200 software is organized in a hierarchically distributed fashion, with software code for functionally distinguishable blocks, protocol layers, and subsystems in separate subdirectories.Each subbuild directory has its own clearly defined build entry point, which is utilized at the top level to build that particular subdirectory.【 CL93-V5332-1_T_Building_AMSS_SW.pdf   10.節】

所有這些source都是通過Rex(real time executive)將其組織起來的，再看AMSS啓動以後運行狀態：

2。編譯環境以及編譯工具

編譯環境的搭建就不做贅述，一般的話公司都有個相關的文檔，這裏指介紹一下主要的工具以及作用。

編譯AMSS的source有兩種方式：一是在windows下編譯 ，另一是在linux下編譯。因爲無法取得linux環境下的RVCT2.2的licence，所以通常情況下都是在windows環境下編譯。 

編譯所需要的工具編譯所需要的工具編譯所需要的工具編譯所需要的工具     

名稱	版本	說明
GNU make cygwin	3.81	（c/c++跨平臺交叉編譯工具：cygwin|minGW|GNUWIN32，三者的區別差異參考）
RVDS (RVCT) 2.2.1	BLD593
Perl	5.8.5 or later	目前安裝的是5.6，Perl稱爲“實用報表提取語言”（Practical Extraction and Report Language），用到了Perl對AMSS整個代碼中腳本的解析功能
Python	2.4.x	（ 注意：必須是Python2.4.X 版本太高了反而不行。）
elfweaver.exe

 特別建議：配置文件中有些目錄的設置，建議編譯工具統一安裝在同一個目錄下，便於代碼提交更新。如C:\utils。而對於cygwin，RVDS (RVCT) 2.2.1和elfweaver.exe是在安裝的時候是不需要重複安裝的，可以拷貝到其他電腦使用。

<三> AMSS的編譯系統

   總算把AMSS這套Makefile整完了，比起Android來QC這套Makefile還是比較爛的，架構不清晰，很多重複的規則，一個模塊要不要加入需要判斷三次，模塊的路徑上判斷一次，模塊的*.min要判斷一次，模塊的OBJ文件上還要判斷一次，而且基本target都加了強制目標作爲依賴，導致很多目標每次編譯時都被強制更新，間接導致了每次編譯的時間都特別的長。

    AMSS把QCSBL/OEMSBL/CFG_DATA/PARTITION/AMSS/FLASH_TOOL用MAKE－C來分開編譯，這在實現上比Android那種一切皆模塊簡單多了，不過個人覺得這樣很容易導致父MAKE和子Make變量之間的混亂，尤其涉及到這麼多export變量的時候。閒話就不多說了，看看這套Make吧～～

    雖然說架構不清晰，但是這套Make還是有一個比較通用的系統結構的：

  首先是定義一些全局變量，這些變量大多數都是路徑啊，以及與芯片和編譯器相關的一些FLAG，還有一個最重要的全局變量就是USES_XXX，這種類型的變量定義我們最後需要將什麼模塊編譯進系統。定義完這些全局變量之後下面一個就是編譯器（RVCT）相關的一些編譯選項，比如說CPU結構啊，編譯是時間優先還是空間優先啊以及一些初始化的CFLAGS/AFLAGS/LCFLAGS等等。全局變量以及編譯器選定以後下面就是選擇要編譯的模塊，QC把模塊放在3個部分，一個是模塊的路徑，另外一個是模塊的本地Make文件*.min，最後一個就是模塊要生成的OBJ文件。個人覺得這樣分開的結果導致模塊相當亂，什麼東西都要來三次，效率還是比較低的。瞭解需要編譯的模塊以後最後就是生成最終目標所需要的一系列規則了，包括生成.o和最終的IMG的一系列規則。下面是一個稍微比較消息的描述：

    AMSS make的最終目標是dmss，定義在dmss_rules.min裏面，而它最重要的一個依賴boot是定義在boot_targets_nonsec.min裏面，這個boot定義了大部分img生成的規則：

      

    除了amss.mbn和amsshd.mbn是在DMSS主Make中生成的以外，其他的IMG都是在子Make中生成的。partition.mbn是相對簡單的，oemsbl和qcsbl基本上採用了和DMSS實現的相同的架構，我這裏只是簡單的畫了下：

   

 appsbl因爲我們直接使用android的LK，所以不需要，直接在dmss_rules.min將其註釋掉就好了。基本上到這裏這套MAKE已經很清晰了，下面我們來看看如何判斷一個模塊是否被編譯，當然瞭解了一個模塊是否被編譯我們也能清楚的知道如何增加和去除一個模塊。