nand flash 分区故障 FLASH分区管理

发布时间 : 2024-11-24

作者 : 小编

访问数量 : 23

扫码分享至微信

FLASH分区管理

什么是分区管理

FLASH分区管理是怎么一回事呢？我们可以以个人电脑来做类比，我们的电脑通常都分有很多个盘符：

这些都是我们硬盘的分区，我这里装了两块硬盘，512GB的机械硬盘+128GB的固态硬盘，共分C~H六个分区，我这里的C盘和H盘是固态硬盘，其它盘符是机械硬盘：

分区是为了方便我们对我们的资料进行管理，各个分区互不影响，比如格式化某个分区只会删除这个分区的内容而不会影响其它分区及整个硬盘等。

同样的，在我们的STM32上也是可以进行分区管理的，这篇笔记我们来使用RT-Thread的FAL软件包来对我STM32片内FLASH及片外FLASH的分区管理。

FAL软件包介绍

FAL (Flash Abstraction Layer) Flash 抽象层，是 RT-Thread 的一个软件包，是对 Flash 及基于 Flash的分区进行管理、操作的抽象层，对上层统一了 Flash 及分区操作的 API ，并具有以下特性：

• 支持静态可配置的分区表，并可关联多个 Flash 设备；

• 分区表支持自动装载。避免在多固件项目，分区表被多次定义的问题；

• 代码精简，对操作系统无依赖，可运行于裸机平台，比如对资源有一定要求的 bootloader；

• 统一的操作接口。保证了文件系统、 OTA、 NVM 等对 Flash 有一定依赖的组件，底层 Flash 驱动的可重用性；

• 自带基于 Finsh/MSH 的测试命令，可以通过 Shell 按字节寻址的方式操作（读写擦） Flash 或分区，方便开发者进行调试、测试；

FAL软件包使用

本笔记主要对潘多拉开发板的FAL例程进行一次梳理，所以部分表述来自于教程文档。我们这个实验建立如下分区表：

1、移植接口文件说明

FAL软件包的目录如下，其中samples文件夹下为移植接口文件：

其中fal_cfg.h 为fal 配置文件（Flash 设备配置和分区表配置）：

fal 是 Flash 抽象层，要操作 Flash 设备必然要将 Flash 的读、写、擦接口对接到 fal 抽象层中。在 fal中，使用 struct fal_flash_dev 结构体来让用户注册该 Flash 设备的操作接口。fal_flash_dev 结构体定义如下所示：

fal_flash_stm32f2_port.c为片内FLASH接口文件，这得根据实际芯片进行修改，主要是封装读、写、擦除函数，例如：

这和我们之前分享的：使用STM32内部Flash额外的空间来存储数据步骤差不多。片内 Flash 对接说明：

Flash 设备名称为 onchip_flash，设备容量为 512K，最小擦除单元为 2K，无初始化接口。

fal_flash_sfud_port.c为片外FLASH接口文件，这使用SFUD 万能 SPI Flash 通用驱动库来驱动。片外 Nor Flash 对接说明：

Flash 设备名称为 nor_flash，设备容量为 16M，最小擦除单元为 4K。这里使用的 read、 write、 erase接口最终调用 SFUD 框架中的接口，无需用户进行驱动开发。

2、fal软件包API接口说明

这里主要列举出本实验需要用到的API说明，其它几个未用到的fal接口函数声明在fal.h文件中。

2.1 查找 Flash 设备

2.2 查找 Flash 分区

2.3 获取分区表

2.4 从分区读取数据

2.5 往分区写入数据

2.6 擦除分区数据

2.7 擦除整个分区数据

3、fal测试函数说明

移植完成后，调用 fal_init() 初始化该库。测试程序主函数：

对d分区与f分区进行读写测试。

（1）擦除分区测试：

擦除成功则分区内容会变成0xFF。

（2）读写测试

读出来的数据与写入的数据相等则测试成功。

程序运行结果：

使用SHELL命令测试FAL

为了方便用户验证 fal 功能是否正常，以及 Flash 驱动是否正确工作，分区表配置是否合理， RT-Thread为 fal 提供了一套测试命令：

1、探测命令

2、擦除命令

3、写数据命令

4、读数据命令

5、性能测试命令

性能测试将会测试 Flash 的擦除、写入及读取速度，同时将会测试写入及读取数据的准确性，保证整个 Flash 或整个分区的写入与读取数据的一致性。

注意事项：

• 如果要修改分区表，请正确配置起始地址和分区大小，不要有分区重叠。

• 在使用 fal 测试命令的时候，请先使用 fal probe 命令选择一个 Flash 分区。

以上就是本次的笔记分享，如有错误，欢迎指出！谢谢~

UFS深入浅出第二章 UFS结构第三节 UFS分区

Section 3 UFS partition

第三节 UFS分区

UFS partition concept is similar to that in eMMC. However, it is not exactly the same. In eMMC, the whole user area could be used immediately after initialization. If there are some dedicated purposes to store specific data, some area called General Purpose Partition (aka GPP) could be separated from user space with its own address memory space assigned. GPP number is up to 4 per eMMC specification. Besides that, there are two boots partition and one RPMB partition in eMMC when shipped out from factory. Either GPP, or Boot/RPMB need dedicated Switch Command CMD6 for accessing to their own independent memory space areas.

UFS分区的概念和eMMC相似。但是，又不完全一样。eMMC里面的整个用户区域可以在初始化之后立即使用。如果有特定的目的去存储一些专门的数据，那么可以从用户区域里面的分出一些分配了自己独立寻址空间的区域，称为通用目的区（也叫GPP）。根据eMMC的规范，GPP的数目最多是4个。除此之外出厂的时候在eMMC里还有两个boot分区以及一个RPMB分区。eMMC里不论是GPP，或者是Boot、RPMB，都需要特定的切换指令CMD6来访问它们自己的独立的寻址空间。

UFS partitions do not work that way. In UFS, partitions have a unique name Logical Unit (aka LU). Except one RPMB logical unit, no other Logical Units are assigned by default in UFS from factory，including boot partition. UFS memory space could not be accessed unless it has been separated into pieces with independent memory space and index assigned. Each piece is so called one Logical Unit, short as LU. The process of memory space allocation for each LU is called provisioning.

UFS的分区工作方式不太一样。在UFS里，分区有一个独特的名字逻辑单元（也叫LU）。除了一个RPMB之外，在UFS里包括boot分区在内，没有其他逻辑分区在出厂的时候就默认分配好的。UFS的存储空间在分成带有独立寻址空间和序列号的小块之前，是不能被访问的。每一个小块也就是一个逻辑单元，简写成LU。分配存储空间给每个LU的过程叫做配置（provisioning）。

The job that provisioning does is actually to create a scattered mapping table of memory space LBA for all LU. There are two types of provisioning defined by UFS specification, Full Provisioning and Thin Provisioning. Full Provisioning gives a 1:1 mapping for all physical memory with its corresponding LBA to LU. While Thin provisioning only assigned all LBAs to LUs. Compared to Full Provisioning, Thin provisioning is more flexible to use physical Flash memory so to reducing NAND overhead blocks and save cost. This is also the reason UFS command UNMAP, which is to delete Logical to Physical Address entry to free the dirty data blocks, is only supported in Thin Provisioning as Full Provisioning need to keep those dirty data blocks unless extra physical Flash blocks that are out of UFS exported capacity are provided to replace them. Nowadays, all UFS vendors has no doubt to choose Thin provisioning.

Provisioning的工作实际上是为所有的LU建立一个分散的存储空间LBA的映射表。UFS规范定义了两种Provisioning模式，完全的Full Provisioning以及廋Thin Provisioning。Full Provisioning给出了所有物理存储以及对应的LBA相对于LU的1:1对应关系。而Thin Provisioning只需要分配所有的LBA个LU。和Full Provisioning相比较，Thin Provisioning可以更加灵活的使用物理闪存，从而减少额外的NAND存储块以及减少成本。这也是为什么UFS的UNMAP命令只支持Thin Provisioning方式，UNMAP命令是通过删除逻辑物理地址映射入口来释放脏数据块。因为Full Provision除非有输出容量之外的额外的物理闪存块来替换那些脏数据块，否则就得一直留着它们。今日，所有的UFS厂商都毫无意外的选择Thin Provisioning。

The index assigned is the number of the LU. Hence Logical Unit Number (aka LUN) is used in UFS protocol to address the specific LU. Generally, there are up to 32 LU in UFS, however the real number could be much less than that based on the real storage usage design.

分配给LU的索引是数字号码，所以逻辑单元号（也叫LUN）就被用在UFS协议里面作为定位特定的LU。一般来说，UFS最多有32个LU，然而实际的数目根据实际存储使用的设计可能远小于这个数字。

UFS also inherit the concept of Well-Known Logical Unit (aka W-LU) from SCSI. There are total 4 W-LU in UFS, Device and Report LUN are two W-LU which have the same definition as that in SCSI, while Boot and RPMB are two W-LU which are newly added to implement and comply with eMMC feature. Each W-LU get its fixed number called Well-known Logical Unit Number (aka W-LUN). The fixed number is the reason that these 4 W-LU are well known. Here we only need to remember that 0xB0 is for Boot and 0xC4 is for RPMB.

UFS还集成了源自于SCSI的概念，众所周知的逻辑单元（也叫 W-LU）。UFS里一共有4个W-LU，Device和Report LUN是和SCSI定义一样的概念的W-LU。而Boot和RPMB是新加入的为了实现以及于eMMC特性保持一致的W-LU。每一个W-LU有固定的众所周知的逻辑单元码, 也就是众所周知的逻辑单元码（也叫W-LUN）。这些固定的数字码也是为什么这四个W-LU众所周知的原因。这里我们只需要记住Boot是0xB0以及RPMB是0xC4。

Boot W-LU density is part of the exported capacity of UFS, and size could be assigned up to 64MB each. This is not like eMMC. In eMMC, two boot partitions density is not counted in the exported capacity and usually is fixed for each, like 4MB. This feature gives UFS more flexibility to fit increasing demand of OS boot size requirement. Another notice for Boot W-LUs is, although it has fixed W-LUN 0xB4, it cannot be accessed until it is linked to a certain LU during the provisioning process by setting the UFS register Descriptor. RPMB W-LU is originated and does not have this limitation, W-LUN is 0xC4, which could be accessed directly. The detail will be covered in the UFS register chapter.

Boot W-LU的容量是包含在UFS的输出容量里的，大小可最大分配到64MB。这个和eMMC不一样，在eMMC里，两个Boot分区的容量是不算在输出容量里的，而且大小通常是固定的，比如说4MB。这个特性也给了UFS更多的灵活性来适应操作系统对于Boot分区尺寸逐渐增加的需求。另外一个Boot W-LU需要注意的点是，虽然它有固定的W-LUN 0xB0，但是在通过UFS寄存器设置做Provisioning把它链接到某个LU之前，它是不能访问的。 RPMB W-LU是原生的，没有这个限制，W-LUN是0xC4，直接就可以访问。具体的细节我们会在UFS寄存器的章节里讲。

FLASH分区管理

什么是分区管理

FAL软件包介绍

FAL软件包使用

使用SHELL命令测试FAL

UFS深入浅出第二章 UFS结构第三节 UFS分区

Section 3 UFS partition

第三节 UFS分区

关于我们

产品中心

服务与支持

FLASH分区管理

什么是分区管理

FAL软件包介绍

FAL软件包使用

使用SHELL命令测试FAL

UFS深入浅出 第二章 UFS结构 第三节 UFS分区

Section 3 UFS partition

第三节 UFS分区

关于我们

产品中心

服务与支持

UFS深入浅出第二章 UFS结构第三节 UFS分区