QC AMSS BUILD SYSTEM

http://blog.csdn.net/yili_xie/article/details/5656608

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

 

 

分享到： 

• 上一篇：vimrc
• 下一篇：GNU-ld链接脚本浅析

查看评论

11楼  beyondioi 2012-07-25 11:51发表 [回复]

我想要啊 可以图片出不来 能不能发给我啊
shenhuaarm@163.com 谢谢啊。

10楼  knightyf001 2012-04-30 20:26发表 [回复]

LZ大大，麻烦把您总结的代码架构图发给我学习下吧（博客里的显示不全），小弟最近看高通代码看地十分郁闷，knightyf@163.com，谢谢啦！

9楼  ricepot100 2012-03-28 23:45发表 [回复]

楼主真是神人啊....我最近在搞一个用7227A做的一个设备,也是MP+AP的双核架构,软件架构也是AMSS+Android,对几个partition.mbn的问题一直没有搞清楚(这里用的是Nandflash,2KB/per page,64pages/per block,8196blocks--->1GB)请楼主帮忙看看
1.查看编译出来的partition.mbn,其AMSS的offset是0x61A8,从partition.mbn的数据结构来看,说明AMSS在NandFlash的起始位置是第0x61A8(25000)个block,但是这已经远远超出了其nandflash的容量范围,请问是怎么回事?
2.从AP端的target_init函数,可以知道AP端实际上是以partition.mbn中APPS分区为起始分区,计算AP端的分区(比如Boot,Recovery,System,Cache等),并且可以看出,这些分区都应该依次在APPS分区记录的后面,所以APPS分区在partition.mbn中的offset+len至少都会在MP端的image的分区的后面(比如应该在OEMSBL,APPSBL后面),不过我这边的parittion.mbn中的APPS分区的offset是0x80,len也是0x80,这样实际上APPS分区的位置是在OEMSBL和APPSBL的前面,按照前面所说的,AP端的分区就会把MP端的分区冲掉,但是实际上,我用这个partition.mbn和升级文件升级,设备都是能正常运行的.让我十分纠结.
请问楼主有没有什么建议啊?

8楼  hanmingjun 2011-04-20 17:04发表 [回复]

[e01]

7楼  匿名用户 2010-07-14 10:43发表 [回复]

请问楼主，生产的mbn img文件是有一定结构的img,还是2进制指令流？

Re:  yili_xie 2010-07-14 11:42发表 [回复]

回复 匿名用户：I am sorry I have no idea about the mbn img, you can read the source of target tools

Re:  匿名用户 2010-07-14 12:50发表 [回复]

回复 yili_xie：/AMSS/AMSS/products/76XX/tools？

Re:  yili_xie 2010-07-14 13:25发表 [回复]

回复 匿名用户：No,they are the tools that generate the mbn format img. You can get their name from the command of related makefile rules ~

6楼  匿名用户 2010-07-08 17:20发表 [回复]

求画图工具nova.nwu@gmail.com

Re:  yili_xie 2010-07-14 11:44发表 [回复]

回复 匿名用户：xmind

5楼  匿名用户 2010-07-01 16:32发表 [回复]

可以发这些图片或者完整文档学习下吗？... 谢谢... liuwenzao@gmail.com

4楼  self_control 2010-06-24 13:43发表 [回复]

LZ可以发这些图片给我看下吗？
我在你的博文里只看到一半...
谢谢...
ander.dy@gmail.com

3楼  匿名用户 2010-06-15 20:49发表 [回复]

请问这是干嘛用的

2楼  匿名用户 2010-06-14 14:21发表 [回复] [引用] [举报]

[e01]

1楼  spritecola 2010-06-09 17:12发表 [回复]

虽然不搞这个， 但还需要[e01] 

楼主是用什么工具画图的？