从JB(4.2)版本通过FOTA升级到KK(4.4)版本的注意事项
时间：10-02
整理：3721RD
点击：
[Description]
KK版本发布以来，几乎每个平台都有收到从JB版本通过FOTA升级到KK版本的需求。鉴于不同平台间会有些许差异，小编在此做了个小小的总括，以供参考。
[Background]
Fota升级必须遵循OTA升级的rules，rules的详情可以参考DCC上文档《android SDupgrade application note》。
[Case 1] TEE和PERSIST分区的问题
Partition table里多出来三个分区：TEE1/TEE2/PERSIST
这三个分区的作用：
ptgen.pl里，这三个分区是否有效，取决于相关的feature option：
TRUSTONIC_TEE_SUPPORT，mtk_PERSIST_PARTITION_SUPPORT。
我司release的默认版本中，//alps/mediatek/config/common/ProjectConfig.mk里这两个feature option没有打开，而//alps/mediatek/config/<project>/ProjectConfig.mk里没有定义。
因此，如贵司对这三个分区无客制化，FOTA升级不受影响。
[Case 2]CUSTOM分区的问题
72平台以后，Partition table里多出来CUSTOM分区，文件系统类型，用于客制化数据的存储。
这个分区是由MTK_CIP_SUPPORT控制的，默认不打开。
想要FOTA升级成功进行，必须保持前后版本MTK_CIP_SUPPORT一致。
[Case 3] MBR起始地址的问题
要想Fota升级成功，MBR的起始地址是绝对不能改变的。
但是，有时会因为memoryDeviceList.xls eMCP信息增删或是Flash兼容，导致前后版本的MBR起始地址发生改变。
82平台及老平台，容易发生此类问题，可以通过查看out目录下scatterfile MBR起始
PERSIST : for key installation
TEE1/ TEE2 : for Trustonic TEE image
Both of these partitions are only enabled when Trustonic TEE support feature option is enabled.
And Trustonic TEE is not allowed to updated fROM non-TEE load to TEE enabled load.
So it will not affect the customers who need to update from non-TEE load (JB) to non-TEE load (KK).
地址进行确认。
如发生此类问题，还请参考ptgen.pl的GetMBRStartAddress。
如需要，也可修改//alps/mediatek/config/<project>/mbr_addr.pl里的$MBR_Start_Address_KB。
[Case 4] BOOT/RECOVERY image的size超标问题
升级前，72/82等平台build出来的load里，其中BOOT/RECOVERY image是小于6M的。
为节约空间，大部分客户往往就把把BOOT/RECOVERY partition的size设为6M。
由于KK的kernel增大，导致KK的BOOT/RECOVERY image有可能大于6M。
当然，增大对应partition的size可以解决问题，但是同时会导致MOTA/FOTA失败。
Kernel的默认压缩方式是GZIP，而XZ的压缩方式会使得size更小，以比GZIP多一倍的压缩时间为代价。
鉴于此，我司建议修改kernel的压缩方式：
修改文件 ----
//ALPS_SW/TRUNK/KK/alps/mediatek/config/<project>/autoconfig/kconfig/proje
ct
从目前来看，修改kernel的压缩方式是最好的办法。
修改后的确认方式：
---- KK前的版本，build之后请查看//alps/kernel/out/.config
---- KK版本，build之后请查看
//alps/out/target/product/<project>/obj/KERNEL_OBJ/.config
[Case 5] EBR2问题
有些平台，可能会遇到新旧scatterfile的EBR2有无问题。
对于此类问题，还请先查看ProjectConfig.mk里MTK_SHARED_SDCARD是否一致。要想FOTA能够成功进行，MTK_SHARED_SDCARD必须一致。
[Case 6] NVRAM问题
相比于JB，KK会有NvRAM ItEMS的增减，比如
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_XZ=y
上图显示，KK上AP_CFG_CUSTOM_BEGIN_LID后面的LID enum值全部增加了1项。
对于Native层来说，可以直接通过NvRAM LID作为输入参数访问NvRAM，没有不良影响。
而对于APP层来说，因无法获取到NvRAM LID的enum值，我司之前建议计算出具体值，code里面需要harcode此LID。这个改动会直接导致APP层的客制化code访问到错误的
NvRAM Item。
因此，KK后请使用新增API（readFileByName()）进行APP层对NvRAM的读写。
KK版本发布以来，几乎每个平台都有收到从JB版本通过FOTA升级到KK版本的需求。鉴于不同平台间会有些许差异，小编在此做了个小小的总括，以供参考。
[Background]
Fota升级必须遵循OTA升级的rules，rules的详情可以参考DCC上文档《android SDupgrade application note》。
[Case 1] TEE和PERSIST分区的问题
Partition table里多出来三个分区：TEE1/TEE2/PERSIST
这三个分区的作用：
ptgen.pl里，这三个分区是否有效，取决于相关的feature option：
TRUSTONIC_TEE_SUPPORT，mtk_PERSIST_PARTITION_SUPPORT。
我司release的默认版本中，//alps/mediatek/config/common/ProjectConfig.mk里这两个feature option没有打开，而//alps/mediatek/config/<project>/ProjectConfig.mk里没有定义。
因此，如贵司对这三个分区无客制化，FOTA升级不受影响。
[Case 2]CUSTOM分区的问题
72平台以后，Partition table里多出来CUSTOM分区，文件系统类型，用于客制化数据的存储。
这个分区是由MTK_CIP_SUPPORT控制的，默认不打开。
想要FOTA升级成功进行，必须保持前后版本MTK_CIP_SUPPORT一致。
[Case 3] MBR起始地址的问题
要想Fota升级成功，MBR的起始地址是绝对不能改变的。
但是，有时会因为memoryDeviceList.xls eMCP信息增删或是Flash兼容，导致前后版本的MBR起始地址发生改变。
82平台及老平台，容易发生此类问题，可以通过查看out目录下scatterfile MBR起始
PERSIST : for key installation
TEE1/ TEE2 : for Trustonic TEE image
Both of these partitions are only enabled when Trustonic TEE support feature option is enabled.
And Trustonic TEE is not allowed to updated fROM non-TEE load to TEE enabled load.
So it will not affect the customers who need to update from non-TEE load (JB) to non-TEE load (KK).
地址进行确认。
如发生此类问题，还请参考ptgen.pl的GetMBRStartAddress。
如需要，也可修改//alps/mediatek/config/<project>/mbr_addr.pl里的$MBR_Start_Address_KB。
[Case 4] BOOT/RECOVERY image的size超标问题
升级前，72/82等平台build出来的load里，其中BOOT/RECOVERY image是小于6M的。
为节约空间，大部分客户往往就把把BOOT/RECOVERY partition的size设为6M。
由于KK的kernel增大，导致KK的BOOT/RECOVERY image有可能大于6M。
当然，增大对应partition的size可以解决问题，但是同时会导致MOTA/FOTA失败。
Kernel的默认压缩方式是GZIP，而XZ的压缩方式会使得size更小，以比GZIP多一倍的压缩时间为代价。
鉴于此，我司建议修改kernel的压缩方式：
修改文件 ----
//ALPS_SW/TRUNK/KK/alps/mediatek/config/<project>/autoconfig/kconfig/proje
ct
从目前来看，修改kernel的压缩方式是最好的办法。
修改后的确认方式：
---- KK前的版本，build之后请查看//alps/kernel/out/.config
---- KK版本，build之后请查看
//alps/out/target/product/<project>/obj/KERNEL_OBJ/.config
[Case 5] EBR2问题
有些平台，可能会遇到新旧scatterfile的EBR2有无问题。
对于此类问题，还请先查看ProjectConfig.mk里MTK_SHARED_SDCARD是否一致。要想FOTA能够成功进行，MTK_SHARED_SDCARD必须一致。
[Case 6] NVRAM问题
相比于JB，KK会有NvRAM ItEMS的增减，比如
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_XZ=y
上图显示，KK上AP_CFG_CUSTOM_BEGIN_LID后面的LID enum值全部增加了1项。
对于Native层来说，可以直接通过NvRAM LID作为输入参数访问NvRAM，没有不良影响。
而对于APP层来说，因无法获取到NvRAM LID的enum值，我司之前建议计算出具体值，code里面需要harcode此LID。这个改动会直接导致APP层的客制化code访问到错误的
NvRAM Item。
因此，KK后请使用新增API（readFileByName()）进行APP层对NvRAM的读写。
:lol