android bootlloader interface每次都需要更新

RK3328 Android 7.1 增加custom分区，当system分区比较大的时候，烧录update.img之后不开机

问题现象：
增加了custom分区，刚开始都正常，随着system打包的东西越来越多，出现了，当增加一个apk进system之后，编译出来的update.img烧录，机器无法开机，log打印为system分区损坏了！将system打包的东西去掉一点，或者将system分区增大，重新编译烧录，又可以开机了！

RK烧录用的system是raw格式的ext4文件系统img，打包脚本在源码根目录下，文件：mkimage.sh，如下代码：

if [ -d $OUT/system ]
then
	echo -n "create system.img... "
	if [ "$FSTYPE" = "cramfs" ]
	then
		chmod -R 777 $OUT/system
		$FAKEROOT mkfs.cramfs $OUT/system $IMAGE_PATH/system.img
	elif [ "$FSTYPE" = "squashfs" ]
	then
		chmod -R 777 $OUT/system
		mksquashfs $OUT/system $IMAGE_PATH/system.img -all-root >/dev/null
	elif [ "$FSTYPE" = "ext3" ] || [ "$FSTYPE" = "ext4" ]
	then
		if [ "$PRODUCT_SYSTEM_VERITY" = "true" ]; 
		then
		    if [ $TARGET == $BOOT_OTA ]
		    then
			mv unsparse_system-*.img $IMAGE_PATH/system.img
		    else
			python ./build/tools/releasetools/build_image.py \
			    $OUT/system $OUT/obj/PACKAGING/systemimage_intermediates/system_image_info.txt \
			    $OUT/system.img $OUT/system
			echo -n "translate verified sparse image to raw image... "
			simg2img $OUT/system.img $IMAGE_PATH/system.img
		    fi
		else
			#system_size=`ls -l $OUT/system.img | awk '{print $5;}'`
			system_size=$BOARD_SYSTEMIMAGE_PARTITION_SIZE
			[ $system_size -gt "0" ] || { echo "Please make first!!!" && exit 1; }
			MAKE_EXT4FS_ARGS=" -L system -S $OUT/root/file_contexts -a system $IMAGE_PATH/system.img $OUT/system"
			ok=0
			while [ "$ok" = "0" ]; do
			    make_ext4fs -l $system_size $MAKE_EXT4FS_ARGS >/dev/null 2>&1 &&
			    tune2fs -c -1 -i 0 $IMAGE_PATH/system.img >/dev/null 2>&1 &&
			    ok=1 || system_size=$(($system_size + 5242880))
			done
			e2fsck -fyD $IMAGE_PATH/system.img >/dev/null 2>&1 || true
		fi
	else
		mkdir -p $IMAGE_PATH/2k $IMAGE_PATH/4k
		mkyaffs2image -c 2032 -s 16 -f $OUT/system $IMAGE_PATH/2k/system.img
		mkyaffs2image -c 4080 -s 16 -f $OUT/system $IMAGE_PATH/4k/system.img
	fi
	echo "done."
fi

可以看到，当文件系统格式为“ext3”或“ext4”的时候，有3种打包system.img的方式！

一开始一直以为是system分区的问题，但其实编译的时候，并没有分区超出设定值的报错，所以就在不编译的情况下，手动打包system.img，如下命令：

export PATH=/home/123/Android/out/host/linux-x86/bin:$PATH
make_ext4fs -l 2147483648 -L system -S ./root/file_contexts.bin -a system ./system.img ./system

先引入环境变量，然后再打包raw格式的system.img，大小为2G，或者将Android编译生成的sparse格式system.img，直接转换成raw格式：

simg2img system.img system_raw.img

如何判断生成的.img是不是raw格式，可以用file命令：file system.img
system.img: Linux rev 1.0 ext4 filesystem data, UUID=da594c53-9beb-f85c-85c5-cedf76546f7a, volume name “system” (extents) (large files)

然后使用手动打包的system.img再生成update.img，参考源码目录文件：
device/rockchip/common/build_base.sh 如下部分：

mkdir -p $PACK_TOOL_DIR/rockdev/Image/
cp -f $IMAGE_PATH/* $PACK_TOOL_DIR/rockdev/Image/

echo "Make update.img"
cd $PACK_TOOL_DIR/rockdev && ./mkupdate.sh
if [ $? -eq 0 ]; then
    echo "Make update image ok!"
else
    echo "Make update image failed!"
    exit 1
fi
cd -

mv $PACK_TOOL_DIR/rockdev/update.img $IMAGE_PATH/
rm $PACK_TOOL_DIR/rockdev/Image -rf

发现，再怎么搞system.img，问题依然存在，但是单独烧录system.img或者使用OTA整包升级，问题又没有了！

所以，怀疑和烧录工具有关系，使用RK的原生系统验证，原生系统没有增加custom分区。测试结果，就算system分区占满了，使用率100%，也依然正常开机，所以，又感觉不像是工具的问题！

这时候，发现，custom分区使用的是sparse格式的img，刚好这个分区和system相邻，但其实，system分区占用率比较小的时候，sparse格式的custom.img也是正常烧录和挂载的，并且RK回复是支持sparse格式的img烧录的！
先不管怎么说，使用raw格式的custom试一下，直接将Android编译出来的sparse格式的custom.img，使用simg2img命令转换成raw格式，打包update.img，烧录之后，之前无法开机的系统可以开机了！
另外，打包sparse格式的custom.img之后，SD升级完无法挂载custom分区，使用了raw格式之后，SD升级完也正常了！

结论：
RK的打包update.img的工具，或者是烧录的工具，对sparse格式的img支持不够好，所以，增加分区之后，需要将sparse格式转换成raw格式，在打包update.img升级！