一、 概述

        本文介绍 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 芯片，需要完成以下步骤：

1. 将编译得到的各个 core 的可执行程序（bin文件）合并并签名，得到 Boot Package 文件，如下图打包过程 1；
2. 如启动设备为 Flash，则需要加载 SFS 文件，同时如果需要在 Flash 中加密启动，则需要再加载 RFD 文件，如果不需要加密启动，则 RFD 文件可以不存在；如果启动设备为 eMMC、SD 卡，则不需要 SFS 文件、 RFD 文件；如下图打包过程 2；
3. 将上述文件打包在一个 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 包括以下信息：

1. Boot Package 的签名信息
2. 各个镜像在 Image 组合中的相对位置（DLP)
3. 镜像加载地址（Load Address）
4. 镜像运行时的入口地址（Entry）
5. HASH 校验信息
6. PSN 信息

      程序镜像组合（Images）：多个 core 的用户程序镜像组合，包含：

1. CPU cluster0 镜像
2. CPU cluster1 程序镜像（可配置为 Split 或者 Lockstep）
3. CPU cluster2 程序镜像（可配置为 Split 或者 Lockstep）
4. Bootloader 镜像
5. 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 进行打包，可以一键完成：

1. 将编译产物 binary 合成 BootPackage；
2. 选择 SFS 的配置文件，将配置文件转换为 img 用于打包，同时能够指定 Boot Package 的地址；
3. 选择打包 Dloader 或 Flashloader，对 Dloader 进行签名，Flashloader 不签名；
4. 可以进行加密配置；
5. 形成 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 / 王丽娜

 
登录大大通，了解更多详情，解锁1500+完整应用方案，更有大联大700+FAE在线答疑解惑！