背景：
平台：stm32mp151平台
什么是OTA？
说起OTA我们应该都不陌生，它是一种可以为设备无损失升级系统的方式，能将新功能远程部署到产品上。
我们不仅可以通过网络下载OTA升级包，也可以通过下载OTA升级包到SD卡或U盘后再对设备升级。
OTA下载方式：
- 短信方式
- PUSH方式
- 网络定制
本例网络定制方式。
现象描述
本产品通过OTA升级测试，升级162次，死机重启19次，如下图所示：
死机重启分析：
1. 为何oom会导致重启？
当需要申请物理页面时，首先使用快通道申请页面，当快通道申请不到将会进入慢通道，当慢通道也无法申请是将触发oom-killer,正常情况下会杀死消耗物理页面最多的进程，而设备直接进入PANIC然后重启。
当申请物理页面时free页面很多情况也会存在页面申请失败的现象，一方面可能内存外碎片化严重，另一方面可能是无法借用其他迁移类型内存。因此尽量不要使能panic_on_oom，但设备使能该参数，如下图所示：
若去掉使能选项，oom-killer将会杀掉物理页最大进程，因此应该杀死蓝牙进程，在升级过程中，杀掉蓝牙进程对业务无任何影响。下图为不开启参数而杀掉最大物理页进程：
2. 为何free页面很多但是还是会进入oom？
当前我们已经知道因/proc/sys/vm/panic_on_oom=1 导致进入oom后便会panic然后重启，但为何内存不足呢？
我们的日志提示还有126M物理页处于空闲可用，不应该会进入内存申请失败的情况。
细看可知gfp_mask=0x101cc0，则MIGRATE_MOVABLE未置1，导致ALLOC_CMA未置1，既不允许使用cma_pages,
当CMA页面不允许使用时，实际所剩余可申请的页面数：free减去free_cma,free_cma提示120多M（高达实际物理内存一半）,所以剩余非迁移属性的页面只剩几M:
解决措施：
因此除了关闭panic_on_oom，还应该去查查为何free_cma为何可以分配的那么多,而不做最大值限制，通过启动日志可看出系统CMA的最大限制为128M，如下图所示：
CMA我们分配竟然达到了50%物理内存，因此将CMA降成64M大小，以释放64M用于非迁移属性页面申请。通过uboot传参cma=64M,可将cma最大值设置为64M。
