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已经很清晰了，下面我们来看看如何判断一个模块是否被编译，当然了解了一个模块是否被编译我们也能清楚的知道如何增加和去除一个模块。