一、 概述
本文介绍 E3 PAC 打包,编译器生成 bin 文件需要通过打包生成 PAC 包,再通过 SDToolBox 工具将 PAC 包烧写到芯片,PAC 包的物理载体分为 Flash、eMMC、SD,一个 PAC包最多支持 3 个BootPackage;本文主要描述打包方式、打包注意事项、PAC 包下载的物理地址,打包方式分为手动打包(命令行打包)和自动打包(Python 脚本自动打包)。
硬件平台:E3640官方开发板(SD103_E3_GATEWAY_ePOWERTRAIN_A03_019);
软件环境:SDToolBox、IAR Embedded Workbench for ARM 8.50.6。
图1 E3640 官方开发板
二、 打包说明
芯片复位后,当启动核从复位状态退出时,集成于芯片内部的 ROM 程序在启动核中开始运行,以完成芯片的启动过程,因此为了能够启动 E3 芯片,需要完成以下步骤:
- 将编译得到的各个 core 的可执行程序(bin文件)合并并签名,得到 Boot Package 文件,如下图打包过程 1;
- 如启动设备为 Flash,则需要加载 SFS 文件,同时如果需要在 Flash 中加密启动,则需要再加载 RFD 文件,如果不需要加密启动,则 RFD 文件可以不存在;如果启动设备为 eMMC、SD 卡,则不需要 SFS 文件、 RFD 文件;如下图打包过程 2;
- 将上述文件打包在一个 PAC 文件中,使用 SDToolBox 下载工具完成烧写。
1.1 Boot Package
1.1.1 Boot Package 组成
由编译器生成的 bin 文件,需要签名生成 Boot Package 才能生成 PAC 包,烧写进芯片,其中 Boot Package 组成部分如下:
BPT(Boot Package Table):位于 Boot Package 最前端,共占用 4096(0x1000)个字节。BPT 包括以下信息:
- Boot Package 的签名信息
- 各个镜像在 Image 组合中的相对位置(DLP)
- 镜像加载地址(Load Address)
- 镜像运行时的入口地址(Entry)
- HASH 校验信息
- PSN 信息
程序镜像组合(Images):多个 core 的用户程序镜像组合,包含:
- CPU cluster0 镜像
- CPU cluster1 程序镜像(可配置为 Split 或者 Lockstep)
- CPU cluster2 程序镜像(可配置为 Split 或者 Lockstep)
- Bootloader 镜像
- SCB 系统控制块(System Configuration Block)
注:图中 Image download 地址为相对于 BPT 相对偏移地址
1.1.2 Boot Package 类型与存储方式
一个 PAC 包中支持三种 Boot Package ,分别为:Normal Boot Package、Backup Boot Package、Third Boot Package,三个 Boot Package 互为冗余。
芯片从不同介质启动,设备能支持的 Boot Package 类型和存储地址见下表:
Boot Package 类型与存储地址分配表
启动设备 | Normal Boot Package存储地址 | Backup Boot Package存储地址 | Third Try Boot Package存储地址 | 备注 |
HyperFalsh | 0xC0000 | 0x4C0000 | 0x8C0000 | 表中标注为默认地址,具体存储地址参见SFS文件,地址划分需要与Flash芯片扇区对齐 |
NorFlash | 0x7000 | 0x407000 | 0x807000 | |
eMMC | BOOT1分区 offset=0 | BOOT2分区 offset=0 | User Areas分区 offset=20KB | |
SD 卡 | offset=20KB |
1.2 download 文件
1.2.1 Dloader
如果使用 USB 下载,需形成可用的 Dloader;目前在 ssdk\devices\$(PART)\-
dloader 路径下提供预编译好的 binary 文件,此 Dloader 需要进行签名形成 Boot Package 才能用于下载。以 e3_gateway 板卡的 HyperFlash 版本的 Dloader 为例,将 e3_gateway_hyperFlash.bin 拷贝到 ssdk\tools\sdtools\temp\src\-e3_gateway_hyperFlash.bin ,使用命令进行签名。
注:Dloader命令行打包时加载地址与入口地址必须是 0x404000,与 Dloader 软件保持一致,设置其他参数有误。
1.2.2 Flashloader
如果使用 JTAG 下载,需形成可用的Flashloader。目前 ssdk\devices\$(PART)\Flashloader 路径下提供预编译好的 binary 文件,此 Flashloader 供工具使用,无需进行签名。以 e3_gateway 板卡的 HyperFlash 版本的 Flashloader 为例,直接将 Flashloader_hyperFlash.out 拷贝到 ssdk\tools\sdtools\temp\ 路径下重命名为downloader_e3_gateway_signed.bin 即可。
1.3 SFS 文件
SFS 是 Flash 的配置文件,在拨码到 Flash 启动模式前,需要先在 Flash 的起始位置预先烧写 SFS 供 ROM 解析,否则从 Flash 启动会失败。可以使用 CMD 命令根据配置文件来生成 SFS 文件,示例配置文件路径为: ssdk\tools\sdtools\sfs\xxx.json 可以使用如下命令将配置文件转换为 sfs.img 用于下载。
1.3.1 命令行方式
其中 0x7000,0x407000, 0x807000 是指定 3 个 Boot Package 的地址,is25-1-1-4.json 是 SFS 配置文件示例,sfs_is25-1-1-4.img 为输出文件。
1.3.2 JSON 文件方式
根据 pac_config.json 中 sfs 字段查找SFS的配置文件进行打包,例如: ssdk\devices\E3640\pacconfig\pac_config_5_core.json 中 sfs 的配置信息为:
该打包配置文件中使用了 sfs 的配置文件为 s26h-hyperFlash.json ,Boot Package 配置地址为 0xC0000,0x4C0000,0x8C0000。在执行打包的过程中, sfs.img 将会被生成并打包到 PAC 包中。
1.4 RFD 文件
关于 RFD 相关部分参加芯驰官方文档《AppNote_E3_Boot_and_OTA》第 11 章节。
1.5 命令行打包
1.5.1 打包过程一:bin 文件签名 Boot Package
- 先把编译产物拷贝到指定路径下,以 ssdk\tools\sdtools\temp_boot_core 路径为例(如果没有temp_boot_core文件夹可新建一个);
- 在 SSDK 根目录打开 cmd 命令行,再进入 ssdk\tools\sdtools 路径;或者可以在 sdtool 根目录下打开命令行;
- 使用如下指令将各个 core 的编译产物(binary文件)打包成 Boot Package 文件:
上述命令行的参数信息如下表;
参数 | 数据 |
--v | 固定写 2,表示当前 atb_signer 版本为 v2 |
--sec_ver | 表示安全启动的版本,ROM 会与 FUSE_PKG_VER[0:127] 中烧写的版本信息进行比较,如果低于fuse中烧写的版本号,则无法用于启动,该 功能用于防回滚到某个较低版本。 |
--dgst | 指定校验算法的类型(sha256/sha512) |
--rcp | 表示使用的签名的私钥路径。例:key=sign_tool\keys\TestRSA2048_ossl.pem |
--iib | 每一个 image 都通过一个 --iib 表示,iib之后的参数为: * " flag ": 值为 0x80 时 ROM 不 kick sp0/sp1/sx0/sx1;值为 0xc0 时 ROM 不 load sp0/sp1/sx0/sx1; * " core ":对应镜像属于哪个核,0 表示为 SF core,2 表示为 SP core0,3 表示为 SP core1,4 表示为 SX core0,5 表示为 SX core1,6 表示为 SX in lockstep mode,7 表示 SP in lockstep mode; * " type ":镜像的类型,0 表示普通镜像,0xf 表示 SF core 的 Bootloader 程序; * " image ":镜像文件的路径; * "dlp" :表示镜像在 Boot Package 中存储的相对位置,以 512 字节为单位,比如 0x8,表示存储的位置相对于 Boot Package 起始位置的偏移为 8*512=4096 字节; * " to ":镜像的加载地址,此处指定的均为 IRAM 地址; * " entry ":程序的入口地址,通常和"to"参数是一样的,ROM 会在镜像加载到"to"参数指定的地址后,跳转到"entry"指定的地址开始执行; * " noHASH ":表示该 iib 对应的程序不做 HASH 校验 |
--psn | 指定 PSN 版本号 |
--of | 指定输出文件的路径和格式 |
按照上述命令我们可以依次打包得到: Backup Boot Package、Third Try Boot Package。
1.5.2 打包过程二:生成 PAC 包
该过程会把 Boot Package文件、Downloader 程序、SFS 等文件打包成 PAC 文件,用于 USB 或 JTAG/SWD 下载。
- Flash 打包形成 PAC 文件的命令为:
- eMMC/SD 卡形成 PAC 包文件的命令为(无需SFS与RFD):
- 将现有的 bin 文件加到 PAC 包中,命令行如下:
具体打包命令的参数解析如下表所示:
参数 | 解析 |
make_pac_image_no_gpt | 使用无分区表的打包方式 |
--output | 输出的pac包路径 |
--allow_empty_partitions | 运行分区表为空(不使用分区表无效果) |
--da | Downloader(Dloader/Flashloader)所在的路径Dloader在USB下载过程中被ROM下载到IRAM中运行,Dloader完成与PC机的通讯,下载Normal/Backup/Third Try BootPackage 与SFS等。 Flashloader在JTAG/SWD下载过程中被工具加载到IRAM中,工具调用其中的函数下载Normal/Backup/Third Try Boot Package与SFS等 |
--preload | 为所需下载的BootPackage以及SFS、RFD对应的固件路径。SFS用于Flash启动,RFD文件用于加密启动。 |
--image 0x140000 | 将现有的bin文件打包到PAC包,0x140000为用户自行设置的bin文件下载到的地址(切记不能与SFS文件分配地址重叠)。 |
1.5.3 命令行打包举例
1.5.3.1 ssdk\boards\e3_gateway\app_demo\boot_core 打包
由于 SSDK 采用 AMP 软件架构提供的 Demo 工程,故使用命令行打包时,可以将多个核的 bin 文件根据运行内核的不同签名到一个 BootPackage 中。
bin 文件签名形成 Boot Package
给 Dloader bin 文件进行签名
生成 PAC 包
运行结果
Memory 内存数据
RAM 空间的数据由 ROM 搬运至不同的加载地址至,数据如下图:
SDToolBox 下载 PAC 包时,按照 BootPackage 打包时不同的 DLC 参数,将不同核的镜像下载到不同的Flash 地址,具体计算方式见 1.1.1 章节,Flash 内部存储数据如下图。
根据该命令行打包参数,内存映射图如下
1.5.3.2 ssdk\boards\e3_gateway\app_demo\multicore-xip 打包
multicore-xip Demo 采用 XIP 模式,分为 Bootloader 与 APP 应用,上电 ROM 需要验签 Bootloader,故将 Bootloader bin 文件进行签名,将 APP 应用追加至 PAC 包内。
bin 文件签名形成 Boot Package
生成 PAC 包
运行结果:
1.5.3.3 ssdk\boards\e3_gateway\driver_demo\gpio 分别打包成 3 个 Boot Package
bin 文件签名形成 Boot Package
SFS 文件生成
Dloader 文件签名
打包成 PAC 包
memory 内存数据如下图:
Normal BootPackage Flash 存储地址
Backup Bootloader Flash 存储地址
Third Boot Package Flash 存储地址
1.6 Python 文件自动打包
Python 脚本打包,SemiDrive 提供的 SSDK 中包含自动打包脚本 tools/genpac.py , genpac.py 可以解析项目的打包配置文件 pac_config.json 进行打包,可以一键完成:
- 将编译产物 binary 合成 BootPackage;
- 选择 SFS 的配置文件,将配置文件转换为 img 用于打包,同时能够指定 Boot Package 的地址;
- 选择打包 Dloader 或 Flashloader,对 Dloader 进行签名,Flashloader 不签名;
- 可以进行加密配置;
- 形成 SDFactoryTool 软件烧录所需的 PAC 文件;Python脚本自动打包有两种方式,区别如下表所示。
方式 | 特点 |
传入多个参数指定 SSDK demo 进行打包 | 根据参数自动匹配 demo 的 binary、Downloader 的默认路径。仅适用于非 XIP 类的 demo。 |
传入打包配置文件的路径名作为参数进行打包 | Demo 的 binary 的路径在打包配置文件中指定。Downloader的路径在打包配置文件中指定。可适用于所有demo。 注意:XIP类demo必须使用此种方式进行打包 |
1.6.1 指定 SSDK Demo 打包
在 SSDK 根目录执行 CMD 指令,输入以下指令:
1.6.2 指定打包配置文件打包
SSDK可以直接指定某个 pac_config.json进行打包,前提是该pac_config.json配置文件直接指定了打包所需文件的路径。这种 pac_config.json 文件的示例存放在 ssdk\tools\genpac\pac_config.json 路径下,该文件中指定了打包所需的文件的路径:
用户可以修改为自己的编译产物以及所使用的 Downloader的绝对路径;在 SSDK 目录下执行 CMD ,并输入如下所示的指令,打包配置文件解析参见《AppNote_E3_Boot_and_OTA_Rev01.06》9.1.2 章节。
三、 参考文档
《AppNote_E3_Boot_and_OTA_Rev01.06》
《AppNote_E3_烧录流程_Rev2.0》
欢迎在博文下方留言评论,我们会及时回复您的问题。如有更多需求,欢迎联系大联大世平集团 ATU 部门:atu.sh@wpi-group.com
作者:Linna Wang / 王丽娜