144
痞子衡维护的 NXP-MCUBootUtility 工具距离上一个版本(v2.3)发布过去 3 个月了，这一次痞子衡为大家带来了小版本升级 v2.3.1（第一次做 x.y.z 中 z 级别更新），这个版本主要有两个比较重要的改动需要跟大家特别说明一下。
一、v2.3.1 更新记录
二、两个不可忽视的更新
> 改进: 在使用 Flashloader 里擦除操作时，某些情况下需要先检查目标区域是否为空
> 修复: 当连接得到的 flash Page/Sector/Block Size 信息有误时，无法做进一步下载
2.1 确定指定 Flash 区域为非空后再擦
我们知道，工具对于 i.MXRT1xxx 系列开发板的外挂 Flash 擦写支持是通过加载二级
Flashloader 来实现的，而 Flashloader 来自于 SDK 包中的
boardsevkimxrt1xxxbootloader_examplesflashloader 工程。
Flashloader 中集成了完整的 FlexSPI NOR Flash 驱动，对于擦除操作，我们知道很多 Flash 都同时支持 4KB 和 64KB 擦除粒度，因为 Flashloader 是因 i.MXRT 芯片而异的，每个芯片的
具体 Flashloader 对于擦除的处理不尽相同，目前主要有两个策略：
策略 1：永远用 64KB 的粒度去做擦除。
策略 2：混合使用 4KB 和 64KB 的粒度来做擦除，大区域先用 64KB，到小区域再用 4KB 细化。
对于工具 v1.1 及之前版本，这两种策略的 Flashloader 配合工具使用都不会有问题。但是从 v1.2 开始，工具配合使用策略 1 的 Flashloader 会有一些问题。目前已知 RT1050 在 HAB 加密模式下，一键下载 App 后去回读会发现偏移 0x2000 之后本该是 App 的地方全是 0xFF，没能正确下载，原因是工具流程里会在下载完 App 之后写一次 FDCB，而做擦除时因为粒度是 64KB，所以误擦了已下载的 App。
因此 v2.3.1 里的解决方案是，先判断 FDCB 区域是否为全 0xFF，如果是的话，就不做擦除了，直接写 FDCB。这个不是完美的解决方案，最好的方案还是修改 Flashloader 去使用策略 2 的擦除方法。
2.2 不依赖读回的 Page/Sector/Block 信息去下载
工具在一键下载前首先需要连接上主芯片，在连接过程中会在左下角芯片状态窗口显示 Flash 的 Page/Sector/Block 信息，这个信息是从哪里来的呢？不同的情况下来源不同：
情况 1：如果当前 Flash 是全空的（或者没有 FDCB），那么 Flashloader 会读取 Flash 中的 SFDP 表，根据 SFDP 表中的信息（包含 Page/Sector/Block Size）自动生成用于启动的 512bytes 的 FDCB 写入 Flash 的起始地址处，并在软件界面同步显示。
情况 2：如果 Flash 中已有 FDCB（这个 FDCB 可能来自于 SDK 里的启动头，也可能是 Flashloader 读 SFDP 表生成的），那么 Flashloader 便会复用这个信息，不再重新写入 FDCB。
对于情况 2 中的 FDCB 来自于 SDK 里的启动头，如果启动头中没有填充有效的 Page/Sector/Block Size 信息，那么在工具窗口你会看到 Page/Sector/Block Size = 0x0/0xFFFFFFFF 的情况下，在这种情况下工具无法再进行后续下载，因为 v2.3 之前工具会用 Page/Sector Size 对擦除或烧写的长度做对齐，显然无法用 0x0/0xFFFFFFFF 做有效的对齐。
v2.3.1 做了改进，不再强制用 Page/Sector Size 对擦除或烧写的长度做对齐，因为 Flashloader 里本身就对传入的区域参数做了对齐处理。
至此，这次更新的主要特性便介绍完了。MCUBootUtility 项目地址为 https://github.com/JayHeng/NXP-MCUBootUtility， 虽然当前版本（v2.3.1）功能已经非常完备，你还是可以在此基础上再添加自己想要的功能。如此神器，还不快快去下载试用？
