Flash 布局与配置

概述

本章介绍默认 Flash 存储布局及自定义修改方法。

SDK 默认采用如下图所示的 Flash 布局（以 8MB Flash 芯片为例），其中引导清单（boot manifest）的起始地址固定为 0x0800_0000，其他区域的起始地址支持灵活配置。

../../../_images/flash_layout_dplus.svg

Item

物理地址

大小 (KB)

描述

KM4 Bootloader manifest

0x0800_0000

4

KM4 启动加载程序 manifest

KM4 Bootloader

0x0800_1000

76

KM4 启动加载程序（代码/数据），包含 KM4 启动加载程序 IMG，映射到虚拟地址 0x0F80_0000。

Key Certificate

0x0801_4000

4

其他固件的公钥哈希信息

IMG2 manifest

0x0801_5000

4

KM0 & KM4 应用程序 & KM4 IMG3 manifest

KM0 & KM4 Application

0x0801_6000

1912

结合 KM0 固件、KM4 固件2 和 KM4 固件3（如果存在）

  • KM0_IMG: KM0 固件（代码/数据），映射到虚拟地址 0x0C00_0000。

  • KM4_IMG2: KM4 非安全固件（代码/数据），映射到虚拟地址 0x0E00_0000。

  • KM4_IMG3: 安全固件（代码/数据）

KM4 Bootloader manifest OTA2

0x0820_0000

4

KM4 启动加载程序清单

KM4 Bootloader OTA2

0x0820_1000

76

KM4 启动加载程序（代码/数据），包含 KM4 启动加载程序 IMG，映射到虚拟地址 0x0F80_0000。

Key Certificate OTA2

0x0821_4000

4

其他固件的公钥哈希信息

IMG2 manifest OTA2

0x0821_5000

4

KM0 & KM4 应用程序 & KM4 IMG3 清单

KM0 & KM4 Application OTA2

0x0821_6000

1820

结合 KM0 固件、KM4 固件2 和 KM4 固件3（如果存在）

  • KM0_IMG: KM0 固件（代码/数据），映射到虚拟地址 0x0C00_0000。

  • KM4_IMG2: KM4 非安全固件（代码/数据），映射到虚拟地址 0x0E00_0000。

  • KM4_IMG3: 安全固件（代码/数据）

FTL

0x083D_D000

12

用于蓝牙

VFS

0x083E_0000

128

用于文件系统

内存管理单元（MMU）

为实现固件灵活性和 RSIP 加密需求（固件加密需要固定 IV 地址，参考 RSIP ），SDK 默认启用 Flash MMU 机制。通过 MMU ，同一块逻辑地址可以映射到 OTA1 物理区域，也可以映射到 OTA2 物理区域，这样设备可以选择运行不同分区中的固件。在未启用 OTA 升级时，固件默认烧录到 OTA1 区域。关于 OTA 的更多信息，请参考 固件升级 章节。

默认 MMU 布局如下：

备注

一般不需要修改 Flash 的逻辑地址，如需修改请联系 Realtek。

Flash 布局修改

可以修改物理地址到逻辑地址的映射改变 Flash 的布局，除 IMG_BOOT 外，其他项都支持修改，在 {SDK}\component\soc\usrcfg\amebaxxx\ameba_flashcfg.c 中修改对应条目即可：

FlashLayoutInfo_TypeDef Flash_Layout[] = {
   /*Region_Type,   [StartAddr,   EndAddr]      */
   {IMG_BOOT,      0x08000000, 0x08013FFF}, //Boot Manifest(4K) + KM4 Bootloader(76K)
   //Users should modify below according to their own memory
   {IMG_APP_OTA1,  0x08014000, 0x081F3FFF}, //Certificate(4K) + Manifest(4K) + KR4 & KM4 Application OTA1 + Manifest(4K) + RDP IMG OTA1

   {IMG_BOOT_OTA2, 0x08200000, 0x08213FFF}, //Boot Manifest(4K) + KM4 Bootloader(76K) OTA
   {IMG_APP_OTA2,  0x08214000, 0x083DCFFF}, //Certificate(4K) + Manifest(4K) + KR4 & KM4 Application OTA2 + Manifest(4K) + RDP IMG OTA2
   {FTL,           0x083DD000, 0x083DFFFF}, //FTL for BT(>=12K), The start offset of flash pages allocated to FTL physical map
   {VFS1,          0x083E0000, 0x083FFFFF}, //VFS region 1 (128K)
   {IMG_DSP,       0x08400000, 0x086FFFFF}, //Manifest(4K) + DSP firmware, only one DSP region in layout
   {VFS2,          0xFFFFFFFF, 0xFFFFFFFF}, //VFS region 2
   {USER,          0xFFFFFFFF, 0xFFFFFFFF}, //reserve for user

   /* End */
   {0xFF,          0xFFFFFFFF, 0xFFFFFFFF},
};

备注

  • 以上代码为示例，实际使用的 IC 可能不包含所有配置行，具体请参考对应 IC 的 Flash_Layout。

  • 如果修改了 VFS 或 FTL 分区，建议通过 ImageTool 工具对相关区域进行擦除，避免新旧数据冲突或干扰。

  • 修改地址要保证相邻条目之间没有交叠。

修改 Bootloader OTA2 分区

BOOT 和 APP 固件均有两个固件分区（ OTA1 和 OTA2 ）用于冗余存储和版本控制，但 BOOT 固件的 OTA 功能默认未开启，请参考 BOOT OTA 中的步骤启用此功能。

如需规划和修改 Bootloader OTA2 分区，请修改 {SDK}\component\soc\usrcfg\amebaxxx\ameba_flashcfg.c 文件中的 IMG_BOOT_OTA2 地址，注意保证 4K 对齐。

备注

  • Bootloader OTA1 的地址固定为 0x0800_0000，无法修改。

  • 芯片 ROM 中的引导程序将根据 BOOT 固件头中的标签和版本号选择启动哪个分区，默认将选择版本号更大的分区，更新固件版本号的方法请参考 固件标签和版本号 。

修改应用程序分区

APP OTA1

  1. 在 {SDK}\component\soc\usrcfg\amebaxxx\ameba_flashcfg.c 中修改 IMG_APP_OTA1 的地址。

  2. 重新编译项目以生成 Bootloader 和 APP OTA1。

  3. IMG_APP_OTA1 的起始和结束地址对应 ImageTool 中 km0_km4_app.bin 的 Start Addr, End Addr，表示应用固件烧录的位置。如果 IMG_APP_OTA1 有调整，请同步修改 ImageTool 中的对应项并下载新的 Bootloader 和 APP OTA1。

    ../../../_images/app_ota1_step3_dplus.png

Bootloader 将根据 APP 固件头中的标签和版本号选择启动哪个分区，如果 APP OTA1 的版本号更大，Bootloader 从 APP OTA1 的新位置加载固件。

APP OTA2

  1. 在 {SDK}\component\soc\usrcfg\amebaxxx\ameba_flashcfg.c 中修改 IMG_APP_OTA2 的地址。

  2. 按照 APP OTA1 中的步骤重新编译并下载 Bootloader 固件。

通过 OTA 的方式将 APP OTA2 下载到闪存后，如果 APP OTA2 的版本更大，Bootloader 将从 APP OTA2 的新位置加载固件。

Flash 写保护机制

Bootloader 在加载 APP 固件前会读取 Flash 状态寄存器：

  • 若寄存器值与 Flash_AVL （路径： {SDK}\component\soc\usrcfg\amebaxxx\ameba_flashcfg.c）中的 status_mask 按位与操作后仅设置 QE 位，则保持原状态

  • 其他情况会将按位与结果写入状态寄存器

/**
* @brif Flash_AVL maintains the flash IC supported by SDK.
*    If users want to adpot new flash, add item in the following AVL.
*    Note that, if new flash can be classfied as one of the Realtek-defined categories according to Classification SPEC,
*    filling in the defined class index is necessary. Otherwise, FlashClassUser can be used to indicate new class.
*    If (Status Register of flash & status_mask in Flash_AVL) != (1 << QE Bit), set (1 << QE Bit) to Status Register of flash
*/
const FlashInfo_TypeDef Flash_AVL[] = {
   /*flash_id,               flash_id_mask,  flash_class,            status_mask,    FlashInitHandler */

   /* case1: Realtek defined class, any modification is not allowed */
   {0xEF,                    0x000000FF,             FlashClass1,            0x000043FC,             NULL},  /* Winbond: MANUFACTURER_ID_WINBOND */
   {0xA1,                    0x000000FF,             FlashClass1,            0x0000FFFC,             NULL},  /* Fudan Micro: MANUFACTURER_ID_FM */
   {0x0B,                    0x000000FF,             FlashClass1,            0x000043FC,             NULL},  /* XTX */
   {0x0E,                    0x000000FF,             FlashClass1,            0x000043FC,             NULL},  /* XTX(FT) */
   {0xC8,                    0x000000FF,             FlashClass2,            0x000043FC,             NULL},  /* GD normal: MANUFACTURER_ID_GD */
   {0x28C2,             0x0000FFFF,          FlashClass6,            0x000200FC,             NULL},  /* MXIC wide-range VCC: MANUFACTURER_ID_MXIC */
   {0xC2,                    0x000000FF,             FlashClass3,            0x000000FC,             NULL},  /* MXIC normal: MANUFACTURER_ID_BOHONG */
   {0x68,                    0x000000FF,             FlashClass3,            0x000000FC,             NULL},  /* Hua Hong */
   {0x51,                    0x000000FF,             FlashClass3,            0x000000FC,             NULL},  /* GD MD serial */
   {0x1C,                    0x000000FF,             FlashClass4,            0x000000FC,             NULL},  /* ESMT: MANUFACTURER_ID_EON */
   {0x20,                    0x000000FF,             FlashClass1,            0x000043FC,             NULL},  /* XMC: MANUFACTURER_ID_WINBOND */
   {0x85,                    0x000000FF,             FlashClass1,            0x000043FC,             NULL},  /* Puya: 85-20-16 */
   {0x5E,                    0x000000FF,             FlashClass1,            0x000043FC,             NULL},  /* Zbit: 5E-50-16 */
   //{0x20,                  0x000000FF,             FlashClass5,            0x000000FC,             NULL},  /* Micron: MANUFACTURER_ID_MICRON */

   /* case2: new flash, ID is not included in case1 list, but specification is compatible with FlashClass1~FlashClass6 */
   //{0xXX,                  0x0000XXXX,             FlashClassX,            0x0000XXXX,             NULL},

   /* case3: new flash, ID is not included in case1 list, and specification is not compatible with FlashClass1~FlashClass6 */
   {0x00,                    0x000000FF,             FlashClassUser,         0xFFFFFFFF,             &flash_init_userdef},

   /* End */
   {0xFF,                    0xFFFFFFFF,             FlashClassNone,         0xFFFFFFFF,             NULL},
};

备注

  • 默认设置 QE 位会解除所有块保护。如需保留块保护，需将 Flash_AVL 中对应型号的 status_mask 块保护位设为 0（例如 Winbond 芯片需设为 0x000043C0）

  • 建议用户对代码段，只读数据段等启用块保护。

  • 使用 LittleFS 时建议将 FTL 分区移至 Flash 末端的 64KB 区域，并设置对应的块保护位

  • OTA 升级期间需解除 Flash 保护，完成后重新启用保护

  • 部分 Flash 芯片无法单独保护末端区块，此时建议启用前半部分块保护