魔兽秘籍助手-echarts自适应
![proconfig](/uploads/image/0276.jpg)
2023年4月6日发(作者:w908)
MemoryConfiguration
Wanghzh2010.03.29
sh
NORFlash的ROM和RAM都较小,要节省RAM只能是去掉不必要的功能或减少存储
PB/SMS等的条数,或者优化应用占用的RAM空间。ROM除了优化和节省代码和资源空
间,还可以通过调整代码区和文件系统区的大小来获得更多的代码区或用户空间。
以128+64MCP为例(Memory分配为Code:14MB,FS:2MB,用户区:355KB)的内存分
配图:
内存配置在custom_MemoryDevice.h文件中:
#defineNOR_BOOTING_NOR_FS_BASE_ADDRESS0xe00000
#defineNOR_BOOTING_NOR_FS_SIZE0x200000
#defineNOR_BOOTING_NOR_FS_FIRST_DRIVE_SECTORS710
其中,
NOR_BOOTING_NOR_FS_BASE_ADDRESS是配置code区域的大小,这里配置为0xe00000
即14MB。Code区中包含bootloader部分,固定占用128KB,所以实际可用的代码区是小
于14MB的。
NOR_BOOTING_NOR_FS_SIZE是配置文件系统区域的大小,这里配置为0x200000即2MB;
NOR_BOOTING_NOR_FS_FIRST_DRIVE_SECTORS是配置用户可见区域的大小,此配置
的单位是sector,1sector=512Bytes,此处的710表示710个sectors,即355KB。
文件系统分配参考文件:
NORFlash(ROM)
Bootloader
Code
FS
128KB
14MB
2MB
UserSpace355KB
FSOverhead7KB
FDMOverhead
Usedby
applications
415,232bytes
965KB
406KB
512bytes
315KB
LeftSpace
===========================================================
FSTotalSize2097152
FSFirstDriveSize363520
FSOverheadfor(MBR+PBR+RootDir)7168
FDMOverhead(NOR)415232
===========================================================
FreeSpaceforFoldersandApplications
FoldersandApplicationsRequirement(Clusters)965
315clustersareleft(315.0KB=0.31MB)
1.1如何调整code区和FS区的大小?
从上图可以看出,NOR_BOOTING_NOR_FS_BASE_ADDRESS和
NOR_BOOTING_NOR_FS_SIZE加起来就是整个Memory的大小。当CODE区不足时(编
译时log中会给出确切的超出尺寸),可以适当的减少FS系统区域的大小;反之,可以增加
FS系统的区域以增加用户区的大小。
注意:
1.针对Multi-Bank的MCP而言,如果要调整ROM的配置,前提是支持如下功能:
ENHANCED_SINGLE_BANK_NOR_FLASH_SUPPORT=TRUE
2.调整ROM的配置要严格一Block对齐(BLOCK的大小与具体的MCP相关,不同的
MCP的Block可能会不同),常见的Block是128KB。
3.根据编译结果,可以确定需要调整的大小,如:
#defineNOR_BOOTING_NOR_FS_BASE_ADDRESS0xE20000
#defineNOR_BOOTING_NOR_FS_SIZE0x1E0000
或
#defineNOR_BOOTING_NOR_FS_BASE_ADDRESS0xDE0000
#defineNOR_BOOTING_NOR_FS_SIZE0x220000
4.目前存在的未解决的问题(eserviceID:MAUI_02876563)
53_09A平台K6053S项目存在问题,当配置如下时是正常的:
#defineNOR_BOOTING_NOR_FS_BASE_ADDRESS0xdc0000
#defineNOR_BOOTING_NOR_FS_SIZE0x240000
但是修改为以下的配置,则无法开机,只显示了bootloader画面,然后就死机了:
#defineNOR_BOOTING_NOR_FS_BASE_ADDRESS0xde0000
#defineNOR_BOOTING_NOR_FS_SIZE0x220000
1.2调整用户可见区的大小
文件系统区分为几个部分:用户区、文件分区表头区、应用程序区以及预留区域。
用户区就是用户可见区域(FSFirstDriveSize),此区域可以分配的最大空间计算如下:
FSFirstDriveSize=FSTotalSize–Overhead–Applications–LeftSpace
其中,FSTotalSize是上一步分配的FS空间大小。
Overhead包括FSOverhead和FDMOverhead,FSOverhead基本是固定的,占用的空间也比
较小,可以不去考虑。FDMOverhead的大小是可以在custom_MemoryDevice.h进行调整的:
#defineNOR_FDM4_ESB_PARAMETER_ERASE_QUEUE_SIZE3
MTK默认的FDMOverhead大小为5个blocks(即5*128KB),最小值为3,不能小于3,
否则会导致错误。如非必要,尽量保持MTK的默认值,保证系统的稳定性和运行效率,
MTK反馈当用户区太小或者应用占用的系统区空间需要增大时,可以调整为3,不会影响
到手机的正常运行,但会对运行效率有一些影响,对于53这样的平台用户基本感觉不到,
因为影响效率的瓶颈不在此处。此配置调整的前提也需要支持如下option:
ENHANCED_SINGLE_BANK_NOR_FLASH_SUPPORT=TRUE
Applications区域是根据项目的不同配置而变化的,比如NVRAM增加或减少,PB和SMS
的最大条数的调整,WAP,JAVA,BT等配置的调整等都会影响到Applications区域的占用空
间。具体可以参考文件。
LeftSpace是系统区预留的空间,不能太小,比如10KB左右就会导致在开机时提示系统空
间不足(倒计时提示),有时开始时没有问题,但操作一些功能后再开机又会出现此提示。
针对此情况,MTK也没有给出具体应该预留多少,建议60KB~100KB或更多些。从目前的
版本情况看,超过30KB应该可以,但为保险起见,还是建议60KB以上。
1.3实现为不同的项目和客户需求自动配置Memory
综上,可以看出,配置Memory只需修改custom_MemoryDevice.h文件中的定义。由于此文
件是由编译前选定的MCP复制而来的,而MCP是公用的,不是为某一个项目或某一个需
求配置的,所以需要在编译开始之前将复制到目标路径custom_MemoryDevice.h进行修改。
custom_MemoryDevice.h这个文件比较特殊,不能像普通的头文件加入条件编译语句,所以
增加了一个perl脚本来完成需要的修改——。此脚本的执行要保证在sysgen
和emigen执行之前。
为增加Memory配置的灵活性,定义了两组宏分别用于项目配置和用户需求配置:
用于项目配置():当通用的MCP配置无法满足某个项目时定义。
TL_MEMORY_CUSTOM_ROM_CODE_SIZE_PROJECT(代码区大小)
TL_MEMORY_CUSTOM_FS_SIZE_PROJECT(文件系统区大小)
TL_MEMORY_CUSTOM_USER_SIZE_PROJECT(用户可见区大小)
用于客户需求配置():当通用的MCP配置无法满足某个客户需求时定义。
TL_MEMORY_CUSTOM_ROM_CODE_SIZE_USER(代码区大小)
TL_MEMORY_CUSTOM_FS_SIZE_USER(文件系统区大小)
TL_MEMORY_CUSTOM_USER_SIZE_USER(用户可见区大小)
脚本的基本思路如下:
1)检查是否用户需求中配置了MCP,如果没有配置则检查项目是否配置了MCP,如果也
没有配置则不需要修改memory配置;否则记录下各区域的大小。此处,为了简化实现,
必须3个区域都配置了才有效,且此处省去了配置各区域的校验。
2)打开custom_MemoryDevice.h这个文件,将文件内容读到一个字符串中,然后关闭。
3)在这个字符串中查找各区域定义的关键字,找到后使用配置的值替换掉。
4)再次打开custom_MemoryDevice.h这个文件,将字符串写回文件中,然后关闭。完成配
置。
如果编译一个版本出现ROM空间超出时,可以直接修改custom_MemoryDevice.h文件中的
定义进行调整,然后执行编译验证。
callmakeTELACOM53_10A_12832gprssysgen
callmakeTELACOM53_10A_12832gprsemiclean
callmakeTELACOM53_10A_12832gprsemigen
callmakeTELACOM53_10A_12832gprsc,ucustomdrv
注意:由于目前makefile中都设置了SYSGEN_ENABLE=TRUE,表示scatterfile每次new
编译时都会自动生成。在10A之前的版本,中不需要执行makesysgen命令scatter
file就会自动更新,但是10A版本则必须要执行makesysgen命令,否则scatterfile无法根
据custom_MemoryDevice.h中修改的配置进行更新。
ash
NANDFlash(MCP的类型)的ROM和RAM相比NORFlash都较大,一般情况不需要过
多的考虑ROM空间问题,但在某些情况RAM是需要重点注意的,当RAM空间紧张的时
候要可以通过优化代码和调整scatterfile来节省RAM。
以下是NANDFlash和RAM分配的简要说明(可能不完全准确):
内存配置在custom_MemoryDevice.h文件中:
NANDFlash(ROM)
Bootloader
Code
FS
UserSpace
FSOverhead
Usedby
applications
XXX_BOOTLOADER_
EXT_BOOTLOADER
ROM
SECONDARY_ROM
DEMAND_PAGING_ROM0
FS
TotalRWSize
(RW+ZI)
CodeLoading
Demand
PagePool
(800KB)
Static
Dynamic
LeftSpace
RAM
LeftSpace
FS
#defineNAND_BOOTING_NAND_FS_BASE_ADDRESS0x02800000
#defineNAND_BOOTING_NAND_FS_SIZE0x05800000
#defineNAND_BOOTING_NAND_FS_FIRST_DRIVE_SECTORS128000
含义与NORFlash相同,其中
NAND_BOOTING_NAND_FS_BASE_ADDRESS是配置code区域的大小;
NAND_BOOTING_NAND_FS_SIZE是配置文件系统区域的大小;
NAND_BOOTING_NAND_FS_FIRST_DRIVE_SECTORS是配置用户可见区域的大小,此配
置的单位是sector,1sector=512Bytes。
由于NANDFlash和NORFlash的工作方式不同,前者不能片上运行,必须要load到RAM
中才能运行,所以需要注意以下几点:
1.当手机上电后,ROM和SECONDARY_ROM会通过bootloader全部Load到RAM中后
才开始运行;
2.而DEMAND_PAGING_ROM0中的代码会动态加载到RAM中运行,即当系统运行过程
中需要执行到DEMANDPAGING中的代码时,会先将一部分代码load到pagepool中,
运行完后再重新载入其他的代码。
3.可见,ROM和SECONDARY_ROM这两部分代码既需要储存在ROM中,也需要同样
大小的RAM加载运行。所以,要节省RAM空间,需要尽可能的将这两部分代码的体
积减小,也就是说要适当增大DEMANDPAGINGCODE的大小。
4.RAM占用的计算方法(大体上):
TOTALRAM=TotalRWSize(RW+ZI)+ROM+SECONDARY_ROM+DemandPagePool
其中,TotalRWSize(RW+ZI)是应用程序占用的RAM空间,可以从lis文件中查看;
DemandPagePool是动态加载需要的RAM空间,MTK默认是800KB,一般情况下不需
要修改,定义在custom_config.c中:
#defineDEMP_PAGE_POOL_SIZE(800*1024)
5.对于NANDFlash,FS系统区(不可见区)需要留出足够的空间以避免再开机时出现文
件系统不足的“倒计时”提示。MTK针对此问题没有明确的说法,只是建议尽量多留
一些,根据我们之前的经验,FS系统区保留18MB~24MB比较合适,即LeftSpace在
10M以上。
2.1调整code区和FS区以及用户可见区的大小
调整code区和FS区的大小的方法与NORFlash相同,实现上也是通过脚
本完成,请参考前面的相关说明和脚本。
另外,为尽可能节省RAM,经常需要调整DEMANDPAGINGROMSIZE。实现上也定义了两组
宏分别用于项目配置和用户需求配置:
TL_MEMORY_CUSTOM_DEMAND_PAGING_ROM_SIZE_USER:用于客户需求配置()
TL_MEMORY_CUSTOM_DEMAND_PAGING_ROM_SIZE_PROJECT:用于项目配置()
修改DEMANDPAGINGROMSIZE需要修改scatterfile和custom_scatstruct.c文件,由于
目前基本都开启了SYSGEN_ENABLE=TRUE,修改这两个文件都要在相应的perl脚本中完
成:和。
custom_scatstruct.c:
#defineDEMP_PAGE_POOL_SIZE(__TL_MEMORY_CUSTOM_DEMAND_PAGING_ROM_SIZE__/1024/1024)
/*inMB*/
scatterfile:
DEMAND_PAGING_ROM00xf40000000x1800000
2.2如何尽可能将资源及代码放到DEMANDPAGINGROM
中?
通过配置scatterfile可以将一些数据及资源放到DEMAND_PAGING_ROM0中,如果开启了
SYSGEN_ENABLE=TRUE,需要修改文件。
将一些模块的资源和数据部分写到scatterfile中的DEMAND_PAGING_ROM0部分,生成
BIN文件时就会生成在DEMAND_PAGING_ROM0文件中。如下:
DEMAND_PAGING_ROM00xf40000000x2000000
{
DEMAND_PAGING_ROM00xf4000000
{
……
}
DEMAND_PAGING_ROM1+0x00
{
……
}
DEMAND_PAGING_ROM2+0x00
{
……
}
DEMAND_PAGING_ROM3+0x00
{
……
;__TL_TELACOM_MODIFICATION__begin
;audioresource
custpack_(+RO-DATA)
resource_(RES_AUDIO)
;Vectorfont
vf_*.obj(+RO-DATA)
;PresetJavaApplets
j2me_custom_(+RO-DATA)
;HanWangWrting
(+RO-DATA)
;Charsettable
(+RO-DATA)
;__TL_TELACOM_MODIFICATION__end
}
……
custpack_(+RO-DATA):表示将custpack_audio.c文件中的DATA部分放到DEMAND
PAGINGROM中。
custpack_(+RO-CODE):表示将custpack_audio.c文件中的code部分放到DEMAND
PAGINGROM中。
对于某些文件中嵌入了一些资源,但不能将DATA区域全部放到DEMANDPAGINGROM
中,否则会导致一些问题(resource_(RES_DATA)会引起死机问题)。将某些CODE放到
DEMANDPAGINGROM也可能会引起类似的问题。保险起见,一般情况下不要将CODE
部分放到DEMANDPAGINGROM中。
对于resource_audio.c这个文件中,如果都直接放到静态ROM中,会占用过多的RAM,而
又不能将data区域都放到DEMANDPAGINGROM中,否则当多路通话时会出现死机现象,
原因就是某些代码不能动态加载。针对此问题,需要将我们确认不会引起问题的数据单独加
载到DEMANDPAGINGROM中,如下:
#pragmaarmsectionrodata="RES_AUDIO"//RES_AUDIO是自定义的名称
//需要加载到DEMANDPAGINGROM中的纯数据
#pragmaarmsectionrodata
如:
#pragmaarmsectionrodata="RES_AUDIO"
__align(2)staticconstunsignedcharcs01_mid[]={
……
};
__align(2)staticconstunsignedcharcs02_mid[]={
……
};
……
#pragmaarmsectionrodata
文件分析
Code()RODataRWDataZIDataDebugLibraryName
……
======================================================================
TotalROSize(Code+ROData)13217788(12908.00kB)
TotalRWSize(RWData+ZIData)4712620(4602.17kB)
TotalROMSize(Code+ROData+RWData)13395272(13081.32kB)
======================================================================
3.1通过lis文件查看当前编译的RAM和ROM占用情况
TotalRWSize是当前占用的总的RAM大小;
TotalROMSize是当前占用的总的ROM大小;
从上表可见,RWData即占用RAM也占用ROM,所以在程序中尽量减少这部分数据。
比如尽量少用全局变量等,对于纯数据,一定要加const关键字。
3.2通过lis文件检查某一模块的占用情况。
3.3通过lis文件查询函数的具体地址,以便跟踪分析死机问题中的死机地址。
更多推荐
proconfig
发布评论