备注：此文虽是基于LSDK而编写，但对OpenWrt也具有重要的参考价值，特别是Uboot和模块加速的优化。
1 背景
在整完一段物联网的项目后，基于此项目中的时间曲线要求，再回头来检查以前WiFi网桥类产品的启动速度，觉得非常不可接受，恰好有朋友要推一款成本更低廉的网桥设备，于是动手对原网桥固件进行了再次优化。
老固件从上电到网络就绪，大概要32秒（可靠率99%）；极端情况下，当CPE端进入“假死”态时，可能需要50秒才能网络就绪。按物联网设备开机即可用的要求，这个时间真的是太漫长了，连金星上的手机都快侦听到此WiFi信号了。
2 具体过程
首先，在网上找了一圈，发现车载/车联网领域的工程师们已经对Linux启动加速进行了多种尝试，有个builtroot项目的启动速率，不超过1秒，这简直是神了。但我不会弄builtroot，将QCA
LSDK工程移植到buildroot上，代价太贵，不敢动。
其次，参照前人的经验，也是从uboot开始，LSDK的uboot功能较单一，绝对速度也算快，只是没有做任何优化，所以相对速率较慢；特别是以前的设计要求中，在基于可靠性要求下，强制网桥要求支持双固件备份，从而极端情况下要计算并检测2次CRC，每次至少需要1秒；加上bootdelay的1秒，以及一些打屏损耗，整体无效耗时较长，需要特别优化。本优化中将uboot中的abort函数直接关闭，不接受字符输入方式进入uboot控制台，仅保留按键方式进入UIP模式。因为进入UIP模式后，可通过按ctrl+C后进入uboot控制台。经过如此优化后，上电到“Starting
kernel”的时间耗费，由近6秒缩到2.202秒。效果非常明显。
再其次是优化内核，将不必要的打印全部关闭，从“Booting Atheros AR934x”到“init started”的时间，缩短到0.900秒。不敢优化lpj，因为该校准耗时为100毫米级，优化价值不高，且怕最终量产后出问题。
其实网桥真正耗时的操作，是无线和有线驱动加载以及配置实例生效。基于以前稳妥的“慢慢来”策略，rcS中先加载有线驱动并拉起有线口配置实例；再加载无线驱动并生效无线配置实例。这个过程都是串行的，需要近20秒，等无线可用时，又耗费6秒多。因此，本次优化的核心工作就是调整驱动加载和配置生效次序(驱动代码中的init链所涉及到的sleep，也适度缩小)，在不引入新问题的原则下，首先调整rcS的驱动加载与指令执行顺序，将无线驱动相关的ko文件分散加载，且将耗时较长的加载改为后台加载，这样前台可立即执行其他不彼此依赖的指令。经过这样修改，成功加载完有线/无线驱动后，所耗时间缩短为3.51秒。
重构有线/无线的配置生效，因为配置生效最终的结果都是产生一系列的配置指令，直接将这些配置指令保存到一个文件中，在驱动加载完毕后，检查生效文件是否存在，如果存在，则直接执行该生效文件；否则才执行原来的配置生效指令集。这样一来，配置下发所耗时间缩短到1.316秒；配置生效所耗时间缩短为1.418秒。
3 优化结果
在AP端设置为固定信道后，从上电到该设备就绪所耗时间缩短至9.499秒，CPE端的启动时间缩短至11.73秒。AP设备不动，CPE侧的主机从CPE上电到ping通AP侧的主机所耗时间约为13秒；CPE设备不动，AP侧的主机从AP设备上电到ping通CPE侧的主机所耗时间约为16秒。
同样地，将AP配置为自动信道后，AP设备不动时，CPE侧的主机从CPE上电到ping通AP侧主机所耗时间约为16秒；而保持CPE设备不动，AP侧的主机从AP设备上电到ping通CPE侧主机所耗时间约为18秒。
但是，无论是固定信道还是自动信道场景，测试中均出现过ping通对方主机时间为35秒的情况，主要表现为AP设备已转为正常工作态，手机上也发现了该AP的广播SSID，但CPE设备仍在不断扫描中，看了CPE侧的内部实现还需要继续优化。
从优化结果上看，已初步符合特殊场景下启动到网络就绪时间不超过20s的硬性要求。
本轮优化改进的测试环境：2台陪测主机均为固定IP；在断电重启过程中，主测试的PC机上执行过arp -d；QCA9342+8032 WiFi 网桥；QCA LSDK 9.2，2.6.31 内核；无线未加密。
