这两天在学习csdk系统，昨晚销售小哥给了一个链接：http://doc.openluat.com/article/1416/0 其中零妖大佬说了关于cat1 差分升级的事。
本着求实的精神，就很像知道确凿的证据，最好有代码或者数据的依据。
所以今天特意准备了下评估板子，看看能不能拿到些直观的线索。
第一个想到的就是通过coolwatcher追查系统的日志。这里有个开发板和我的usb uart小板电平不匹配的小插曲，定位此问题又额外浪费了点时间，暂不展开，如果有人想细究再补充，先说结论：想稳定看coolwatcher的日志，你需要使用host log的串口方式，而不是用usb方式。
测试使用的是官方的ota平台： iot.openluat.com ,设备初始代码是自己编译的测试包， ota包使用同样的代码，只是改了下版本号，因为主要是验证流程，所以不用关注功能逻辑。
fota包的下载使用的是http，注意是http，不是https，主要原因就是简单，https是趋势。
第一步：
通过http获取到文件大小，这里对应是的是Content-Length
[ota] HTTPClientFindFirstHeader 21,Content-Length: 48330
[ota]GetSize fsz: 48330
6M左右的原始bin档，实际的下载大小只有48K左右，这就说明下载的是差分，而不是全量包。
第二步：
ota_parse otaProcess file size 48320, type 1
从48330 变成了48320 说明有10byte可能是控制描述数据，不细表。
第三步：
[ota] HTTPClientReadData readSize 511
[ota] HTTPClientReadData readTotalLen 1022, 48330
每次下载511个字节，一包一包开始下载
第四步：
中间重复无数包，通过总包大小控制下载次数，直到最后一包下载完成
[ota]--HTTPIntrnConnectionClose--
ota_parse otaDownloadDone appState 3 CoreState 1
[ota_parse] FILE: app 48320 0
app应该是文件名，48320是大小，0 是属性或者权限之类的吧。
第五步：校验
ota_app crc (f7ddf30f,f7ddf30f)
ota openat_newApp appImageIsVaild ok
使用的应该是crc32 的校验的多包累加和，纯瞎猜，不求证
第六步：更新ota的标志
ota check 1,0
ota check 1,1
ota OPENAT_newOtaFlagSet 102
这个102应该就是告诉bootloader这个是刚ota完成，第一次需要做些特殊的工作。
第七步：下载完成
ota_parse _otaDownloadDone ok
[ota]fota end 0
看日志，整个升级48k大小的样子，花了6s完成，基本无感知，所以如果你用usb方式看日志，可能coolwatch还没连接上，升级就完成了