193
我们知道 KBOOT 是一个完善的 Bootloader 解决方案，这个解决方案主要设计用于 Kinetis 芯片上，目前 Kinetis 芯片起码有上百种型号，KBOOT 在这上百种 Kinetis 芯片里存在的形式并不是完全一样的，KBOOT 主要有三种存在形式（ROM Bootloader、Flashloader、Flash-Resident Bootloader），下面痞子衡为大家细说这三种形态：
一、KBOOT 形态区别
KBOOT 有三种形态，分别是如下图所示的 ROM Bootloader、Flashloader、Flash-Resident Bootloader，三种形态共享大部分 KBOOT 源码，仅在一些细节上有差别，这些细节在 KBOOT 源码里是用条件编译加以区分的，对应的条件编译宏分别是 BL_TARGET_ROM, BL_TARGET_RAM, BL_TARGET_FLASH。三种形态最大的区别其实是在链接文件上，经过汇编器后的 read only section 分别链接在了 Kinetis 芯片 System memory 空间里的 ROM（起始地址 0x1c000000）、RAM（区间地址 0x20000000）、Flash（起始地址 0x00000000）区域。
下表是 KBOOT 三种形态的对比，分别从 use case、delivery mechanism、supported device、clock configuration、feature 五大角度进行了对比：
总结来说，可以这么看 KBOOT 这三种存在的由来：
对于 2014 年初及以后问世的 Kinetis 芯片（比如 MKL03、MKL27、MKL43、MKL80、MKE18F 等），芯片内基本都是含 ROM 空间的，因此 KBOOT 是以 ROM Bootloader 的形式存在的；
对于 2014 年初及以后主推的 Kinetis 芯片（比如 MK22、MK65、MKV31、MKS22 等），芯片内虽然没有 ROM 空间，但飞思卡尔希望能给客户提供至少一次免编程器烧录 Application（用于量产）的机会，因此 KBOOT 是以 Flashloader 的形式存在的；
对于在市场上主流又畅销的 Kinetis 芯片（比如 MKL25、MK22、MK66、MKL28 等），不管芯片内是否有 ROM 空间，飞思卡尔都希望能够给出 Bootloader 源码，以便让客户自由修改来满足其个性化需求，因此 KBOOT 是以 Flash-Resident Bootloader 的形式存在的；
二、KBOOT 各形态实现
2.1 ROM Bootloader
KBOOT 的 ROM Bootloader 形态是放在 ROM 空间里的，随着芯片一起 Tape-out 出厂，固化在芯片里面，所以该形态可以被当做硬件模块，可以被无限次使用。
因为有了 ROM 的存在，所以芯片上电启动便有了两种选择：从 ROM 启动、从内部 Flash 启动，这种启动选择是由芯片系统决定的。
如果是从 ROM 启动，那么我们可以借助 ROM 将 Application 烧写进 Flash（内部 / 外部）的起始空间并跳转过去执行。跳转至 Flash 执行分为：从内部 Flash 执行、从外部 QSPI NOR Flash 执行，这种执行选择是由 ROM 代码决定的。
如果已经使用 ROM 将 Application 下载进内部 Flash 起始地址，并在系统设置里设置芯片从内部 Flash 启动，那么下次芯片复位启动完全可以绕开 ROM 直接从内部 Flash 起始地址执行 Application。
2.2 Flash-Resident Bootloader
KBOOT 的 Flash-Resident Bootloader 形态是放在内部 Flash 起始空间的，以源代码的形式提供给客户，客户需要自己编译 KBOOT 工程并使用编程器 / 调试器将编译生成的 KBOOT binary 下载进芯片内部 Flash 起始地址，除非使用调试器将其擦除，否则其也可以被无限次使用。
对于没有 ROM 的芯片，芯片上电只能从内部 Flash 起始地址处开始启动，因为 Flash-Resident Bootloader 已经占据了内部 Flash 的起始空间，所以芯片永远是先执行 Flash-Resident Bootloader。借助 Flash-Resident Bootloader 只能将 Application 烧写进内部 Flash 一定偏移处（这个偏移地址由 Flash-Resident Bootloader 指定）并跳转过去执行。
2.3 Flashloader
KBOOT 的 Flashloader 形态其实也是放在内部 Flash 起始空间的，不过与 Flash-Resident Bootloader 形态在 Flash 里执行不同之处在于 Flashloader 形态是在 SRAM 里执行的，众所周知，SRAM 断电是不保存数据的，因此 Flashloader 需要一个放在内部 Flash 里的配套 loader 程序，在芯片上电时先运行 Flash 里的 loader 程序，由 loader 程序将 Flashloader 从 Flash 中搬运到 SRAM 中并跳转到 SRAM 中运行。
Flashloader 是在芯片出厂之后由飞思卡尔产品工程师将其 binary 预先下载进内部 Flash 再售卖给客户，所以客户拿到芯片之后至少可以使用一次 Flashloader，客户借助 Flashloader 可以将 Application 烧写进内部 Flash 起始空间(同时也覆盖了原 Flashloader-loader)，这就是 Flashloader 只能被使用一次的原因。
2.3.1 loader 机制
关于 loader 机制与实现，有必要详细讲解一下，让我们结合代码分析，首先从官网下载 NXP_Kinetis_Bootloader_2_0_0.zip 包，就以 KS22 芯片为例（\targets\MKS22F25612\bootloader.eww）：
使用 IAR EWARM 7.80.x 开发环境打开 KS22 的 Bootloader 工程，可以看到有如下三个工程，其中 flashloader.ewp 便是主角，其源码文件与 ROM 和 Flash-Resident Bootloader 是一样，只是工程链接文件有区别，其代码段链接在于 SRAM 里；maps_bootloader.ewp 便是 Flash-Resident Bootloader，不是此处讨论的重点；flashloader_loader.ewp 就是 Flashloader 能在 SRAM 里执行的关键所在。
flashloader_loader.ewp 工程里除了必要的芯片 startup 文件外，只有三个源文件：flashloader_image.c/h，bl_flashloader.c，其中 bl_flashloader.c 里包含了工程 main 函数，让我们试着分析这个文件以及 main 函数，下面是 bl_flashloader.c 的文件内容：
#include <string.h>
#include "bootloader_common.h"
#include "fsl_device_registers.h"
#include "bootloader/flashloader_image.h"
#if DEBUG
#include "debug/flashloader_image.c"
#else
#include "release/flashloader_image.c"
#endif
////////////////////////////////////////////////////////////////////////////////
// Code
////////////////////////////////////////////////////////////////////////////////
// @brief Run the bootloader.
void bootloader_run(void)
{
// Copy flashloader image to RAM.
// 关键拷贝，实现了 flashloader binary 从 Flash 到 RAM 的转移
memcpy((void *)g_flashloaderBase, g_flashloaderImage, g_flashloaderSize);
// Turn off interrupts.
__disable_irq();
// Set the VTOR to default.
SCB->VTOR = 0x0;
// Memory barriers for good measure.
__ISB();
__DSB();
// Set main stack pointer and process stack pointer.
__set_MSP(g_flashloaderStack);
__set_PSP(g_flashloaderStack);
// Jump to flashloader entry point, does not return.
// 关键跳转，执行位置从 Flash 切换到了 RAM
void (*entry)(void) = (void (*)(void))g_flashloaderEntry;
entry();
}
// @brief Main bootloader entry point.
int main(void)
{
bootloader_run();
// Should never end up here.
while (1);
}
从上述 bl_flashloader.c 的文件里我们可以看到，其实 loader 工程的 main 函数特别简单，它就是将内部 Flash 里的 g_flashloaderImage[]数据（即 flashloader.ewp 编译生成的 binary）拷贝到 g_flashloaderBase 地址（即 flashloader binary 起始地址）处，并将 SP 和 PC 分别指向 g_flashloaderStack（即 flashloader 初始 SP）和 g_flashloaderEntry（即 flashloader 的 Reset Handler 入口）。
那么 g_flashloaderXX 常量都放在哪里的呢？打开 \targets\MKS22F25612\iar\flashloader\output\Release\flashloader_image.c 可以找到答案:
const uint8_t g_flashloaderImage[] = {
0x70, 0x62, 0x00, 0x20, 0x11, 0xc4, 0xff, 0x1f, 0xeb, 0xc4, 0xff, 0x1f, 0x75, 0xef, 0xff, 0x1f,
// 此处省略 41552 bytes
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
const uint32_t g_flashloaderSize = 41584U;
const uint32_t g_flashloaderBase = 0x1fffc000;
const uint32_t g_flashloaderEntry = 0x1fffc411;
const uint32_t g_flashloaderStack = 0x20006270;
loader 机制越来越清晰了，现在只剩最后一个问题了，flashloader_image.c 文件是哪里来的？这个文件当然可以手动创建，文件里的信息都可以从 flashloader.ewp 工程生成的 elf/map 文件里中找到，但本着高效的原则，但凡能脚本自动生成的决不手动创建，是的这个 flashloader_image.c 文件就是脚本自动生成的，在 flashloader.ewp 的 Option 选项的 Build Actions 里可以看到调用脚本的命令，这个脚本名叫 create_flashloader_image.bat。
在 \bin 目录下存放了所有脚本文件，当然也包括 create_flashloader_image.bat，先打开这个脚本看一下：
cd /d %1
ielftool --bin output\%2\flashloader.elf flashloader.bin
python ..\..\..\..\bin\create_fl_image.py output\%2\flashloader.elf flashloader.bin output\%2\flashloader_image.c
ielftool.exe 是 IAR 软件目录下的工具，可以将 elf 文件转换成 bin 文件。最核心的脚本其实是 create_fl_image.py，这个 python 脚本根据 elf 文件和 bin 文件生成了 flashloader_image.c 文件。打开 create_fl_image.py 文件如下（作了一些异常判断的删减，为了突出脚本主逻辑）：
import sys
import os
import elf
# usage: create_fl_image.py <elffile> <binfile> <cfile>
def main(argv):
# Collect arguments
elfFilename = argv[0]
binFilename = argv[1]
cFilename = argv[2]
# Open files
binFile = open(binFilename, 'rb')
cFile = open(cFilename, 'w')
# 创建了 elfData 对象，用于后续处理 .elf 格式文件
elfData = elf.ELFObject()
with open(elfFilename, 'rb') as elfFile:
# 开始处理输入的 .elf 文件
elfData.fromFile(elfFile)
if elfData.e_type != elf.ELFObject.ET_EXEC:
raise Exception("No executable")
# 开始从 .elf 里获取关键信息
resetHandler = elfData.getSymbol("Reset_Handler")
vectors = elfData.getSymbol("__Vectors")
stack = elfData.getSymbol("CSTACK$$Limit")
# Print header
print >> cFile, 'const uint8_t g_flashloaderImage[] = {'
# Print byte data
totalBytes = 0
while True:
data = binFile.read(16)
dataLen = len(data)
if dataLen == 0: break
totalBytes += dataLen;
cFile.write(' ')
for i in range(dataLen):
cFile.write('0x%02x, ' % ord(data[i]))
print >> cFile
print >> cFile, '};\n'
# Print size and other info
cFile.write('const uint32_t g_flashloaderSize = %dU;\n' % totalBytes)
cFile.write('const uint32_t g_flashloaderBase = 0x%x;\n' % vectors.st_value)
cFile.write('const uint32_t g_flashloaderEntry = 0x%x;\n' % resetHandler.st_value)
cFile.write('const uint32_t g_flashloaderStack = 0x%x;\n' % stack.st_value)
if __name__ == "__main__":
main(sys.argv[1:])
create_fl_image.py 脚本里除了普通文件操作外，最关键的是这句 elfData = elf.ELFObject()，调用了 elf.py 文件提供的 elf 格式文件操作接口，通过这些接口得到了 flashloader 里的关键信息（vectors、resetHandler、stack），感兴趣的可以自己去分析 elf.py 文件。
三、KBOOT 各形态芯片支持
截止目前（2017 年），KBOOT 支持的 Kinetis 芯片全部列出在下表：
至此，飞思卡尔 Kinetis 系列 MCU 的 KBOOT 形态痞子衡便介绍完毕了，掌声在哪里~~~
