Nor Flash 代码压缩

1.   代码压缩需求

目前，feature phone普遍采用nor flash存放image。Nor flash多采用16MB大小，如果超出，市场上很难采购到合适大小的nor flash，即使有，成本也很难令人接受。所以，在nor flash固定的情况下，只有想办法压缩image大小。

上述情况，就是feature phone采用压缩文件存放在nor flash的原因。当然，没有完美的方案，代码压缩同样需要付出代价:

1.     额外的RAM空间，用来存放解压缩后的code；

2.     增加MMU模块，用来管理地址空间，并且在预取指令异常或者数据缺失异常发生的情况下，解压缩相应page的code到空闲ram空间中去，并且刷新页表；

3.     增加硬件解压缩模块，用来减少解压代码需要的时间；

4.     压缩code执行需要更多的时间。

1.   代码压缩实现方案

代码压缩首先需要考虑对哪部分代码进行压缩。RTOS对代码执行效率要求较高，并且mmu的配置和中断处理都处于此image中，所以不能进行压缩。一般主要是对安装的应用程序进行压缩，对存放的各种图片等资源进行压缩。

注意：一旦压缩，就只能采取只读方式，无法修改image文件了。

 

压缩实现方案：

1.     编译时候，对生成的image文件进行压缩处理。主要是需要提供一个压缩命令，对文件压缩处理。压缩命令应该能按照指定的page大小(1K,4K)进行压缩，并且在压缩后的文件头部存放每个page压缩后的位置和大小，供解压缩使用。Page大小需要综合考虑压缩效率和解压缩时间来衡量。压缩算法比较灵活，由硬件的解压缩的实现方案决定；

 

2.     MMU初始化，此时需要考虑：mmu页表(pgd和pte)内存空间，解压缩后code存放空间位置和大小，各个虚拟地址空间的各种属性，比如访问权限等。Mmu初始化pgd表项，根据虚拟地址空间属性，申请pte表项，并且完成初始化。最后，读取nor flash压缩文件，获取压缩文件相关信息，比如说page压缩后位置和大小等；

3.     当发生指令预取异常的时候，或者数据异常的时候，获取解压缩code空间的尾部，然后无效其虚拟地址的pgd和tlb，然后根据发生异常的虚拟地址空间，在存储page压缩后位置和大小的空间中获取对应虚拟地址对应的nor flash 的offset和size，使用解压缩硬件，把此page解压缩到解压缩地址空间对应的尾部的物理地址上，然后生成新的pgd表项，刷新tlb。