OTA三种差分算法安装&使用。bsdiff,hdiffpatch,xdelta3

 目前在做OTA差分算法研究,基于baidu.google, gayhub各种资料和途径,整理出来了三种OTA算法的安装步骤及使用方法。

 

1.bsdiff

我就不简介了,网上百度巴拉巴拉一大堆,我就把如何安装还有使用命令的教程给列出来。

a 依赖的tar bsdiff-4.3.tar.gz    bzip2-1.0.6.tar.gz

     解压:    tar –zxvf bsdiff-4.3.tar.gz  

      解压:    tar –zxvf bzip2-1.0.6.tar.gz

      重命名:  mv bzip2-1.0.6.tar.gz  bzip2

      将bzip2文件夹移动到 /usr/local/include :   sudo  cp –r bzip2 /usr/local/include

b 依赖的源

       yum install bzip2-devel.x86_64 进行下载

c修改 bsdiff-4.3 文件夹里面的 bsdiff.c 和bspatch.c

在include 头里添加

#include "bzip2/bzlib.c"

#include "bzip2/crctable.c"

#include "bzip2/compress.c"

#include "bzip2/decompress.c"

#include "bzip2/randtable.c"

#include "bzip2/blocksort.c"

#include "bzip2/huffman.c"

如图:

    

 

修改Makefile

 在.ifndef和.endif 前面加一个 tab 空出距离,否则报错

如图:

   

 

准备工作完成以后 进行编译 : make

 

1.1运行命令

两个绿色的就是编译出的命令行

 差分:  ./bsdiff  [oldfile] [newfile] [patchName]

 合成:  ./bspatch [oldfile] [newFileName] [patchName]

对比文件是否有差异: sha1sum  [fileName] 检验文件完整性和hash值。

2.hdiffpatch

a 需要用到的zip包:  HDiffPatch-master.zip , lz4-dev.zip, zstd-dev.zip, lzma-master.zip

 

b解压

   unzip HDiffPatch-master.zip

   unzip lz4-dev.zip

 

unzip zstd-dev.zip

unzip lzma-master.zip

 

重命名

mv HDiffPatch-master  hdiffpatch

mv lz4-dev  lz4

mv zstd-dev  zstd

mv lzma-master  lzma

 

在/usr/local/include/bzip2 目录下 将 bzlib.h 复制到 /usr/local/include  

sudo   cp bzlib.h  ../

安装 zlib:  yum install -y zlib zlib-devel (如果是ubuntu的话 需要  apt-get install zlib1g zlib1g-dev)

 

c 编译:

 

   

成功结果:

 

2.1使用命令

执行命令的语法:

   拆分: ./hdiffz [oldFile] [newFile] [patchName]

   合成: ./hpatchz [oldFile] [patchName][oldFileName]

命令详解:

hdiffz [-m[-matchScore]|-s[-matchBlockSize]]  [-c-compressType[-compressLevel]] [-o] oldFile newFile outDiffFile

hpatchz  [-m|-s[-s-cacheSize]]  [-o] oldFile diffFile outNewFile

建议命令参数:

      hdiffz run by: -s-128 -c-bzip2-9 [oldFile] [newFile] [outDiffFile]
    hpatchz run by: -s-4m [oldFile] [diffFile] [outNewFile]

对比文件是否有差异: sha1sum  [fileName] 检验文件完整性和hash值。

2.2hdiffz 参数简介

-m matchScore

 

使用matchScore将所有文件加载到内存中,默认是difffileSize 这种方式不推荐.

 

 

-s-matchBlockSize

所有文件加载为流式处理,参数由matchBlockSize决定,参数设置例如 128 128K 128M

默认128,建议32 - 16K 64K 1M等。

 

特殊选项:

C-压缩-压缩能级

设置差分文件的压缩类型和级别,默认不压缩;

支持压缩类型和级别:

(参考:HTTPS://Github. COM/SISON/LZTAMP/BROB/MARST/LZTAT17171SORTED.D)

       -zlib[-{1..9}]              DEFAULT level 9

        -bzip2[-{1..9}]             DEFAULT level 9
        -lzma[-{0..9}[-dictSize]]   DEFAULT level 7
            dictSize(==decompress stream size) can like 4096 or 4k or 4m or 128m etc..., DEFAULT 4m
        -lz4                         no level
        -lz4hc[-{3..12}]            DEFAULT level 11
        -zstd[-{0..22}]             DEFAULT level 20

2.3hpatchz 参数简介

内存参数:

  -m  旧文件全部加载入内存

  -s-cacheSize  旧文件以流的方式加载。

  cacheSize can like 262144 or 256k or 512m or 2g etc..., DEFAULT 128m

 

3.Xdelta3

  1. 依赖的包 xdelta-gpl-release3_1.zip
  2. 解压,unzip xdelta-gpl-release3_1.zip

cd   xdelta-gpl-release3_1/xdelta3

在当前文件夹执行命令:   ./run_release.sh

                                        autoscan .

                                        aclocal

                                        autoheader

                                        automake –add-missing

                                       ./configure

                                       make

    

 

3.1命令

执行命令的方法

拆分 :  ./xdelta3 -v -e -s [oldFile] [newFile] [patchName]

合成 :  ./xdelta3 -v -d -s [oldFile] [patchName] [newFileName]

对比文件是否有差异: sha1sum  [fileName]  检验文件完整性和hash值。

命令详细参数

用法: xdelta3 [命令/选项] [input [output]]

特殊命令名:

    config      输出 xdelta3 配置信息

    decode      解压缩 input

    encode      压缩 input

    test        运行内置的测试

为 VCDIFF 输入所用的特殊命令:

    printdelta  输出整个变化的信息

    printhdr    输出第一个窗口的信息

    printhdrs   输出所有窗口的信息

标准选项:

   -0 .. -9     压缩等级

   -c           使用 stdout

   -d           解压缩

   -e           压缩

   -f           强制覆盖

   -h           显示帮助

   -q           静默模式

   -v           使用详细信息(最大2)

   -V           显示版本

内存选项:

   -B bytes     源窗口大小

   -W bytes     输入窗口大小

压缩选项:

   -s source    如果存在,选择来源文件从哪儿复制

   -S [djw|fgk] 启用/弃用二级压缩

   -N           弃用小字符串匹配压缩

   -D           弃用外部解压缩 (压缩/解压缩)

   -R           弃用外部重压缩 (压缩)

   -n           弃用校验 (压缩/解压缩)

   -C           软配置 (压缩, 无文档的)

   -A [apphead] 弃用/提供程序头部 (压缩)

 

4.系统环境

系统:centos7

依赖:C++ gcc –v和 g++ -v  如果没有显示出对应的版本,则需要

执行 :yum groupinstall "Development Tools"

   安装一些常用的开发者开发命令

<think>好的,用户想了解MCU的OTA升级方法和解决方案。首先,我需要回顾一下之前的对话。用户之前询问了T-BOX与车机娱乐系统的连接,现在转向MCU的OTA升级,这可能与汽车电子系统或其他物联网设备的固件更新有关。 根据用户提供的引用资料,引用1到5提到了不同的OTA方案,包括差分升级、Boot升级、硬件复位机制、MCU重启问题以及标志位设置。用户需要综合这些信息,给出MCU OTA升级的具体方法和解决方案。 首先,要明确MCU OTA的基本概念。MCU通常资源有限,不像高性能处理器那样容易处理大文件,因此需要考虑节省带宽和存储空间的方案,比如差分升级。引用2提到艾拉比的整机级方案,使用差分算法减少下载时间,这可能适用于MCU。 接下来,需要考虑升级过程中的安全性。引用1提到版本校验,引用2和3强调了安全鉴权和回滚机制,这些都是关键点。另外,引用3提到硬件IO检测作为恢复机制,这对防止升级失败导致设备变砖很重要。 然后,硬件设计方面,引用4指出MCU重启时的供电问题,可能导致无法正常重启。需要设计独立的电源管理模块,或者软件上确保重启时维持供电。引用5提到在特定内存地址放置标志位,用于Bootloader判断升级状态,这也是常见的做法。 用户可能还关心具体的实现步骤,比如Bootloader设计、双区存储切换、断点续传等。需要将这些技术点组织成清晰的方案,并给出行业案例,比如家电或汽车中的应用,如引用2中的家电方案和引用1的OTA服务流程。 最后,要确保回答结构清晰,分点说明,涵盖基本原理、关键技术、安全设计、典型方案和行业案例。同时,生成的相关问题要引导用户深入探讨,比如安全性优化或资源受限下的解决方案。</think>### MCU OTA升级方法及解决方案深度解析 MCU(微控制器单元)的OTA(空中下载技术)升级是物联网设备固件更新的关键技术,其核心挑战在于资源受限环境下的可靠性、安全性和兼容性设计。以下结合行业实践与引用资料提供系统性解决方案: --- #### 一、MCU OTA基本原理 1. **技术架构** $$ \text{云端管理平台} \xrightarrow{\text{HTTPS/MQTT}} \text{MCU固件包} \xrightarrow{\text{差分/全量}} \text{设备端Bootloader} \xrightarrow{\text{双区切换}} \text{运行新固件} $$ 典型流程包含**版本检测→下载→校验→激活→回滚**五个阶段[^1]。 2. **核心组件** ```text - Bootloader:占用4-16KB Flash,实现固件校验、跳转(引用5) - 双存储分区:Active(运行区)与Backup(升级区) - 硬件看门狗:防止升级过程卡死(引用4) ``` --- #### 二、关键技术实现方案 1. **差分升级优化** - **算法选择**:针对Renesas等MCU优化BSDiff/XDelta算法,压缩率可达60%-90%(引用2) - **内存管理**:采用分块下载机制,示例代码: ```c #define BLOCK_SIZE 512 // 根据RAM容量调整 uint8_t ota_buffer[BLOCK_SIZE]; while (download_next_block(ota_buffer)) { flash_write(ota_buffer, current_address); current_address += BLOCK_SIZE; } ``` 2. **安全启动设计** - **数字签名**:使用ECDSA或RSA算法验证固件完整性 - **防回滚**:在Flash特定位置(如0x00000FF0)存储版本号(引用5) $$ \text{签名验证流程: } \sigma_{\text{新固件}} \stackrel{?}{=} \text{Verify}(PK_{\text{厂商}}, H(\text{Firmware})) $$ 3. **硬件辅助升级** - **强制恢复模式**:通过检测GPIO引脚电平(如长按按键3秒)触发出厂固件恢复(引用3) - **独立供电设计**:采用LDO+电容组合确保升级期间不掉电(引用4) --- #### 三、典型解决方案对比 | 方案类型 | 适用场景 | 优点 | 缺点 | |----------------|---------------------------|-------------------------------|-----------------------| | **双区切换** | 资源充足型MCU(>128KB Flash) | 升级失败可回滚,可靠性高 | 占用双倍存储空间 | | **原地升级** | 低资源MCU(<64KB Flash) | 节省Flash空间 | 需完整校验防止数据损坏| | **压缩差分** | 网络带宽受限环境 | 减少70%数据传输量(引用2) | 需额外RAM进行解压 | --- #### 四、行业实践案例 1. **家电领域** - **艾拉比方案**:通过组件化设计实现家电整机OTA,支持Homebus/CAN等多总线(引用2) ```mermaid graph TB 云平台--加密差分包-->WiFi模块--SPI-->主控MCU--CAN-->子设备MCU ``` 2. **汽车电子领域** - **双Bank升级**:在STM32中划分Bank1(运行区)与Bank2(升级区),通过FLASH_CR寄存器的SWAP位实现热切换[^1] - **安全回滚**:当CRC校验失败时,自动跳转至备份固件(引用3) --- #### 五、关键问题解决方案 1. **断电保护机制** - **断点续传**:在Flash中记录已下载块的位置索引 - **原子操作**:使用STM32的Flash编程锁防止写操作中断 2. **资源受限优化** - **混合升级模式**:小更新用全量升级(代码段<10KB),大更新用差分升级 - **内存复用**:复用通信缓冲区作为解压暂存区 --- ### 相关问题 1. 如何设计MCU OTA升级中的数字签名验证流程? 2. 在RAM不足的情况下如何实现差分升级包的解压? 3. 汽车电子领域的MCU OTA与消费电子领域有哪些特殊要求差异? [^1]: 实际工程中需根据MCU的Flash分页特性设计双区切换机制,例如STM32F4系列的Sector擦除规则。 [^2]: 家电领域OTA需考虑多设备协同升级,需实现主控MCU与子设备的分批升级调度。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值