表现：
1、测试两张卡
2、客户现场使用，表现为系统无法启动，fpga正常启动！
3、两张卡，日志均表现一致如下：
排查：
1、根据日志显示为mmcblk0p11 挂载失败 且 Can't find ext4 filesystem，定位为system.img，利用工具导出img文件！
2、测试img文件报错如下：
从使用e2fsck的修复状态来看，system分区的super-block损坏了
3、交叉验证img文件是否损坏：
将导出的异常system.img 烧录到正常的板卡中，测试显示，报错一致：Can't find ext4 filesystem
4、针对system分区的super-block损坏，做进一步分析， 通过资料查询， Android系统的system分区挂载的ro只读的，也就是不可能被写成其他的数据，是不存在super-block损坏的，那么就考虑非正常的情况了！主要有以下几种：
① android system被root了，那么就可能变成rw被写坏了
②android recovery ota升级更新system分区掉电了，把system分区写坏了
③emmc本身的问题，掉码了，导致super-block的关键数据丢了
④android system运行中，冲内存了，覆盖了system分区的super-block数据。
逐步分析：
① 是否root： 根据资料显示，对比异常img 和正常img 如下， 文件保持一致，排除被root 写坏了
②修复img，利用工具：
打开文件：如下
查看生产日期，和查看文件系统中 升级 确认系统未进行升级操作！如下：
③ 分析多块坏板，发现都是system分区的super block无法挂载，且仅仅只有super block损坏，后面的data block都是正常，也就是损坏的block仅仅为super block，不具有随机性，则我们不能判断为emmc 本身的问题，掉码时随机性的。
④查阅资料，确定
利用工具查看异常img、修复后的img 还有 正常img Superblock！ 如下：
通过对比确认是 system分区的super block数据不正常了，被异常的数据覆盖了！ 接下来查具体为何会被覆盖，什么程序导致被覆盖的！
资料参考：
https://blog.csdn.net/csdn66_2016/article/details/88396911
