boot/kernel/app快速启动策略

         最近整理海思3559AV100开发资料，发现官方带的开发包里有专门描述系统快速启动的相关内容，感觉相当不错。3559多核系统分别使用linux和liteOS，启动是以uboot引导的。尽管一般的嵌入式系统可能只有linux或者其它操作系统，但是总体而言都是boot引导部分+操作系统+应用。所以海思这一套很具有通用代表性，因此记录在此。

一  3559是以DV开发模型为例说明的，快速启动的目标是：

A    开机后快速启动app
B  开机后快速获取第一帧视频

这样看的话，其实主要目标就是系统启动要快，另外应用也要块。可见目标是与其它嵌入式项目中的目标是相同的。

海思DV快速启动的方案如下：

分析：uboot和linux部署在4核(双A53+双A73)上，Liteos部署在单核A53上。单核A53主要处理应用中的直接影响用户体验的视频部分，这部分需要快速启动。而其它的不那么直接影响用户体验的放到4核上或者等待系统启动以后运行。首先uboot和kernel，rootfs都是精简版本，减少启动读取时间。另外uboot启动过程中先加载liteos镜像给单核A53,这样，4核上继续往后执行的时候，单核A53也可以并行执行，结果就是可能4核上系统还没有启动完，单核A53上的应用可能已经运行起来了。用户又不管你什么boot，什么kernel，看得见的才是硬道理。从海思DV的例子不难看出，其实就是除了精简镜像以外，就是把和用户体验直接相关的任务分解给简单的，执行速度快的硬件，进而让用户在第一时间就能感受飞一般的感觉。那平时我们的项目中也可以采取同样的策略，当然需要添加硬件成本.这两天无意中看到nxp的 RT1170 mcu， m7+m4双核，1Ghz，这mcu挺猛啊，如果你的项目中用到这款mcu，那你就可以把业务分开了，比如m7上跑系统，m4上运行和用户直接交互的部分，这样就可以采用上面提到的快速启动方案了。

二 通用优化策略

硬件优化一般对软件功能影响不大，但是软件优化可能对功能有一些影响。快速启动一般会对boot、kernel和rootfs进行软件模块裁剪，不可避免地对开发过程有一些影响。因此推荐的方法是平时的开发和调试采用正常版本，当软件版本可以定型或发布前再切换到快速启动版本。

2.1 硬件

2.1.1 硬件复位方式：可以片内复位，也可以片外复位。片外复位选st、ti等大厂的快速复位芯片，一般会比片内复位块。

2.1.2 flash选型

Flash你可以认为就是我们电脑的硬盘，你的boot、操作系统和应用程序都在flash上存储。嵌入式设备从上电到最后应用启动，就和你按电脑开机键，等待系统启动，进入桌面，打开word是一样的。你如果经历过机械硬盘到SSD固态硬盘的更换过程，就了解这个过程所用时间的对比有多大。所以很多人一旦用过SSD，就在也不会用机械硬盘了。一些玩游戏的人员可能有过这样的经历：pc里安装一块ssd，一块机械，ssd上除了装系统外，另外把经常玩的游戏也存放在ssd上，这也算是系统快速和应用快速启动的一种方案。Flash选型就是你选7200rpm硬盘还是5400rpm硬盘还是ssd这么一回事。海思针对flash选型的测试结果如下图，我们可以直接适配自己的硬件：

2.1.3 DDR选型

这里就是屏率越高的ddr速度越快，这没啥好说的。3559使用ddr4,ddr可不是一上电就能用的，ddr4上电以后做了下面一堆工作以后才能用：

都是和阻抗匹配，时序匹配相关的一些初始化。有意的同学移位这里阅读：

海思描述说他们针对ddr4 training做了优化，training大概20ms。

2.1.4 关闭bootrom功能

Flash中已经烧录uboot，系统更新一类的都可以使用uboot，关掉bootrom，减少bootrom启动时件。海思描述说能减少50ms。

2.2 软件

2.2.1 uboot优化

uboot 启动时间主要受 uboot 镜像大小、驱动初始化时间、所加载的镜像的大小、镜像加载速率等因素影响,快速启动版本的 mini-uboot 主要针对以上几点进行优化。优化后的 mini-uboot 没有命令行、串口升级等调试功能,只具备快速启动功能,为了弥补这一缺点,我们采用 mini-uboot + normal uboot 的启动方案,即在有升级、命令行操作等需求时,通过按键或其它触发机制,从 mini-uboot 跳转到normal uboot 中执行。

这种方式不错啊，很多地方我们可以借鉴使用，即板子上有2个uboot，一个是快速版本，一个是正常版本。平时正常使用的时候用的是快速版本，当有升级或者其它命令行操作要求时通过外部触发机制进入正常版本uboot。唯一就是稍微用点flash空间。

2.2.1.1 uboot镜像大小裁剪

A 去掉命令行相关代码

B 去掉环境变量相关代码

C 去掉未用到的驱动代码(mmc、usb、网络等)

D 去掉不用的其它flash驱动代码

2.2.1.2 驱动初始化时间优化

2.2.1.1中的C和D，去掉驱动代码，驱动不用加载，也不用初始化。

2.2.1.3 加载镜像裁剪

这里的镜像是指kernel镜像以及其它uboot需要加载的镜像。把镜像做特定压缩，尽量小，解压尽量使用硬件解压，减少加载和解压时间。

2.2.2 kernel优化

原则：对kernel进行裁剪，尽量基于kernel标准的配置文件进行，尽量不要改动代码本身。Kernel的启动时间主要受内核大小，内核解压速度，默认加载驱动模块多少与速度等方面影响。

    2.2.2.1 bootargs优化，主要是通过bootargs修改内核启动流程，并且禁止即时打印。

    
    2.2.2.2 电源管理优化，裁剪部分电源管理通过修改config，当然如果你的设备电源管理是必须的，那就不行了。

    2.2.2.3 去掉ipv6支持，修改config，去掉ipv6代码，减小内核大小。

    2.2.2.4 把usb默认编译成KO文件，通过修改config文件把usb各个驱动模块编译成ko文件来延迟初始化(如在UI显示完成以后加载)可缩短kernel启动时件。

    2.2.2.5 只保留必要的文件系统，修改config裁剪掉其它不用的文件系统，这可有效减小kernel大小，缩短加载时间。但是可能会影响后期文件系统兼容性。

    2.2.2.6 MMC模块编译成KO，mmc模块初始化需要一定时间，通过把mmc编译成ko文件，可缩短kernel启动时间。

    2.2.2.7 其它一些优化选项，关闭swap，GPIO，input device

 

2.2.3 rootfs优化

主要是通过裁剪rootfs镜像本身，优化busybox启动策略，选择快速文件系统三个方向进行。

    2.2.3.1 保留必要的busybox命令，没有或者预计不用的统统去掉。

    2.2.3.2 文件系统选型

不同flash支持文件系统不同，读写性能差异较大。根据文件系统本身属性和实际项目需求进行选择，下面是海思列出的常用文件系统特性：

SPI nor Flash上的文件系统

A 研发调试期间，可以选用jffs2或ubifs;

B 快速启动版本推荐squashfs，只读，性能不如ubifs，可以在系统启动以后挂载一个jffs2文件系统;

C ubifs性能最好，只是业界没有大规模使用，可能有一定的大坑在等你;

D jffs2不推荐快速版本使用，很慢;

Spi nand flash/Parallel nand flash上的文件系统

A 不管快速启动版本还是调试期间版本都优选ubifs;

B jffs2很慢

量产产品，推荐文件系统做成只读，确保系统启动正常。

 

2.3 APP启动优化

2.4.1 去掉调试打印;

2.4.2 把业务分开，先启动UI相关的，如果有多核硬件更好;

2.4.3 系统参数读写采用直接读写flash，不使用文件系统读写方式;

好了，就这么多。