高通分区总结

Posted 2020-09-01 请给我倒杯茶

本文转载自：http://blog.csdn.net/jerome198707/article/details/41512419

高通分区模块总结

1.MBR和GPT

目前分区模式，主要有两种：Bios+硬盘MBR分区和EFI和硬盘GPT分区。

BIOS+硬盘MBR分区是沿用了数十年的引导模式，MBR分区的标准决定了MBR只支持在2TB以下的硬盘，超过2TB的硬盘只能管理2TB。为解决这个大问题，微软和英特尔在EFI方案中开发了GPT分区模式。随着不久的将来硬盘容量突破2TB，BIOS＋MBR组合估计会被主板EFI和硬盘GPT分区的组合模式取代了。
GPT，全球唯一标识分区表(GUIDPartition Table)，GUID，全球唯一标识符(Globally Unique Identifier)。GPT是EFI方案的一部分，但并不依赖于EFI主板，在BIOS主板的PC中也可使用GPT分区。与MBR最大4个分区表项的限制相比，GPT对分区数量没有限制，但Windows最大仅支持128个GPT分区。GPT可管理硬盘大小达到了18EB(1EB=1024PB=1,048,576TB)，不过NTFS格式最大仅支持256TB。

1.1MBR说明

主引导记录（MasterBootRecord，缩写：MBR），又叫做主引导扇区，是计算机开机后访问的首个扇区，它在硬盘上的三维地址为（柱面，磁头，扇区）＝（0，0，1）。MBR的大小为512字节，包括引导程序、主分区表和引导记录，主分区表为64个字节，每个分区表的描述信息为16个字节，里面最多只能放4个分区表信息，这也是用MBR引导只能支持四个分区的原因。MBR结构见表1.

 

1.2GPT说明

GPT（GUIDPartition Table）属于EFI 方案中的一部分。GPT为了兼容MBR，LBA0 依旧保留了MBR的结构。在GPT工作时，会优先读取GPT (LBA1) 内容。如果没有GPT 内容，则认为这是一块MBR磁盘。再从LBA0 读取MBR。在硬盘末尾，GPT备份了一份，这样当GPT出错时，可以快速的从硬盘末尾恢复。LBA-1 (负1)表示倒数第一块LBA。

从LBA2 到LBA 33 ，一共预留了128 个分区表空间。GPT 支持在一块硬盘上创建128 个分区。GPT分区表的结构如图1所示

图1GPT分区表结构图

 

1.2.1LBA 0 protecttive MBR

在GPT分区表的最开头，处于兼容性考虑仍然存储了一份传统的MBR，用来防止不支持GPT的硬盘管理工具错误识别并破坏硬盘中的数据，这个MBR也叫做保护MBR。在支持从GPT启动的操作系统中，这里也用于存储第一阶段的启动代码。在这个MBR中，只有一个标识为0xEE的分区，以此来表示这块硬盘使用GPT分区表。不能识别GPT硬盘的操作系统通常会识别出一个未知类型的分区，并且拒绝对硬盘进行操作，除非用户特别要求删除这个分区。这就避免了意外删除分区的危险。另外，能够识别GPT分区表的操作系统会检查保护MBR中的分区表，如果分区类型不是0xEE或者MBR分区表中有多个项，也会拒绝对硬盘进行操作。

1.2.2LBA 1 GPT Heard

分区表头定义了硬盘的可用空间以及组成分区表的项的大小和数量。最多可以创建128个分区，即分区表中保留了128个项，其中每个都是128字节。（EFI标准要求分区表最小要有16,384字节，即128个分区项的大小）

分区表头还记录了这块硬盘的GUID，记录了分区表头本身的位置和大小（位置总是在LBA1）以及备份分区表头和分区表的位置和大小（在硬盘的最后）。它还储存着它本身和分区表的CRC32校验。固件、引导程序和操作系统在启动时可以根据这个校验值来判断分区表是否出错，如果出错了，可以使用软件从硬盘最后的备份GPT中恢复整个分区表，如果备份GPT也校验错误，硬盘将不可使用。所以GPT硬盘的分区表不可以直接使用16进制编辑器修改。

LBA 1 有512bytes大小的空间，里面放的就是GPTHeard，基本结构，见表2

表2GPT头的基本结构

1.2.3LAB2~LAB33 GPT分区表项

GPT分区表主要描述分区的类型起始地址和结束地址，属性和分区名见表3

表3GPT分区表项的格式

2.分区配置文件partition.xml

partition.xml是分区配置文件，用于指定具体有分区名称、分区大小和类型，用于生成GPT分区表。

2.1参数说明

WRITE_PROTECT_BOUNDARY_IN_KB：

写保护区域的基准大小，一般标准的设置为64M

GROW_LAST_PARTITION_TO_FILL_DISK：

如果为真，最后一个分区的大小会自动调整为emmc剩余所有空间大小，充分利用空间。如果为假，最后一个分区将按你设定的大小去分配分区大小。

partitionlabel ： 分区名字

size_in_kb： 分区大小

type： 分区类型

bootable： 是否可以引导

readonly： 是否为只读

filename： 分区对应的镜像名字

sparse： 烧录的镜像是否是展开的

system分区的partition.xml文件配置，如下图2所示

 

图2system 分区配置信息

 

该文件是system分区的配置文件,主要作用包括：

WRITE_PROTECT_BOUNDARY_IN_KB =65536 写保护区域的基准大小为64M，保证同一读写属性的分区64M对齐

GROW_LAST_PARTITION_TO_FILL_DISK=true 最后一个分区的大小会自动扩充到最大

<partitionlabel="system" 指定分区的名字为system

size_in_kb="819200" 指定分区大小为800M

type="EBD0A0A2-B9E5-4433-87C0-68B6B72699C7"分区类型为数据分区

bootable="false" 设置该分区为不可引导分区

readonly="true" 读写属性为只读

filename="system.img" 分区对应的镜像名字

sparse="true" 烧录镜像是展开的镜像文件

2.分区镜像配置文件Boardconfig.mk

device/qcom/msmxx/Boardconfig.mk作用：

1.指定对应分区镜像文件格式化的大小

2.分区镜像文件的文件系统类型

如图3可知system被配置为400M,文件系统类型为ext4格式。

注：该值必须小于或等于partition.xml配置的大小partition.xml配置才是真正意义上的物理分区大小，越界将会导致分区加载失败。

图3 Boardconfig.mk配置文件

当编译的时候makefile就会从Boardconfig.mk获取system分区的大小和文件系统类型并用调用make_ext4fs 把out/target/product/msm8610/system的文件制作成大小为400Mext4格式的system.img分区压缩文件，如下图4所示

图4 system.img 制作命令

注：编译生成的system.img里面包含了对应分区的文件系统类型，以及挂载分区的大小，所以改变分区时一定要更新对应分区镜像文件。

 

3.高通项目分区整改实例分析

高通平台的分区有25个基本分区，所用的引导方式是gpt引导方式，所有文件都是存放在MMC上，系统运行过程中，就会通过各分区名字从MMC的指定分区读取相关的数据，高通提供的分区是一种通用的配置方式，由于要保证通用性的可行性，会造成空间资源的浪费，比如system镜像问件的实际大小为300M目前分配的大小为800M,明显浪费很大的存储空间，所以需要对分区做进一步调整。

3.1实例一 增加vendor分区

本项目的分区整改要求如下所示，system.img分区由800M减小到400M,用于增加一个300M的vendor分区，见表4。

 

表4高通分区整改要求对比

更改分区文件

3.1.1修改partition.xml文件里面修改包括分区大小、类型和要烧写镜像的名字等等信息见图5.

图5 vendor分区配置图

3.1.2.device/qcom/msmxx/Boardconfig.mk里面的分区宏,使这个分区恰好小于等于modem侧的partition.xml分区大小,见图6.

图6system BoardConfig.mk

3.2实例二 增大userdata分区

整改要求：去除由于对齐造成的空间浪费，减小system分区大小为400M尽可能的为用户增大userdata分区。

更改分区文件

3.2.1修改partition.xml文件里面做如下修改，见图7。

1.WRITE_PROTECT_BOUNDARY_IN_KB =0

2.system分区的大小为400M

3.userdata的分区为3000M

图7 partition.xml分区配置图

3.2.2.device/qcom/msmxx/Boardconfig.mk修改分区镜像文件格式化的大小，见图8。

1.把system分区镜像文件格式化的大小400M

2.userdata分区镜像文件格式化的大小3000M

图8Boardconfig.mk分区配置图

图9 userdata 增大后UI界面显示效果图

3.3编译AP测代码

重新编译AP测代码，更新AP侧system和userdata的镜像文件，生成新的system.img和userdata.img。

 

 

3.4拷贝

在modem\Linux\Android\下创建路径out\target\product\

把生成的\out\target\product\msm8610文件全部拷贝到modem侧代码modem\LINUX\android\out\target\product\路径下见图10。

图10路径图

3.5编译modem侧代码

执行命令pythonupdate_common_info.py重新编译modem

3.6烧写

3.6.1把\common\build\bin\asic下的pil_split_binsh、sparse_images和NON-HLOS文件拷贝到烧写的文件根目录下，见图11。

图11路径图

3.6.2common\build下的gpt_main0、gpt_backup0、patch0.xml拷贝到烧写的文件根目录下

最后用emmcsoftware download 下载到机器里面，见图12。

图12路径图

 

4.减少分区空间浪费措施

1.计算每个镜像的分区大小，留有足够预留空间合理分配每个分区大小

2.在进行分区布局的时候，尽量让读写属性一致的放在一起，这样就可以减少由于对齐造成的空间浪费。

3.通过设置WRITE_PROTECT_BOUNDARY_IN_KB来改变写保护区域的基准大小。

4.GROW_LAST_PARTITION_TO_FILL_DISK：最好设置为真，这样最后一个分区就会扩展到最大这样保证不浪费emmc存储空间。

5.注意事项

1.emmcsoftware download 所依赖的分区信息和系统启动时加载的gpt分区信息必须一致。

（1）emmc software download烧写各类镜像文件所依赖的分区信息是从rawprogram_unsparse获得的该烧写软件就是通过该文件获取各分区的起始地址和分区大小，并把各镜像文件烧录到指定位置。

（2）系统运行时bootloader会从mmc的512字节（前面512字节是MBR）地址处读取文件gpt_main0和gpt_backup0来获取各分区的起始地址和大小，并去指定位置镜像文件.

因此rawprogram_unsparse文件必须是编译gpt_main0和gpt_backup0生成的最新文件，地址必须匹配，否则系统运行后将找不到相应镜像文件，而无法运行。

rawprogram_unsparse文件是编译gpt_main0和gpt_backup0生成的，路径在\common\build\bin\asic\sparse_images下

2.分区时防止越界

在改变分区大小时，要防止自己的分区大小总和不能超过emmc的总大小，否则越界的分区时将会出错。系统稳定性将得不到保证。