Tina Linux存储开发指南

Tina Linux 存储开发指南

1 概述

1.1 编写目的

介绍TinaLinux Flash，分区，文件系统等存储相关信息，指导方案的开发定制。

1.2 适用范围

Tina V3.0 及其后续版本。

1.3 相关人员

适用于TinaLinux 平台的客户及相关技术人员。

2 分区管理

2.1 分区配置文件

在全志平台中，通过sys_partition.fex 文件配置分区。在Tina 中，可以在lunch 选择方案后，通过命令cconfigs 快速跳转到分区配置目录，通常情况下，其路径如下。

tina/device/config/chips/<芯片编号>/configs/<方案名>/linux/sys_partition.fex

tina/device/config/chips/<芯片编号>/configs/<方案名>/linux/sys_partition_nor.fex

#以上路径不存在，则使用

tina/device/config/chips/<芯片编号>/configs/<方案名>/sys_partition.fex

​

说明 sys_partition_nor.fex 适用于nor。 sys_partition.fex 适用于rawnand/spinand/mmc。

2.2 分区配置格式

以rootfs 分区为例：

[partition]

name = rootfs

size = 20480

downloadfile = "rootfs.fex"

user_type = 0x8000

每个分区以[partition] 标识，分区属性及其意义如下表。

属性	含义	必选	备注
name	分区名	Y
size	分区大小	Y	单位：扇区（512B），注1
downlodefile	分区烧入的镜像文件	N	注2
verify	量产后校验标识	N	(默认)1：使能；0:禁用，注3
user_type	分区属性	N	注 4
keydata	量产时是否擦除本分区	N	0x8000：使用;其他无效

说明：

最后一个分区(UDISK)，不设置size，表示分配所有剩余空间。

downloadfile 支持绝对路径和相对路径，相对于tina/out/<方案名>/image。

verify 决定是否校验downloadfile 中指定的镜像，若为ext4 稀疏镜像，务必禁用。

历史遗留，目前只对UBI 方案有效。bit0为1 时，表示创建静态卷，反之为动态卷。

创建downloadfile 的资源镜像包看章节分区资源镜像文件。 [partition] 标识用户空间的逻辑分区，在UBI 方案中，表现为UBI 卷。此外，在sys_partiton.fex中存在特殊的配置MBR，用于配置MBR 空间大小，此配置在UBI 方案中无效。例如：

[mbr]

size = 2048

MBR 分区以Kbyte 为单位，对用户不可见，属于隐藏空间，其大小也必须满足对齐原则。

警告 一般情况下，不建议用户修改mbr 分区的大小。

2.3 常见分区及其用途

分区名	用途	大小	备注
boot	内核镜像分区	比实际镜像等大或稍大即可
rootfs	根文件系统镜像	比实际镜像等大或稍大即可
extend	扩展系统镜像	参考OTA 文档	参考OTA 文档仅小容量OTA 方案使用
recovery	恢复系统镜像	参考OTA 文档	仅限大容量OTA 方案使用
private	存储SN、MAC 等数据	使用默认大小即可	量产时默认不丢失
misc	存储系统状态、刷机状态	使用默认大小即可
env	存放Uboot 使用的数据	使用默认大小即可
pstore	内核奔溃日志转存分区	使用默认大小即可
rootfs_data	根目录覆盖分区	根据需求配置	注1
UDISK	用户数据分区	不需要配置大小	注2

说明：

rootfs_data 分区通过overlayfs 覆盖根文件系统，以支持squashfs 根文件系统的可写，此时对根文件系统写入的数 据实际是保存到rootfs_data 分区，因此rootfs_data 分区的容量标识着根文件系统最大可写数据量。

UDISK 作为最后一个分区，不需要设置size，表示分配剩余所有空间给UDISK。

2.4 分区大小与对齐

分区大小的对齐要求与不同介质(nor/nand/mmc)、不同存储方案相关。不按对齐要求配置，可能出现文件系统异常，分区边界数据丢失等现象。对齐规则如下表。

介质	对齐大小	备注
nor	64K	对齐物理擦除块大小，注1
(nftl) spinand	驱动超级块大小	注2
(ubi) spinand	2 × 物理块- 2 × 页	注3
rawnand	驱动超级块大小	与物料相关，16M 对齐可基本兼容
emmc	16M	与物料相关，16M 对齐可基本兼容

说明

nor 的擦除块常见为64K，即在sys_partition_nor.fex 中分区size 进行128 对齐。在id 表配置为4K 擦除且使能内核CONFIG_MTD_SPI_NOR_USE_4K_SECTORS 时，也可使用4K 对齐。推荐使用默认64K 对齐。

在常见的128M Spi Nand 中，为256K 对齐，即在sys_partition.fex 中分区size 进行512 对齐。

在常见的128M Spi Nand 中，需要和逻辑擦除块（super block）对齐，1 个super block 包含两个物理擦除块，常见的物理擦除块128K，1 个逻辑的超级块为256K，但是需要使用每个物理块的第一个page（2K）来作为ubi 所需的信息头部，所以实际的为（256k-2*2k），为252K 对齐，即在sys_partition.fex 中分区size 进行504 对齐。

警告 如果分区不对齐，可能会出现以下情况。 • nor/rawnand/spinand 可能会导致数据丢失。 • mmc 不会造成数据丢失，但可能导致性能损失。

如果分区使用ubifs 文件系统，分区最小为5M ，否则大概率提示空间不够。 如果分区使用ext4 文件系统，分区最小为3M ，否则无法形成日志，会有掉电变砖风险。

技巧

在ext4 与日志章节有描述判断创建的ext4 文件系统是否支持日志的方法。

在分区资源镜像文件章节指导如何创建带文件系统的资源镜像、分区大小、文件系统大小、文件大小更多内容，请参考总容量说明。

2.5 分区与文件系统

常见的分区与文件系统对应关系如下表。

分区名	默认文件系统	文件系统特性	备注
rootfs	squashfs	压缩、只读	为了安全，根文件系统建议只读
rootfs_data	jffs2/ext4/ubifs	可写	注1
UIDSK	jffs2/ext4/ubifs	可写	注1
boot	vfat		裸数据分区，部分方案为vfat
private	vfat		注2
misc	none		裸数据分区
env	none		裸数据分区
pstore	pstore		转存奔溃日志

说明

可写的分区，nor 为jffs2；UBI 方案为ubifs；其他为ext4。

private 默认为裸数据，使用dragonSN 工具烧录后会成为vfat 文件系统。

只读文件系统推荐使用squashfs。可写文件系统，nor 推荐jffs2，UBI 方案推荐ubifs，其他推荐ext4。更多文件系统信息，请参考文件系统支持情况。

2.6 分区资源镜像文件

在sys_partition.fex中通过downloadfile 指定需要烧录到分区的资源镜像文件。大多数情况下，资源镜像文件都构建在文件系统上，通过某些命令实现把系统需要的文件，例如音频文件、视频文件等资源，打包成一个带文件系统的镜像包，并在烧录时把镜像包烧写入存储 介质。 创建不同文件系统镜像的命令不一样，常见有以下几种：

文件系统	创建镜像命令
vfat	mkfs.vfat
ext4	make_ext4fs
ubifs	mkfs.ubifs
squashfs	mksquashfs4

为了最大程度利用空间，一般会使文件系统等于物理分区大小，即创建文件系统时使用分区表划定的分区大小来创建。

如果不希望硬编码大小，则可在打包时从分区表获得大小，再传给文件系统创建工具，具体的实现可以参考tina/scripts/pack_img.sh 中的make_data_res() 和make_user_res() 等函数。

2.6.1 创建squashfs 镜像

生成squashfs 的命令，可参考编译过程的log 得到，或者在网上搜索squashfs 生成方式。 例如在scripts/pack_img.sh 中定义一个函数

function make_user_squash()

{

local SOURCE_DATE_EPOCH=$(${PACK_TOPDIR}/scripts/get_source_date_epoch.sh)

# 这一行指定要打包到文件系统的数据

local USER_PART_FILE_PATH=${PACK_TOPDIR}/target/allwinner/方案名字/user_sq

local USER_PART_SQUASHFS=${PACK_TOPDIR}/out/${PACK_BOARD}/image/user_sq.squashfs

local USER_PART_DOWNLOAD_FILE=${PACK_TOPDIR}/out/${PACK_BOARD}/image/user_sq.fex

cd ${ROOT_DIR}/image

[ -e $USER_PART_FILE_PATH ] && {

#这里用了gzip，需要更高压缩率可改成xz

${PACK_TOPDIR}/out/host/bin/mksquashfs4 $USER_PART_FILE_PATH $USER_PART_SQUASHFS

-noappend -root-owned -comp gzip -b 256k

-processors 1 -fixed-time $SOURCE_DATE_EPOCH

dd if=${USER_PART_SQUASHFS} of=${USER_PART_DOWNLOAD_FILE} bs=128k conv=sync

}

cd -

}

找个地方调用下即可。 这里不用传入分区表的原因是，制作squashfs 不需要指定文件系统大小，只读的文件系统大小完全取决于文件内容。

2.6.2 创建vfat 镜像

mkfs.vfat <输出镜像> -C <文件系统大小>

mcopy -s -v -i <输出镜像> <资源文件所在文件夹>/* ::

可参考pack_img.sh（在其中搜索mkfs.vfat 找到相关代码）。

2.6.3 创建ext4 镜像

使用tina/out/host/bin/make_ext4fs 创建ext4 镜像，推荐的使用方法如下:

make_ext4fs -l <文件系统大小> -b <块大小> -m 0 -j <日志块个数> <输出的镜像保存路径> <资源文件所在文件

夹>

其中， • -m 0: 表示不需要要为root 保留空间。 • -j < 日志块个数>: 日志总大小为块大小* 日志块个数。

例如：

make_ext4fs -l 20m -b 1024 -m 0 -j 1024 ${ROOT_DIR}/img/data.fex ${FILE_PATH}

如果空间不够大，会显示类似如下的错误日志：

$ ./bin/make_ext4fs -l 10m -b 1024 -m 0 -j 1024 data.fex ./bin

Creating filesystem with parameters:

Size: 10485760

Block size: 1024

Blocks per group: 8192

Inodes per group: 1280

Inode size: 256

Journal blocks: 1024

Label:

Blocks: 10240

Block groups: 2

Reserved blocks: 0

Reserved block group size: 63

error: ext4_allocate_best_fit_partial: failed to allocate 7483 blocks, out of space?

上述错误中，资源文件达到100+M，但是创建的镜像-l 指定的大小只有10M，导致空间不够而报错。只需要扩大镜像大小即可。 如需使用分区大小作为文件系统大小，可参考pack_img.sh（在其中搜索make_ext4fs 找到相关代码）。

技巧 镜像大小可以根据分区大小设置，也可以根据资源大小设置，后通过稀疏和resize 处理，即可保证最短烧录时间和动态匹配分区大小。见稀疏ext4 镜像和动态resize 章节。

2.6.3.1 稀疏ext4 镜像

如果资源文件只有10M，但创建了100M 的镜像文件，导致烧录100M 的文件拖慢了烧录速度。此时可以采用稀疏ext4 镜像。

tina/out/host/bin/img2simg <原镜像> <输出镜像>

稀疏镜像的原理，类似与把文件系统没用到的无效数据全删掉，把文件系统压缩。可参考pack_img.sh 中的函数sparse_ext4() 的实现与运用。

2.6.3.2 动态resize

如果担心创建镜像时指定的大小与实际的分区大小不匹配，可以在设备启动后执行resize2fs 动态调整文件系统的大小。 例如:

resize2fs /dev/by-name/UDISK

命令后不指定大小，则默认为分区大小。通过这方法可以让打包镜像创建的文件系统大小匹配分区大小。 此命令可直接写入启动脚本，在挂载前执行。每次启动都执行一遍不会有不良影响。

2.6.4 创建ubifs 镜像

使用tina/out/host/bin/make.ubifs 创建ubifs 镜像，推荐的使用方法如下:

mkfs.ubifs -x <压缩方式> -b <超级页大小> -e <逻辑擦除块大小> -c <最大逻辑擦除块个数> -r <资源文件所在 文件夹> -o <输出的镜像保存路径> 压缩方式可选none lzo zlib, 压缩率zlib > lzo > none 对常见的128MB spinand，1 page = 2048 bytes, 1 block = 64 page, 则 超级页大小为2048 * 2 = 4096 逻辑擦除块大小为2048 * 2 * 64 = 262144 最大逻辑擦除块个数，可简单设置为一个较大的值，例如128MB / ( 2048 bytes * 2 * 64) = 512 则最终的命令为: mkfs.ubifs -x zlib -b 4096 -e 262144 -c 512 -r ${FILE_PATH} -o ${ROOT_DIR}/img/data_ubifs. fex

2.7 根文件系统改用ubifs

使用suqashfs + overlayfs(ubifs) 方案实现根目录可写，但是ubifs 会占用大量的空间存放元数据，造成空间浪费。理论上，UBIFS 可直接作为根文件系统，其稳定性和可压缩性足够保证安全和提高空间利用率。

警告 请谨慎使用，UBIFS 作为根文件系统只是理论安全，全志暂无量产方案佐证。

修改步骤如下：

执行cdevice ，修改跳转目录下的Makefile 在FEATURES 变量中添加ubifs 和nand

执行make menuconfig 使能在Target Image 页面下使能ubifs 在Utilities->mtdutils 页面中使能mtd-utils-mkfs.ubifs

执行cconfigs ，修改跳转目录下的env-XXX.cfg 把rootfstype 值改为ubifs 在对应 存储介质的setargs_XXX 的root 值改为root=ubi0_X ，其中X 表示对应的第几个分区；删除 ubi.block 项。

执行make kernel_menuconfig，取消使能overlayfs

在sys_partition.fex 中删除rootfs_data 分区

2.8 总容量说明

在全志的驱动中，会预留一部分空间存储特殊数据，因此提供给用户分区空间不等于实际Flash总容量。

分区表可用空间= flash总容量- 保留空间

不同存储介质，其保留空间会有差异。

存储介质	保留空间	备注
nor	512K	对应bootloader 分区，包含分区表，boot0，uboot
(nftl) nand	总容量的1/10~1/8	注1，注2
(UBI) spinand
mmc	20M	包含boot0，uboot 等

最新spinor 的存储分布, 隐藏空间1MB，其中mbr 占用16KB，mbr 往前共占用1008KB，uboot 往前共占用64KB，其中包括boot0 和uboot 中间4KB 的预留区域，这段区域用于存放flash 的spi 采样点等信息。

|boot0|4kb|uboot|mbr |分区表可见的用户分区|

说明

(nftl) nand 的隐藏空间对用户不可见，包含分区表MBR 分区，boot0，uboot, 磨损算法、坏块保留等。对128M 的 spinand 来说，用户可用空间一般为108M。

由于出厂坏块的存在，可能会导致每一颗Flash 呈现的用户可用总容量不同，但全志(nftl) nand 保证总容量不会随着使 用过程出现坏块而导致可用容量减少。

UBI 方案中，除了必要的mtd 物理分区之外(boot0/uboot/pstore 等)，其余空间划分到一个mtd 物理分区。在此 mtd 物理分区中根据sys_partition.fex 的划分构建ubi 卷。UBI 的机制，每个块都需要预留1~2 个页作为EC/VID 头。因此可用容量会小于mtd 物理分区容量。

对于非ubi 方案，用户空间可通过下面的命令查看用户可用分区大小，大小单位为KB。

# cat /proc/partitions major minor #blocks name 93 0 112384 nand0 93 1 256 nand0p1 93 2 5120 nand0p2 93 3 10240 nand0p3 93 4 10240 nand0p4 93 5 7168 nand0p5 93 6 64 nand0p6 93 7 512 nand0p7 93 8 256 nand0p8 93 9 76463 nand0p9

如例子中的结果，nand0 分为多个分区，每个nand0px 对应一个分区表中的分区。对于ubi 方案，整个nand 分为若干mtd。可使用以下命令查看

# cat /proc/mtd dev: size erasesize name mtd0: 00100000 00040000 "boot0" mtd1: 00300000 00040000 "uboot" mtd2: 00100000 00040000 "secure_storage" mtd3: 00080000 00040000 "pstore" mtd4: 07a80000 00040000 "sys"

如例子中的结果，整个nand 分为5 个mtd。 • mtd0 存放boot0, size 1 MB • mtd1 存放uboot, size 3 MB • mtd2 存放secure_storage, size 1 MB • mtd3 存放pstore, size 512 KB • mtd4 则会进一步分为多个ubi 卷，占用剩余所有空间

以上所有mtd 的size 相加，应该恰好等于flash 总size。分区表中定义的每个逻辑分区，会对应mtd sys 上的ubi 卷。可使用以下命令查看

# ubinfo -a UBI version: 1 Count of UBI devices: 1 UBI control device major/minor: 10:51 Present UBI devices: ubi0 ubi0 Volumes count: 12 Logical eraseblock size: 258048 bytes, 252.0 KiB Total amount of logical eraseblocks: 489 (126185472 bytes, 120.3 MiB) Amount of available logical eraseblocks: 0 (0 bytes) Maximum count of volumes 128 Count of bad physical eraseblocks: 1 Count of reserved physical eraseblocks: 19 Current maximum erase counter value: 3 Minimum input/output unit size: 4096 bytes Character device major/minor: 247:0 Present volumes: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 Volume ID: 0 (on ubi0) Type: static Alignment: 1 Size: 1 LEBs (258048 bytes, 252.0 KiB) Data bytes: 258048 bytes (252.0 KiB) State: OK Name: mbr Character device major/minor: 247:1 ----------------------------------- Volume ID: 1 (on ubi0) Type: dynamic Alignment: 1 Size: 2 LEBs (516096 bytes, 504.0 KiB) State: OK Name: boot-resource Character device major/minor: 247:2 ----------------------------------- ... #此处省略若干卷 ----------------------------------- Volume ID: 11 (on ubi0) Type: dynamic Alignment: 1 Size: 242 LEBs (62447616 bytes, 59.6 MiB) State: OK Name: UDISK Character device major/minor: 247:12

如例子中的结果 • volume 0 为mbr, 占1 LEBs(252 KB)，对应分区表本身 • volume 1 为boot-resource, 占2 LEBs(504 KB)，对应分区表中第一个分区 • … • volume 11 为UDISK, 占242 LEBs(59.8 MB)，对应分区表中最后一个分区 常见的关于容量的疑惑与解答。

问：df 查看UDISK 分区大小，明明分区有50M，怎么显示总大小只有40+M？ 答：df 显示的是文件系统的大小，文件系统本身需要额外的空间存储元数据，导致实际可用空间 会比分区大小略少。

问：df 查看boot 分区大小，为什么显示的大小比实际分区大？ 答：boot 分区是通过镜像烧写的形式格式化的fs，创建镜像时设置的文件系统的大小并不等于分 区实际大小，导致此时文件系统大小并不能体现实际分区大小。

问：df 查看squashfs 使用率总是100%？ 答：squashfs 是只读压缩文件系统，文件系统大小取决于总文件大小，使用率总是100%，跟分 区大小无关。

说明

文件大小 我们常说的文件大小，指的是文件内容有多少字节。但在一个文件系统中，空间分配以块为单位，必然会造成内部碎片。假 设块为4K，如果文件大小为1K，文件系统依然为其分配4K 的块，就会造成3K 的空间浪费。

文件系统大小 文件系统大小，指的是文件系统元数据中标识的可用大小。形象来说，是df 命令或者statfs() 函数反馈的大小。文件系 统大小不一定等于分区大小，既可大于分区大小，也可小于分区大小。

分区大小 在划分分区时规定的大小，往往是sys_partition.fex 中指定的大小。

2.9 特殊隐藏空间

不管是nor，nand 还是mmc，都需要一些隐藏空间存储特殊数据，例如boot0/uboot/dtb/sys_config。用户无法使用这些隐藏空间。 此外，nand 驱动还需要额外的空间以实现磨损平衡、坏块管理算法，因此nand 的隐藏空间更大。

隐藏空间大小见总容量说明。

3 系统挂载

Tina 目前支持两种启动方式，分别是busybox 和procd，不同启动方式，其自动挂载的配置不同。 此处的自动挂载指开机冷挂载以及热插拔挂载，其中冷挂载指启动时挂载，热挂载指TF/U 盘等插拔设备时的挂载。

3.1 块设备节点

Tina 中设备节点都在/dev 目录下，对于不同存储介质，生成的设备节点会不一样。

存储	介质设备	节点备注
nand	/dev/nand{a,b,c…}	MBR 分区表
nand	/dev/nand0p{1,2,3…}	GPT 分区表
mmc	/dev/mmcblk0p{1,2,3…}
nor	/dev/mtdblock{0,1,2…}
TF	卡/dev/mmcblk{0,1}p{1,2…}	注1
U 盘	/dev/sda{1,2…}
SATA	硬盘/dev/sda{1,2…}

说明

若使用mmc 做内部存储介质，由于mmc 占用了mmcblk0的设备名，此时TF 卡的设备名序号递增为mmcblk1，否则生 成mmcblk0的设备名。因此配置fstab 时尤其注意TF 设备名是否正确。 对sys_partition.fex 中设置的内部存储介质的设备节点，会自动动态在/dev/by-name 中创建软链 接。例如：

root@TinaLinux:/# ll /dev/by-name/ drwxr-xr-x 2 root root 220 Mar 1 15:05 . drwxr-xr-x 7 root root 3060 Mar 1 15:05 .. lrwxrwxrwx 1 root root 12 Mar 1 15:05 UDISK -> /dev/nand0p9 lrwxrwxrwx 1 root root 12 Mar 1 15:05 boot -> /dev/nand0p2 lrwxrwxrwx 1 root root 12 Mar 1 15:05 env -> /dev/nand0p1 lrwxrwxrwx 1 root root 12 Mar 1 15:05 misc -> /dev/nand0p6 lrwxrwxrwx 1 root root 12 Mar 1 15:05 private -> /dev/nand0p8 lrwxrwxrwx 1 root root 12 Mar 1 15:05 pstore -> /dev/nand0p7 lrwxrwxrwx 1 root root 12 Mar 1 15:05 recovery -> /dev/nand0p5 lrwxrwxrwx 1 root root 12 Mar 1 15:05 rootfs -> /dev/nand0p3 lrwxrwxrwx 1 root root 12 Mar 1 15:05 rootfs_data -> /dev/nand0p4

因此，在fstab 也可以使用/dev/by-name/XXXX的形式匹配设备。块设备如果有分区，会形成分区设备节点，以mmc、U 盘为例介绍设备节点名与分区的关系：

设备节点名	含义
/dev/mmcblk0	表示整个mmc 空间，包含所有分区
/dev/mmcblk0p1	表示mmc 中的第1 个分区
/dev/mmcblk0p2	表示mmc 中的第2 个分区
/dev/sda	表示整个U 盘，包含所有分区
/dev/sda1	表示U 盘内的第1 个分区
/dev/sda2	表示U 盘内的第2 个分区

热插拔块设备分区有以下特殊情况。

块设备没有分区 有一些特殊的TF 卡/U 盘没有分区，而是直接使用整个存储，表现为只有/dev/mmcblk1 和 /dev/sda ，而没有分区节点/dev/mmcblk1p1 和/dev/sda1 。此时需要直接挂载整个存储 设备，Tina 大部分方案都支持这种特殊情况。

块设备有多个分区 有一些特殊的TF 卡/U 盘被分为多个分区，表现为存在多个/dev/mmcblk1p{1,2…} 和 /dev/sda{1,2…}。默认情况下，Tina 的fstab 配置为只支持挂载热插拔存储设备的第一个 分区到/mnt/SDCARD 或者/mnt/exUDISK。

3.2 挂载点

3.2.1 默认挂载设备目录

Tina 中对常见的分区和热插拔块设备，有默认的挂载点。

存储介质	挂载节点	设备节点	备注
nor/nand/mmc	/mnt/UDISK	/dev/by-name/UDISK	注1
TF 卡	/mnt/SDCARD 或/mnt/extsd	/dev/mmcblk{0,1}p1	注2
U 盘	/mnt/exUDISK	/dev/sda1	注3
SATA 磁盘	/mnt/exUDISK	/dev/sda1	注3

说明

/dev/by-name/UDISK 为sys_partition.fex 的UDISK 分区的软连接。

当无分区时，默认挂载整个TF 卡; 当有1 个或多个分区时，只挂载第一分区。

当无分区时，默认挂载整个设备(/dev/sda)，当有1 个或多个分区时，只挂载第一个分区。

3.2.2 新建挂载点

挂载文件系统需要有挂载点。 如果挂载点所在目录可写，则在挂载之前先创建目录即可。

mkdir -p xxx

若挂载点所在目录为只读，则需要在制作文件系统时提前创建好。 如创建非空目录，则在对应方案的base-files 目录创建。

procd-init: target/allwinner/方案/base-files busybox-init: target/allwinner/方案/busybox-init-base-files

如创建空目录，由于git 不管理空目录，因此需在Makefile 中动态创建，可仿照现有Makefile中创建UDISK 目录的写法。

procd-init: package/base-files/Makefile busybox-init: package/busybox-init-base-files/Makefile

3.3 procd 启动下的挂载

procd 启动时，自动挂载由procd、fstools、fstab 配合完成。如果需要修改冷/热挂载规则，只需要修改fstab 配置文件即可。 SDK 中，配置文件位于：

tina/target/allwinner/<方案名>/base-files/etc

若只是调试或临时修改挂载规则，只需要修改小机端的配置文件：

/etc/config/fstab

3.3.1 fstab 编写格式

fstab 由多个config 组成，每个config 的基本格式示例如下：

config ‘xxxx’ option xxxx ‘xx’ option xxxx ‘xx’ option xxxx ‘xx’

config 有3 种类型，分别是mount|global|swap 。Tina SDK 中没使用swap，在本文中不做介绍。

3.3.2 global 类型config

global 类型的config 是全局配置，示例如下。

config 'global' option anon_swap '0' option anon_mount '0' option auto_swap '1' option auto_mount '1' option delay_root '5' option check_fs '1'

配置项的意义如下表：

配置名称	可选值	意义
anon_mount	0/1	注1
anon_swap	0/1	swap 使用，此处省略
auto_mount	0/1	只适用于设置热插拔是否自动挂载块设备
auto_swap	0/1	swap 使用，此处忽略
check_fs	0/1	建议配置为1，注2
delay_root	1,2,3…	注3

说明

anon_mount: 当fstab 中无匹配要挂载设备的uuid/label/device 属性的配置节时, 是否采用默认挂载为 /mnt/“$device-name”。

check_fs: 是否在挂载前用/usr/sbin/e2fsck 检查文件系统一致性(只适用于ext 系统)。

delay_root: 对应fstab 中target 为”/” 或”/overlay” 的设备节点不存在时，最长等待delay_root 秒。

3.3.3 mount 类型config

mount 类型的config 是具体的设备挂载配置，示例如下

config 'mount' option target '/mnt/UDISK' option device '/dev/by-name/UDISK' option options 'rw,sync' option enabled '1'

配置项的意义如下表：

配置名称	意义	备注
target	挂载点	必须是绝对路径，必须有效
device	设备名	通过设备名指定待挂载的设备，注1
uuid	设备UUID	通过fs 的UUID 指定待挂载的设备，注1
label	设备label	通过fs 的label 指定待挂载的设备，注1
enabled	是否使能	该节点是否有效(0/1)
options	挂载属性	例如只读挂载等，注2

device/uuid/label 是匹配挂载的设备，三者中至少要有一个有效。

默认挂载支持的属性如下表：

配置名称	意义	缺省值
ro / rw	只读/ 可读写	rw
nosuid / suid	忽略suid/sgid 的文件属性	suid
nodev / dev	不允许/允许访问设备文件	dev
noexec / exec	不允许/允许执行程序	exec
sync / async	同步/异步写入	async
mand / nomand	允许/不允许强制锁	nomand
irsync	同步更新文件夹	无效
noatime / atime	不更新/更新访问时间(atime)	atime
nodiratime / diratime	不更新/更新目录访问时间(atime)	diratime
relatime / norelatime	允许/不允许根据ctime/mtime 更新actime n	orelatime
strictatime	禁止根据内核行为来更新atime, 但允许用户空间修改	无效

3.4 busybox 启动下的挂载

busybox 启动时，通过pseudo_init 和rcS 完成大部分默认的挂载工作。

存储节点	挂载路径	用途
/dev/by-name/UDISK	/mnt/UDISK	用户数据
/dev/by-name/rootfs_data	/overlay	作为overlay 使得rootfs 可写
/dev/mmcblk{0,1}p1	/mnt/SDCARD 或/mnt/extsd	TF 卡
/dev/sda1	/mnt/exUDISK	U 盘

busybox 启动使用默认挂载配置即可，如果需要修改，需要自行修改脚本。

tina/package/busybox-init-base-files/busybox-init-base-files/usr/bin/hotplug.sh

3.5 挂载文件系统

在分区表中增加的分区默认是空分区，如需挂载成文件系统使用，则首先需要在分区中写入一个文件系统。 方式一，在PC 端预先生成好一个文件系统，并在分区表中指定为download_file，则启动后可直接挂载。例如rootfs 分区就是在PC 端制作好文件系统，烧录时写入rootfs 分区。 方式二，在小机端进行格式化。例如UDISK 分区就是在第一次启动时，由启动脚本进行格式化。客户可自行在某一启动脚本或应用中调用格式化工具（mkfs.xxx）进行格式化。如需参考，可仿照UDISK 分区的格式化：

procd-init: package/base-files/files/lib/preinit/79_format_partition busybox-init: package/busybox-init-base-files/files/pseudo_init

3.5.1 注意事项

一些格式化工具并未默认选中，需要时请自行在make menuconfig 界面配置。部分文件系统对分区大小有最低要求，如ext4，ubifs，如果在小机端调用格式化分区时报错，可根据报错信息提示增大分区。 对于private 分区默认为空，使用DragonSN 工具写号后，则为vfat 格式的文件系统。对于ubi 方案来说，如果需要使用基于块设备的文件系统，则需要在ubi 之上模拟块设备。在用户空间可调用ubiblock 工具完成，注意这样模拟出的块设备是只读的，如需可写建议直接使用 ubifs。

详见后文ubi 方案特殊说明。

4 文件系统支持情况

存储介质	jffs2	squashfs	ext4	vfat	ntfs	exfat	ubifs
(NFTL) nand	N	Y	Y	Y	Y	N	N
(UBI) spinand	N	Y	Y(ro)	Y(ro)	Y(ro)	N	Y
mmc	N	Y	Y	Y	Y	N	N
nor	Y	Y	N	N	N	N	N
TF 卡	N	N	Y	Y	Y	N	N
U 盘	N	N	Y	Y	Y	N	N

说明

(ro) 表示只能实现只读: ubi 卷可通过模拟块设备，实现块文件系统的读，但不支持写。

vfat（fat32）使用内核原生的支持，exfat 需要在Linux-5.7 后社区才正式支持，因此此处标注为不支持。

ntfs 依赖于第三方工具ntfs-3g。

TF 卡/U 盘等，建议使用vfat 实现Window/Linux/MacOS 的最大兼容参考文章《多平台大型文件系统比较》。

vfat/ntfs/exfat 等Window 文件系统，不建议用做嵌入式存储，除非您能保证其掉电安全和移植文件系统修复工具。

警告 关于文件系统的选择，有以下几点需要注意：

全志NFTL nand 可使用块文件系统(ext4) 全志在驱动中实现磨损平衡和坏块管理，向上呈现为块设 备。因此可支持ext4，不需要且不支持常见的flash 文件系统(jffs2/yaffs/ubifs 等)。

为了保证掉电不变砖，根文件系统务必只读(squashfs)，或者ext4 挂载为ro 模式。

ext4/ubifs 等文件系统分区大小必须足够大，以确保能正确创建日志块，否则有掉电变砖风险分区大小 请参考章节分区大小与对齐。

4.1 ext4 与日志

4.1.1 ext4 的日志

与服务器等长期稳定供电的情况不同，嵌入式设备随时有掉电的可能。不管在任意时间掉电，文件系统都需要保持一致性，换句话说，保证文件不会因为掉电丢失。如果文件系统只读，则不需要日志。日志只是确保写的安全。

说明 什么是文件系统的一致性？ 文件系统元数据块记录了有什么文件，数据块则保存了实际的文件内容。一致性则表示，元数据块记录了存在某个文件，必定存 在对应的数据块，换句话说，就是保证元数据和数据的一致。 如果出现，元数据记录文件A 存在，但文件A 的数据块是无效的，或者明明数据块是有效的，但元数据并没任何记录，导致系 统并不知道文件存在，就出现了文件系统的不一致。

警告 保证文件不丢失，只保证之前写入的文件数据正常，而非正在写，且因为掉电导致没写完整的文件。对大多数文 件系统而言，更多时候会直接丢弃这没写完整的文件以保证一致性。

ext4 通过日志的形式保证文件系统一致性。其支持3 种日志模式：

日志模式	原理	特点
journal	元数据与数据都写入日志	最安全，但性能最慢
writeback	只有元数据写入日志，但不保证数据先落盘	性能最快，但最不安全
ordered	只有元数据写入日志，且保证数据先落盘，元数据后落盘	折中，默认方案

考虑安全和性能的折中，建议使用ordered 的日志模式。系统默认使用的就是ordered 模式。我们在mount 命令中显示的挂载参数可显示使用的哪种日志。

$mount /dev/by-name/UDISK on /mnt/UDISK type ext4 (rw,....,data=ordered)

4.1.2 分区大小与日志

有时候分区太小，系统会默认把日志功能关闭。可以通过以下方法判断：

$dumpe2fs <分区or 镜像文件> ... Filesystem features: has_journal ... ... Journal backup: inode blocks Journal features: (none) 日志大小: 1024k Journal length: 1024 Journal sequence: 0x00000001 Journal start: 0 ...

在Filesystem features 中有has_journal 的标志表示支持日志。在Jorunal 片段中也详细描述了日志块的大小等信息。 如果创建的文件系统没有日志，对大多数用户而言，扩大分区大小是最简单的做法。专业的做法可以通过缩小块大小，取消预留块等方式为日志腾挪出空间。 按以往经验，对小容量(<100M) 的存储而言，在资源文件之外预留3-5M 的空间用于文件系统的元数据即可。

4.1.3 修复ext4

ext4 文件系统每次重启后，建议都进行一次修复，确保文件系统稳定。 修复可以参考以下命令：

e2fsck -y <分区>

4.1.4 修复fat

TF 卡挂载fat 文件系统，fat 文件系统不是日志型文件系统，在掉电、带电插拔等场景下不能保证文件系统数据的安全，所以建议启动都进行一次修复。修复可以参考以下命令：

fsck_msdos -pfS /dev/mmcblk0p1

如章节global 类型config中描述，如果使用procd 引导启动，在fstab 中使能check_fs，也可实现在挂载前自动修复。

5 UBI VS. NFTL

对nand 存储介质，全志有两套解决方案，分别是NFTL spi/raw nand 和UBI spi nand。UBI 存储方案常用于小容量spinand，其实现原理跟NFTL 存储方案完全不同。

5.1 NFTL Nand

这是全志实现的不开源的Nand 驱动，NFTL 全称为NAND Flash Translation Layer，其可实现屏蔽Nand 的特性，对上呈现为块设备。 我们常见的mmc 设备也是块设备，可以简单理解为，MMC = Nand Flash + 控制器+NFTL。所以通过全志的NFTL nand 驱动后，我们可以像mmc 设备一样，以块设备操作Nand。 例如，上层可以直接裸读写块设备，常见的ota 更新也是基于这样的实现：

dd if=boot.fex of=/dev/by-name/boot

技巧

详细的OTA 方法，请参见OTA 相关文档。

全志的NFTL Nand 驱动中，预留一部分空间做算法和关键数据保存。预留空间大致为1/10 ~1/8 的可用空间。这里的可用空间是指剔除出厂坏块之外的空间。由于每一颗Flash 的出厂坏块数量不尽相同，因此最终呈现给用户的可用空间不尽相同。用户也不需要担心使用过程中出现的坏块导致用户可用空间变小，在算法实现中，使用坏块会体现在预留空间而不是用户空间。 此外，Nand 的磨损平衡、坏块管理等特性全由NFTL 驱动实现。换句话说，驱动保证用户数据的稳定，用户可将其按块设备使用。

5.2 UBI (spi) Nand

当前UBI 方案仅适用于小容量spinand。 UBI 方案是社区普遍使用的Flash 存储方案，其构建在mtd 设备之上，由UBI 子系统屏蔽Nand 特性，对接UBIFS 文件系统。其层次结构由上往下大致如下：

层次	层级	功能
0 (最上层)	UBIFS	ubifs 文件系统
1 UBI	子系统	Nand 特性管理
2	MTD 子系统	封装Flash，向上提供统一接口
3 (最下层)	Flash	具体的Flash 驱动

我们把MTD 分区称为物理分区，把UBI 卷(分区) 成为逻辑分区，因为 • MTD 分区是按Flash 的物理地址区间划分分区 • UBI 卷(分区) 是动态映射的区间 全志的UBI 方案中，创建了这些MTD 物理分区：

分区名	大小	作用
boot0	4/8 个物理块	存放boot0
uboot	4/20M	存放uboot
secure storage	8 个物理块	存放关键数据
pstore	512K	奔溃日志转存
sys	剩余空间	提供给ubi 子系统划分逻辑分区

驱动会在sys 的MTD 物理分区上根据sys_partition.fex构建UBI 逻辑分区(卷)。 UBI 设备向上呈现为字符设备，无法直接使用诸如ext4 这样基于块设备的文件系统。但UBI 子系统支持模拟只读的块设备，即把UBI 逻辑卷模拟成只读的块设备。基于此，可以做到根文件系统依然使用squashfs 这样的块文件系统。 社区为UBI 设备专门设计了ubifs 文件系统。经过验证，其配合UBI 子系统可保证数据掉电安全以及提供通用文件系统所有功能，甚至还提供文件系统压缩功能。 除此之外，UBI 设备更新（OTA 更新）也不能直接裸写设备，需要通过ubiupdateval 命令更新。 技巧：详细的OTA 方法，请参见OTA 相关文档。

5.3 ubi 相关工具

5.3.1 ubinfo

输出指定ubi 设备信息。 例子:

ubinfo /dev/by-name/rootfs #查看rootfs卷的信息 ubinfo -a #查看所有卷的信息

可参考总容量说明

5.3.2 ubiupdatevol

更新指定卷上的数据。 例子:

ubiupdatevol -t /dev/by-name/boot #清除boot卷的数据 ubiupdatevol /dev/by-name/boot /tmp/boot.img #将/tmp/boot.img写到boot卷，卷上原有数据会完全丢失

可参考总容量说明

可参考模拟块设备

5.3.3 ubiblock

基于一个ubi 卷，生成模拟的只读块设备 例子:

ubiblock -c /dev/by-name/test #将test卷生成一个块设备节点

可参考模拟块设备

5.3.4 其他

在tina 方案上，烧录固件时已经完成mtd 和ubi 卷的创建，启动时自动attach 并挂载对应的分区，无需再自行处理。因此以下命令一般不会用到。 ubiformat: 将裸mtd 格式化成ubi ubiattach: 将mtd 关联到ubi ubidetach: 将ubi 与mtd 解除关联ubimkvol: 创建ubi 卷 ubirmvol: 移除ubi 卷

6 rootfs_data 及UDISK

6.1 overlayfs 简介

Tina 默认根文件系统格式使用squashfs 格式，这是一种只读压缩的文件系统。很多应用则需要文件系统可写，特别是/etc 等存放较多配置文件的目录，为了满足可写的需求，Tina 默认使用overlayfs 技术。overlayfs 是一种堆叠文件系统，可以将底层文件系统和顶层文件系统的目录进行合并呈现。

6.2 使用rootfs_data 作为overlayfs

Tina 常用的方式是专门划分一个rootfs_data 分区， 先格式化成可写的文件系统（如ext4/ubifs）， 再进一步挂载为overyfs， 成为新的根， 让上层应用认为rootfs 是可写的。 rootfs_data 分区的大小就决定了应用能修改多少文件。具体原理和细节请参考网上公开资料，此处仅举简单例子辅助理解。

底层（即rootfs 分区的文件系统）不存在文件A，应用创建A，则A 只存在于上层（即 rootfs_data 分区）。

底层存在文件B，应用删除B，则B 仍然存在于底层，但上层会创建一个特殊文件屏蔽掉，导 致对应用来说B 就看不到了，起到删除的效果。

底层存在文件C，上层修改C，则C 会先被整个拷贝到上层，C 本身多大就需占用多大的上 层空间，在这个基础上应用对上层的C 进行修改。 基于以上理解，可按需配置rootfs_data 的大小。一般开发期间会配置得较大，量产时可减小 （考虑实际只会修改少量配置文件）甚至去除（需要确认所有应用均不依赖rootfs 可写）。

6.3 使用UDISK 作为overlayfs

如果希望overlayfs 的空间尽可能较大，也可考虑直接使用UDISK 分区作为上层文件系统空间。 可将target/allwinner/xxx/base-files/etc/config/fstab 中的rootfs_data 分区及UDISK 分区的挂载配置disable 掉。

config 'mount' option target '/overlay' option device '/dev/by-name/rootfs_data' option options 'rw,sync,noatime' option enabled '0' #此行改成0 config 'mount' option target '/mnt/UDISK' option device '/dev/by-name/UDISK' option options 'rw,async,noatime' option enabled '0'

再新增一个配置，将UDISK 直接挂载到/overlay 目录。

config 'mount' option target '/overlay' option device '/dev/by-name/UDISK' option options 'rw,sync,noatime' option enabled '1'

6.4 如何清空rootfs_data 和UDISK

出于恢复出厂设置或其他需要，有时需要清空rootfs_data 和UDISK。 一般不建议在文件系统仍处于挂载状态时直接操作对应的底层分区，因此建议需要清空时，不要直接操作对应块设备，而是先设置标志并重启，再在挂载对应分区前的启动脚本中检测到对应标志后，对分区进行重新格式化。 当前79_format_partition 中实现了一个clean_parts 功能， 会检测env 分区中的parts_clean 变量并清空对应分区的头部。清空后，rootfs_data 和UDISK 分区会自动重新触发格式化。

# to clean rootfs_data and UDISK, please run fw_setenv parts_clean rootfs_data:UDISK reboot

具体实现请查看

package/base-files/files/lib/preinit/79_format_partition

7 关键数据保护

设备上保存的一些关键的数据，例如mac，SN 号等，一般要求在重新刷机时不丢失。以下介绍刷机数据不丢失的解决方案。

7.1 逻辑分区保护方案

7.1.1 分区设置

此处的逻辑分区，是指在分区表(sys_partition.fex/sys_partition_nor.fex) 中定义的分区。名字为private 的分区会特殊处理，默认刷机数据不丢失。 其他名字的分区，如果指定keydata=0x8000 属性，则刷机数据不丢失。对于private 分区或设置了keydata=0x8000 属性的分区，请勿设置downloadfile。

7.1.2 实现原理

对private 分区(配置了keydata=0x8000 属性同理) 保护的方式是，擦除之前先申请一片内存，然后根据flash 中的旧分区表，读出private 分区内容。 接着进行擦除，然后再按照新的分区表，将private 分区内容写回flash 上新分区所在位置。

7.1.3 常见用法

使用全志的DragonSN 工具，选择私有key 模式，将key 写入private 分区。写入后private分区默认会是一个vfat 文件系统，启动后挂载/dev/by-name/private，即可读出key。DragonSN 的具体用法请参考工具自带文档。

不使用DragonSN 工具， 由应用自行负责写入数据和读出数据， 直接在用户空间操作/dev/by-name/private 节点即可。量产时可自行开发PC 端工具，通过adb 命令来完成key 的写入。

7.1.4 ubi 方案特殊说明

7.1.4.1 模拟块设备

对于nand nftl 方案，emmc 方案，nor 方案，逻辑分区是对应到一个块设备，即对于private分区，可以直接读写/dev/by-name/private 节点，也可以借助DragonSN 工具制作成一个vfat文件系统，再挂载使用，挂载后文件系统是可读写的。 但对于nand ubi 方案，逻辑分区是对应到ubi 卷，由于ubi 的特性，无法再直接写数据到/dev/by-name/private 节点，需要通过ubiupdatevol 工具来更新卷，或者自行在应用中按照ubi 卷更新步骤操作。 当基于ubi 卷构建vfat 文件系统时，需要先基于ubi 卷模拟块设备，且挂载上的vfat 文件系统是只读的。操作示例如下。

#查看private分区对应的ubi节点 root@TinaLinux:/# ll /dev/by-name/private lrwxrwxrwx 1 root root 11 Jan 1 00:00 /dev/by-name/private -> /dev/ ubi0_4 #创建模拟的块设备 root@TinaLinux:/# ubiblock -c /dev/ubi0_4 block ubiblock0_4: created from ubi0:4(private) #挂载 root@TinaLinux:/# mkdir /tmp/private root@TinaLinux:/# mount -t vfat /dev/ubiblock0_4 /tmp/private/ #可以读取内容 root@TinaLinux:/# ls /tmp/private/ ULI magic.bin #查看挂载情况，为ro root@TinaLinux:/# mount | grep private /dev/ubiblock0_4 on /tmp/private type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437, iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

7.1.4.2 在设备端制作vfat 镜像

由于ubifs 需占用17 个LEB，比较占空间，对于只在工厂一次性写入信息，后续只读的场景，一种可考虑的方案是使用vfat 文件系统。 首先选上kernel 的loopback 支持：

make kernel_menuconfig 选上Device Drivers --> [*] Block Devices --> <*>Loopback device support

分区表中建立分区，假设为test 分区随后可以在小机端准备一个vfat 镜像：

dd if=/dev/zero of=/mnt/UDISK/test.img bs=1M count=1 mkfs.vfat /mnt/UDISK/test.img mkdir -p /tmp/test mount /mnt/UDISK/test.img /tmp/test 此时可向/tmp/test 写入文件 umount /tmp/test

将镜像写入卷中：

ubiupdatevol /dev/by-name/test /mnt/UDISK/test

后续按上文介绍的方法，使用模拟块设备挂载，注意使用模拟块设备挂载后就是只读的了。

7.1.5 可能造成数据丢失的情况

出现以下情况，会导致private 分区数据丢失。

配置了强制擦除，例如sys_config.fex 中配置了eraseflag = 0x11。

无法读取flash 上的分区表或private 分区。这个可能的原因包括flash 上的数据被破坏了 等。

新的分区表不包含private 分区。

在烧录过程中掉电。如上所述，烧录时是读出-> 擦除-> 写回，在擦除之后，写回之前掉电，则数据丢失。 检测到private 分区，开始执行保护private 分区的代码，但执行过程中出错，如malloc 失败,private 无法读取等，则会导致烧录失败。出现malloc 失败问题一般是因为板子上烧录了Android固件。因为安卓的private 分区比较大，而tina 的uboot 分配给malloc 的空间比较小。 这个时候，需要打包一份不保护private 分区的tina 固件先进行一次烧录，即可解决问题。具体的：将sys_config.fex 的eraseflag 改为0x11，强制擦除。或者临时移除sys_partition.fex中的private 分区。

7.2 物理区域保护方案

另一种保护数据不丢失的思路是，在flash 上划定一块物理区域，烧录时默认不擦除。在Tina 上实现的secure storage 区域即具有这种特性。secure storage 区域用于保存key，可代替private 分区，理论上更为安全（被烧录时误擦除和被别的应用误写的可能性较低）。

7.2.1 nand nftl 方案实现

nand nftl 方案中，预留了一块物理区域，用于secure storage。这块区域不是逻辑分区，用户空间不可见。烧录时不会擦除这块区域。在用户空间读写secure storage 需要使用ioctl，由内核nand 驱动来协助完成。

7.2.2 nand ubi 方案实现

nand ubi 方案中，预留了一块物理区域，用于secure storage，对上表现为一个mtd 分区。用户空间可见。烧录时不会擦除这块区域。在用户空间读写secure storage 需要使用ioctl，由内核来协助完成。理论上也可以直接读写mtd 设备节点，但不推荐，使用这种方式应用需要自行处理坏块等问题。

7.2.3 emmc 方案实现

预留了一块物理区域，默认是偏移6M-6.25M 的区域，作为secure storage。在用户空间读写，可以直接通过mmcblk0 节点读写指定偏移。

7.2.4 nor 方案实现

暂未实现。

7.2.5 常见用法

使用全志的DragonSN 工具，选择安全key 模式，将key 写入secure storage 区域。启动后在用户空间调用库读出key。DragonSN 的具体用法请参考工具自带文档。

不使用DragonSN 工具，由应用自行在用户空间调用库写入数据和读出数据。量产时可自行开发PC 端工具，通过adb 命令来完成key 的写入。

7.2.6 secure storage 格式

secure storage 有预设的格式，简单总结如下 • secure storage 总大小为256KB，因为有备份，所以实际能用128KB。 • 128KB 分为32 个item, 即每个item 是4KB。 • item0 用作secure_sotrage_map，所以用户能用的实际为31 个item。 • 每个item 内部为键值对的格式，包含CRC 校验，其中用户可存储的key 长度最多为3KB。 • secure_storage_map 中是以“name:length” 的格式保存所有item 的信息，所以所有item的“name:length” 字符串长度总和不能超过secure_storage_map 中data 的长度。一般而言，31 个3KB 的key 可以满足需求，如果无法满足，例如需要更多数量的key，则一种解决方式是上层应用自行将多个key 拼接起来，只要总大小不超过3KB 即可当成一个key 写入 secure storage。读出时应用自行反向解析出目标key 即可。

7.2.7 在uboot 中读写

基于以上介绍的格式，uboot 中封装了pst 命令。

pst - read data from secure storageerase flag in secure storage Usage: pst pst read|erase [name] pst read, then dump all data pst read name, then dump the dedicate data pst write name, string, write the name = string pst erase, then erase all secure storage data pst erase key_burned_flag, then erase the dedicate data

7.2.8 在用户空间读写

Tina 提供了读写库。

make menuconfig 选中Allwinner --> <*> libsec_key --> [*] Enable secure storage key support

如果选上demo，则会编译出demo 程序sec_key_test。

root@TinaLinux:/# sec_key_test -h -w : write key to sst and private -r : read key from sst or private -t 0: write some key to secure storage -t 1: repetitve read + verify some key from secure storage -t 2: repetitve write + verify some key from secure storage -t 3: verify some key from secure storage -t 4: write some key to private -t 5: repetitve read + verify some key from private -t 6: repetitve write + verify some key from private -t 7: verify some key from private -l : list -d : printf hex -h : help

更详细的使用方式请参考：

tina/package/allwinner/libkey/readme.txt

7.3 secure storage 区域与private 分区比较

刷机不丢失的特性： • private 分区每次刷机，是先读出到dram，擦除flash，再写入flash。刷机中途掉电可能丢失 • secure storage 则是刷机过程完全不会擦除。理论上secure storage 的数据更安全。

用户空间误操作的可能： • private 分区可以用常规分区更新命令清除掉。 • secure storage 需要通过ioctl 专用接口访问。

数据格式： • private 分区可以裸分区读写，也可以格式化成文件系统。 • secure storage 已限制为键值对，key 的长度也有限制。

存放位置： • private 分区大小由分区表配置，是一个可见的普通分区。 • secure storage 是flash 上的保留区域，大小固定，分区表中不可见。

• private 分区没有备份，请避免写入时掉电。或者自行在private 分区中构建备份。 • secure storage 默认是双备份。

在uboot 访问： • private 分区，uboot 通过通用的读写flash 接口或文件系统接口访问，取决于数据格式。 • sectre storage 区域，有固定格式，通过uboot 提供的secure storage 专用接口访问。

校验： • private 分区如果是裸数据，是否校验由应用自行处理。如果是文件系统，则由文件系统特性决定。 • secure storage 格式中带了crc 校验。

审核编辑：汤梓红