2014年11月28日 星期五 阴转小雨

最近三天都在加班，都是迫不得已的，我也没想到我要加班。

周三是离下班还有两分钟，被S拉住了，跟我大谈特谈NFC，搞了一个小时，看了一会代码，我才和他沟通交流得比较透彻了。得出一个结论：凡是和不是软件的人打交道说软件如何实现，必须先问他的需求是什么，他想让别人做啥，最好画出来。

周四是合入Patch，MTK攒了半个月给我Modem Patch，一下来了7个。我没有用svn merge的方式去合，我是用beyond compare去合的。我动作很快，合入所有Patch之后，结果真的有一个合漏了，第一次是被人编译不过去（编译缺文件），第二次被人发现database没更新（有人误打误撞发现）。后来我花了一小时又核对了一下代码，又花了两个小时代码从头到尾把patch再merge一遍，再和我最新的比，确认完全OK了，才回家。

回家后还是惴惴不安预感会出事，等着看版本发布的邮件有没有发出来，我邮件叮嘱过他们，务必打电话和发短信，看信号条，如果有问题的话，千万别发出来。结果，我看到了凉风发布版本的软件。

今天，没敢偷懒，按时上班了。

打开邮箱，果然看到客户就开骂了，说软件版本有问题，下载后就没信号条了。我们顿时就明白，软件版本出问题了。

然后我拿到了log，分析出来是Modem Assert了，Nvram问题。其中他们发现如果没有写BINREGION的，就是正常的（我在这个时候竟然没想到是什么问题，我有点愚钝了，有时候）

然后review代码，发现有两个MTK Patch涉及到Nvram的修改，我review出MTK有个Patch更新Nvram结构体和内容后，并没有更新Nvram LID，我改了一下，让他们编译。

updata-modem出来的一样有问题，让new，结果new出来的也有问题。

这时候，我一边让人挨个去掉Patch编译验证，我一边分析。我看了一下assert的地方，竟然是L4_IMPORTANT的，但我合入的Patch都是普通的Nv啊。我去看modem Log，推算出NVRAM ID是SML的NV。

真相大白，原来是MTK在第一个Patch加了个宏，改了这个NV的长度（结构体都变了），而这个NV正是L4_IMPORTANT的NV，备份在BINREGION里，第一次开机会去读BINREGION尝试恢复，把旧的NV用新的结构体去解释，结果自然是读取失败了。

MTK这个Patch只是加了一个Option开关和一些库文件，注掉后编译验证OK。后续在SVN上的分支策略管理这支文件即可。

下午，又帮S看了一下NFC的问题，耗费了我一点时间。

最后验证了OTA升级lk.bin和logo.bin，这是我们第一次升级lk.bin。一般来说，都要支持Memory兼容的，客户要换Hynix的Memory，要升级lk.bin和logo.bin(Flash不够，部分放到logo.bin)了。其实标准Android OTA命令分别加上-l logo.bin -u lk.bin就可以了，但MTK方案有个坑，在编译otapackage的时候，在Makefile里就没有把这两项编译加进去。。。

总之，这周五还是比较愉快的，我总算是做了点事情，而且还比较快，找到了英雄用武之地的感觉，一天都在亢奋之中。这周六就不去加班了。