嵌入式设备固件代码升级流程及总结。

嵌入式设备的程序是存在flash中的。

首先要明确flash区域的划分：

名称 地址
boot 0x0000 ~0x10000
应用层(app) 0x10000~ 0x80000

• 升级的流程步骤：
  • step1: 下发升级使能的参数配置：根据通信下发的配置的参数判断要不要升级
  • step2: 上位机 获取ImageBlockSize(获取升级包的大小)，这样上位机每帧数据可以传固定字节数的升级包
  • step3: 初始化升级过程，上位机下发的数据格式是包含两个元素的结构体， image_identifier和image_size。其中 image_identifier包含了配置文件(配置文件里面的数据就是上位机用来下发升级相关的参数的），主要包含：文件类型+对散列校验码加密的加密类型+ 校验类型+版本控制+ 散列校验码(当对散列校验码加密的加密类型) 。入伙文件类型为0xFD，加密类型位0x01，校验类型为0x01，版本控制为" VERSON001"，散列校验码或散列校验码密文。重点： 上面所说的都是上位机下发下来的，下位机也就是嵌入式设备此时需要清除升级镜像和传输位图。
  • step4: 传输升级包：上位机每次下发的数据是包含2个元素的结构体：block num和update_data。下位机对刚接收到的第一帧升级数据，需要进行特殊处理下（要传升级包了，嵌入式设备总的准备下呀），往后的升级包，嵌入式设备只需要正常的保存下下发的升级包内容，更新下升级包的位图就可以了。
  • step5:检查升级包是否传输完成:上位机将升级包传输完成后，这时候要读下表里面的参数（也就是升级包的位图），根据下位机也就是嵌入式设备返回的升级包位图来判断下，升级包是否传输完整，判断出哪包数据漏了。
  • step6: 校验升级包：上位机给嵌入式设备下发校验明令，此时嵌入式设备校验下自己接受到的升级数据和上位机下发的升级数据的校验码是否一致
  • step7:检查表中的升级信息：上位机读下step3:传给表里面的参数此刻是否正确
  • step8:激活：上位机下发激活命令后，表计进入掉电处理，并且复位。复位成功后，进入boot阶段，应用程任务结束。
• 何为uboot ?
  • uboot是一个裸机程序，比较复杂
  • uboot就是一个bootloader，作用就是启动linux或其他系统。Uboot最主要的作用就是初始化DDR，因为linux是运行在DDR里面的，一般镜像zlmage(ulamage)+设备树(.dtb)存放在SD、EMMC、NAND、SPI、FLASH等外置存储区域。这时候就牵扯到一个问题，需要linux镜像从外置flash拷贝到DDR中，再去启动。
  • uboot的主要目的就是位系统的启动做准备
  • ubpot不仅仅可以启动linux，也可以启动其他系统，比如vxworks。
  • linux不仅仅能通过uboot启动
  • uboot是一个通用的bootload，它支持多种架构。
• uboo获取：
  • step1: 首先就是uboot官网，缺点就是支持少，比如某一款具体芯片驱动等不完善。
  • step2:soc厂商会从uboot官网上下载某一个版本的uboot，然后在这个版本加上soc及驱动，这就是soc厂商定制的uboot，NXP官方的I.MX6ULL EVK板子。
  • step3:做开发板的厂商，开发板会参考SOC厂商的板子，开发板板必选和官方的板子不一样，这样开发板厂商又会去修改soc厂商做好的uboot，以适应自己的板子。
• 正点原子官方uboot编译：
  • step1: 编译uboot的时候需要先配置
  • step2:编译完成后就会生成一个uboot.bin，必须向uboot.bin添加头部信息。uboot编译最后会通过/tools/mkimage软件添加头部信息，生成uboot.imx。
  • step3:如果配置过uboot，那么一定要注意shell脚本会清除整个工程，那个配置的文件也会被删除，配置项也会被删除掉。
  • step4:为了方便开发，建议直接在uboot顶层makefile里面设置好ARCH和CORSS_COMPILE这两个变量的值。