2020-09-29 GPT分区&&f2fs

最新推荐文章于 2024-03-28 18:13:36 发布
最新推荐文章于 2024-03-28 18:13:36 发布
阅读量1.6k 收藏 7
点赞数
分类专栏： Linux Android 文章标签： linux
原文链接：http://www.jinbuguo.com/storage/gpt.html
版权

eMMC基础技术9：分区管理

http://www.wowotech.net/basic_tech/emmc_partitions.html
https://en.wikipedia.org/wiki/GUID_Partition_Table
https://en.wikipedia.org/wiki/Disk_partitioning
https://blog.csdn.net/wxh0000mm/article/details/77864002
https://blog.csdn.net/Darton_Zhang/article/details/79034396
http://www.jinbuguo.com/storage/gpt.html
Android eMMC 分区详解(转载)
GPT 分区详解
https://lwn.net/Articles/518717/
https://lwn.net/Articles/518988/
[http://manpages.ubuntu.com/manpages/bionic/man8/resize.f2fs.8.html]
(http://manpages.ubuntu.com/manpages/bionic/man8/resize.f2fs.8.html)
http://manpages.ubuntu.com/manpages/bionic/man8/mkfs.f2fs.8.html
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git

0.前言

emmc的物理分区有boot partition,boot partition2以及RPMB(Replay Protected Memory Block),GPAP(GeneralPurpose Area Partitions,最多可以有4个)，UDA（User Data Area)分区。而我们一般只知道UDA分区。一般我们的Android或linux分区都会建立在User data Area。具体型号的eMMC每个物理分区的大小，可以参考对应的eMMC的datasheet，有详细参数说明。
在这里插入图片描述

  1. J6 Android eMMC 分区结构
    J6 Android系统的分区表的起始是从eMMC的User Data Area起始的，以下为J6 Android在eMMC上的分区结构
    在这里插入图片描述

    最开始128K空间，共256个block(每个block是512Byte)。block0 是传统的MBR分区(包含MBR分区标记)，但并不包含实际的分区表信息。J6 Android采用的是GPT分区表，从block1开始是GPT分区表信息。软件这块可以通过gpt write 命令的代码流程分析，也可以通过dd命令dump出eMMC前128K数据来分析。后面都会有分析。 剩余空间大小，分为固定大小空间和可变空间大小(user data由eMMC决定）。

固定分区大小:

128K+128K+768K+128K+128K+384K+16M+16K+10M+10M+768M+256M+8M+8M+8M+8M+17KB

=1119905KB

eMMC可用用户数据区大小：mmc->capacity= 0x1d0000000 = 7602176KB

计算出Android User Data 分区的大小:7602176KB- 1119905KB = 6482271KB

其中User Data分区的大小跟具体某款eMMC型号相关，可通过eMMC的CSD相关寄存器可以读取，一般datasheet上也会标明。

  1. J6 GPT分区表的创建

    J6分区表在dra7xx_evm.h中定义,

在这里插入图片描述

通过uboot中的命令行 gpt write mmc 1 $partitions_android可创建GPT 分区表。要注意的是userdata分区大小并不是固定的,该分区大小eMMC 容量和已用大小相关.所以对编译出的userdata.img需要单独做resize的处理,后续会有说明。

3.UserData 分区的处理
J6 Android编译生成的system.img和userdata.img都是包含ext4文件系统信息的image。经过simg2img 处理后可以在linux系统上将该image m挂载成文件系统的形式，它包含了文件系统的全部信息。正因为userdata分区跟具体emmc型号相关，所以该分区的大小是可变的。一般具体项目编译出来的userdata.img会有一个默认大小（Boardconfig.mk中配置），但最终实际的大小都需要做resize的处理。
以J6 EVM板上8G eMMC为例,经计算,Android分区的UserDataPartition 大小为 6482271KB. 系统默认编译出来的userdata.img 是稀疏的(sparse类型)image,压缩了全0的数据.可以通过./simg2img userdata.img userdata.img.raw 将sparse形式的image还原为raw 的ext4的文件.
查看userdata.img.raw大小,2147483648Byte,仅默认2GB大小空间.并不符合我们的 6482271KB的UserData 分区.
在这里插入图片描述

所以要对userdata.img进行resize：

  1. 将这种raw的ext4格式的image mount到某个目录下(data)

mount -o loop -o grpid -t ext4./userdata.img.raw ./data

2)通过make_ext4fs将data目录制作成(指定分区大小userdatasize})sparse格式的userdata_new.img.

./make_ext4fs -s -l ${userdatasize}K -a datauserdata_new.img data/

最后将resize过后的userdata_new.img通过fastboot flash命令烧录的指定的分区,并不需要单独的格式化分区.

3.1 Android默认编译出的image大小如何配置?
在这里插入图片描述

配置文件在mydroid\device\ti\jacinto6evm\BoradConfig.mk中

3.2 Fastboot.sh脚本中怎么获取到userdata_size ?
TI提供的linux环境下的fastboot.sh中,会进行对userdata做resize操作，原理是怎样的？是如何获取当前emmc的userdata大小的呢。fastboot.sh中代码片段:

在uboot中,设置环境变量：
在这里插入图片描述

eMMC 标准中，将内部的 Flash Memory 划分为 4 类区域，分别是：
User Data区域用于存储数据；
boot区域用于启动；
replay protected memory block区域用于存放受保护的数据
general purpose分区

1. 概述

在这里插入图片描述

图1 eMMC分区

Boot Area Partitions 和 RPMB Partition 的容量大小（须为128kB的倍数）通常都为 4MB，部分芯片厂家也会提供配置的机会。

General Purpose Partitions (GPP) 则在出厂时默认不被支持，即不存在这些分区，需要用户主动使能，并配置其所要使用的 GPP 的容量大小，GPP 的数量可以为 1 - 4 个，各个 GPP 的容量大小可以不一样。

User Data Area (UDA) 的容量大小则为总容量大小减去其他分区所占用的容量。更多各个分区的细节将在后续小节中描述。
eMMC 的每一个硬件分区的存储空间都是独立编址的，即访问地址为 0 - partition size。

具体的数据读写操作实际访问哪一个硬件分区，是由 eMMC 的 Extended CSD register 的 PARTITION_CONFIG Field 中 的 Bit[2:0]: PARTITION_ACCESS 决定的，用户可以通过配置 PARTITION_ACCESS 来切换硬件分区的访问。

也就是说，用户在访问特定的分区前，需要先发送命令，配置 PARTITION_ACCESS，然后再发送相关的数据访问请求。更多数据读写相关的细节，请参考 eMMC 总线协议 章节。

eMMC 的各个硬件分区有其自身的功能特性，多分区的设计，为不同的应用场景提供了便利。

2. Boot Area Partitions

Boot Area 包含两个 Boot Area Partitions，主要用于存储 Bootloader，支持 SOC 从 eMMC 启动系统。

2.1 容量大小

两个 Boot Area Partitions 的大小是完全一致的，由 Extended CSD register 的 BOOT_SIZE_MULT Field 决定，大小的计算公式如下：

Size = 128Kbytes x BOOT_SIZE_MULT

一般情况下，Boot Area Partition 的大小都为 4 MB，即 BOOT_SIZE_MULT 为 32，部分芯片厂家会提供改写 BOOT_SIZE_MULT 的功能来改变 Boot Area Partition 的容量大小。

BOOT_SIZE_MULT 最大可以为 255，即 Boot Area Partition 的最大容量大小可以为 255 x 128 KB = 32640 KB = 31.875 MB。

2.2 从 Boot Area 启动

eMMC 中定义了 Boot State，在 Power-up、HW reset 或者 SW reset 后，如果满足一定的条件，eMMC 就会进入该 State。进入 Boot State 的条件如下：

Original Boot Operation
CMD 信号保持低电平不少于 74 个时钟周期，会触发 Original Boot Operation，进入 Boot State。
在这里插入图片描述

Alternative Boot Operation
在 74 个时钟周期后，在 CMD 信号首次拉低或者 Host 发送 CMD1 之前，Host 发送参数为 0xFFFFFFFA 的 COM0时，会触发 Alternative Boot Operation，进入 Boot State。
在这里插入图片描述

在 Boot State 下，如果有配置 BOOT_ACK，eMMC 会先发送 “010” 的 ACK 包，接着 eMMC 会将最大为 128Kbytes x BOOT_SIZE_MULT 的 Boot Data 发送给 Host。

传输过程中，Host 可以通过拉高 CMD 信号 (Original Boot 中)，或者发送 Reset 命令 (Alternative Boot 中) 来中断 eMMC 的数据发送，完成 Boot Data 传输。

Boot Data 根据 Extended CSD register 的 PARTITION_CONFIG Field 的 Bit[5:3]:BOOT_PARTITION_ENABLE 的设定，可以从 Boot Area Partition 1、Boot Area Partition 2 或者 User Data Area 读出。

Boot Data 存储在 Boot Area 比在 User Data Area 中要更加的安全，可以减少意外修改导致系统无法启动，同时无法更新系统的情况出现。

（更多 Boot State 的细节，请参考 eMMC 工作模式 的 Boot Mode 章节）

2.3 写保护

通过设定 Extended CSD register 的 BOOT_WP Field，可以为两个 Boot Area Partition 独立配置写保护功能,以防止数据被意外改写或者擦出。

eMMC 中定义了两种 Boot Area 的写保护模式：

Power-on write protection，使能后，如果 eMMC 掉电，写保护功能失效，需要每次 Power on 后进行配置
Permanent write protection，使能后，即使掉电也不会失效，主动进行关闭才会失效

3. RPMB Partition

RPMB（Replay Protected Memory Block）Partition 是 eMMC 中的一个具有安全特性的分区。
eMMC 在写入数据到 RPMB 时，会校验数据的合法性，只有指定的 Host 才能够写入，同时在读数据时，也提供了签名机制，保证 Host 读取到的数据是 RPMB 内部数据，而不是攻击者伪造的数据。

RPMB 在实际应用中，通常用于存储一些有防止非法篡改需求的数据，例如手机上指纹支付相关的公钥、序列号等。

RPMB 可以对写入操作进行鉴权，但是读取并不需要鉴权，任何人都可以进行读取的操作，因此存储到 RPMB 的数据通常会进行加密后再存储。

3.1 容量大小

两个 RPMB Partition 的大小是由 Extended CSD register 的 BOOT_SIZE_MULT Field 决定，大小的计算公式如下：

Size = 128Kbytes x BOOT_SIZE_MULT

一般情况下，Boot Area Partition 的大小为 4 MB，即 RPMB_SIZE_MULT 为 32，部分芯片厂家会提供改写 RPMB_SIZE_MULT 的功能来改变 RPMB Partition 的容量大小。

RPMB_SIZE_MULT 最大可以为 128，即 Boot Area Partition 的最大容量大小可以为 128 x 128 KB = 16384 KB = 16 MB。

3.2 Replay Protect 原理

使用 eMMC 的产品，在产线生产时，会为每一个产品生产一个唯一的 256 bits 的 Secure Key，烧写到 eMMC 的 OTP 区域（只能烧写一次的区域），同时 Host 在安全区域中（例如：TEE）也会保留该 Secure Key。

在 eMMC 内部，还有一个RPMB Write Counter。RPMB 每进行一次合法的写入操作时，Write Counter 就会自动加一 。

通过 Secure Key 和 Write Counter 的应用，RMPB 可以实现数据读取和写入的 Replay Protect。

RPMB 数据读取
RPMB 数据读取的流程如下：
在这里插入图片描述
Host 向 eMMC 发起读 RPMB 的请求，同时生成一个 16 bytes 的随机数，发送给 eMMC。
eMMC 将请求的数据从 RPMB 中读出，并使用 Secure Key 通过 HMAC SHA-256 算法，计算读取到的数据和接收到的随机数拼接到一起后的签名。然后，eMMC 将读取到的数据、接收到的随机数、计算得到的签名一并发送给 Host。
Host 接收到 RPMB 的数据、随机数以及签名后，首先比较随机数是否与自己发送的一致，如果一致，再用同样的 Secure Key 通过 HMAC SHA-256 算法对数据和随机数组合到一起进行签名，如果签名与 eMMC 发送的签名是一致的，那么就可以确定该数据是从 RPMB 中读取到的正确数据，而不是攻击者伪造的数据。
通过上述的读取流程，可以保证 Host 正确的读取到 RPMB 的数据。

RPMB 数据写入
RPMB 数据写入的流程如下：
在这里插入图片描述

Host 按照上面的读数据流程，读取 RPMB 的 Write Counter。
Host 将需要写入的数据和 Write Counter 拼接到一起并计算签名，然后将数据、Write Counter 以及签名一并发给 eMMC。
eMMC 接收到数据后，先对比 Write Counter 是否与当前的值相同，如果相同那么再对数据和 Write Counter 的组合进行签名，然后和 Host 发送过来的签名进行比较，如果签名相同则鉴权通过，将数据写入到 RPMB 中。
通过上述的写入流程，可以保证 RPMB 不会被非法篡改。

更多 RPMB 相关的细节，可以参考 eMMC RPMB 章节。

4. General Purpose Partitions

eMMC 提供了 General Purpose Partitions (GPP)，主要用于存储系统和应用数据。在很多使用 eMMC 的产品中，GPP 都没有被启用，因为它在功能上与 UDA 类似，产品上直接使用 UDA 就可以满足需求。

4.1 容量大小

eMMC 最多可以支持 4 个 GPPs，每一个 GPP 的大小可以单独配置。用户可以通过设定 Extended CSD register 的以下三个 Field 来设 GPPx (x=1~4) 的容量大小：

GP_SIZE_MULT_x_2
GP_SIZE_MULT_x_1
GP_SIZE_MULT_x_0
GPPx 的容量计算公式如下：

Size = (GP_SIZE_MULT_x_2 * 2^16 + GP_SIZE_MULT_x_1 * 2^8 + GP_SIZE_MULT_x_0 * 2^0) * (Write protect group size)

Write protect group size = 512KB * HC_ERASE_GRP_SIZE * HC_WP_GRP_SIZE

eMMC 中，擦除和写保护都是按块进行的，上述表达式中的 HC_WP_GRP_SIZE 为写保护的操作块大小，HC_ERASE_GRP_SIZE 则为擦除操作的快的大小。
eMMC 芯片的 GPP 的配置通常是只能进行一次 (OTP)，一般会在产品量产阶段，在产线上进行。

4.2 分区属性

在这里插入图片描述

eMMC 标准中，为 GPP 定义了两类属性，Enhanced attribute 和 Extended attribute。每个 GPP 可以设定两类属性中的一种属性，不可以同时设定多个属性。

Enhanced attribute

Default, 未设定 Enhanced attribute。
Enhanced storage media， 设定 GPP 为 Enhanced storage media。
在 eMMC 标准中，实际上并未定义设定 Enhanced attribute 后对 eMMC 的影响。Enhanced attribute 的具体作用，由芯片制造商定义。
在实际的产品中，设定 Enhanced storage media 后，一般是把该分区的存储介质从 MLC 改变为 SLC，提高该分区的读写性能、寿命以及稳定性。

由于 1 个存储单元下，MLC 的容量是 SLC 的两倍，所以在总的存储单元数量一定的情况下，如果把原本为 MLC 的分区改变为 SLC，会减少 eMMC 的容量，就是说，此时 eMMC 的实际总容量比标称的总容量会小一点。（MLC 和 SLC 的细节可以参考 Flash Memory 章节内容）

Extended attribute

Default, 未设定 Extended attribute。
System code， 设定 GPP 为 System code 属性，该属性主要用在存放操作系统类的、很少进行擦写更新的分区。
Non-Persistent，设定 GPP 为 Non-Persistent 属性，该属性主要用于存储临时数据的分区，例如 tmp 目录所在分区、 swap 分区等。
在 eMMC 标准中，同样也没有定义设定 Extended attribute 后对 eMMC 的影响。

Extended attribute 的具体作用，由芯片制造商定义。Extended attribute 主要是跟分区的应用场景有关，厂商可以为不用应用场景的分区做不同的优化处理。

5. User Data Area

User Data Area (UDA) 通常是 eMMC 中最大的一个分区，是实际产品中，最主要的存储区域。

5.1 容量大小

UDA 的容量大小不需要设置，在配置完其他分区大小后，再扣除设置 Enhanced attribute 所损耗的容量，剩下的容量就是 UDA 的容量。

5.2 软件分区

为了更合理的管理数据，满足不同的应用需求，UDA 在实际产品中，会进行软件再分区。

目前主流的软件分区技术有 MBR（Master Boot Record）和 GPT（GUID Partition Table）两种。这两种分区技术的基本原理类似，如下图所示：
在这里插入图片描述

软件分区技术一般是将存储介质划分为多个区域，既 SW Partitions，然后通过一个 Partition Table 来维护这些 SW Partitions。

在 Partition Table 中，每一个条目都保存着一个 SW Partition 的起始地址、大小等的属性信息。

软件系统在启动后，会去扫描 Partition Table，获取存储介质上的各个 SW Partitions 信息，然后根据这些信息，将各个 Partitions 加载到系统中，进行数据存取。

MBR 和 GPT 此处不展开详细介绍，更多的细节可以参考 wikipedia 上 MBR 和 GPT 相关介绍。

5.3 区域属性

eMMC 标准中，支持为 UDA 中一个特定大小的区域设定 Enhanced attribute。与 GPP 中的 Enhanced attribute 相同，eMMC 标准也没有定义该区域设定 Enhanced attribute 后对 eMMC 的影响。

Enhanced attribute 的具体作用，由芯片制造商定义。

Enhanced attribute

Default, 未设定 Enhanced attribute。
Enhanced storage media， 设定该区域为 Enhanced storage media。
在实际的产品中，UDA 区域设定为 Enhanced storage media 后，一般是把该区域的存储介质从 MLC 改变为 SLC。

通常，产品中可以将某一个 SW Partition 设定为 Enhanced storage media，以获得更好的性能和健壮性。

6. eMMC 分区应用实例

在一个 Android 手机系统中，各个分区的呈现形式如下：

mmcblk0 为 eMMC 的块设备;
mmcblk0boot0 和 mmcblk0boot1 对应两个 Boot Area Partitions;
mmcblk0rpmb 则为 RPMB Partition，
mmcblk0px 为 UDA 划分出来的 SW Partitions;
如果存在 GPP，名称则为 mmcblk0gp1、mmcblk0gp2、mmcblk0gp3、mmcblk0gp4;
root@xxx:/ # ls /dev/block/mmcblk0*
/dev/block/mmcblk0
/dev/block/mmcblk0boot0
/dev/block/mmcblk0boot1
/dev/block/mmcblk0rpmb
/dev/block/mmcblk0p1
/dev/block/mmcblk0p2
/dev/block/mmcblk0p3
/dev/block/mmcblk0p4
/dev/block/mmcblk0p5
/dev/block/mmcblk0p6
/dev/block/mmcblk0p7
/dev/block/mmcblk0p8
/dev/block/mmcblk0p9
/dev/block/mmcblk0p10
/dev/block/mmcblk0p11
/dev/block/mmcblk0p12
/dev/block/mmcblk0p13
/dev/block/mmcblk0p14
/dev/block/mmcblk0p15
/dev/block/mmcblk0p16
/dev/block/mmcblk0p17
/dev/block/mmcblk0p18
/dev/block/mmcblk0p19
/dev/block/mmcblk0p20
/dev/block/mmcblk0p21
/dev/block/mmcblk0p22
/dev/block/mmcblk0p23
/dev/block/mmcblk0p24
/dev/block/mmcblk0p25
/dev/block/mmcblk0p26
/dev/block/mmcblk0p27
/dev/block/mmcblk0p28
/dev/block/mmcblk0p29
/dev/block/mmcblk0p30
/dev/block/mmcblk0p31
/dev/block/mmcblk0p32
每一个分区会根据实际的功能来设定名称。

root@xxx:/ # ls -l /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/
lrwxrwxrwx root root 2015-01-03 04:03 boot -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 2015-01-03 04:03 cache -> /dev/block/mmcblk0p30
lrwxrwxrwx root root 2015-01-03 04:03 custom -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2015-01-03 04:03 devinfo -> /dev/block/mmcblk0p28
lrwxrwxrwx root root 2015-01-03 04:03 expdb -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2015-01-03 04:03 flashinfo -> /dev/block/mmcblk0p32
lrwxrwxrwx root root 2015-01-03 04:03 frp -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2015-01-03 04:03 keystore -> /dev/block/mmcblk0p27
lrwxrwxrwx root root 2015-01-03 04:03 lk -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2015-01-03 04:03 lk2 -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 2015-01-03 04:03 logo -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 2015-01-03 04:03 md1arm7 -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2015-01-03 04:03 md1dsp -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2015-01-03 04:03 md1img -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2015-01-03 04:03 md3img -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2015-01-03 04:03 metadata -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2015-01-03 04:03 nvdata -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2015-01-03 04:03 nvram -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2015-01-03 04:03 oemkeystore -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2015-01-03 04:03 para -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2015-01-03 04:03 ppl -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2015-01-03 04:03 proinfo -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2015-01-03 04:03 protect1 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2015-01-03 04:03 protect2 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2015-01-03 04:03 recovery -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2015-01-03 04:03 rstinfo -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2015-01-03 04:03 seccfg -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2015-01-03 04:03 secro -> /dev/block/mmcblk0p26
lrwxrwxrwx root root 2015-01-03 04:03 system -> /dev/block/mmcblk0p29
lrwxrwxrwx root root 2015-01-03 04:03 tee1 -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 2015-01-03 04:03 tee2 -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 2015-01-03 04:03 userdata -> /dev/block/mmcblk0p31

7. 参考资料

Embedded Multi-Media Card (e•MMC) Electrical Standard (5.1) [PDF]
Disk partitioning [Web]
https://en.wikipedia.org/wiki/Disk_partitioning
Master Boot Record [Web]
GUID Partition Table [Web]
https://en.wikipedia.org/wiki/GUID_Partition_Table
转载于:https://www.cnblogs.com/smartjourneys/p/6653867.html

http://www.jinbuguo.com/storage/gpt.html

GPT 分区详解

保护MBR

保护MBR包含一个DOS分区表(LBA0)，只包含一个类型值为0xEE的分区项，在小于2TB的磁盘上，大小为整个磁盘；在更大的磁盘上，它的大小固定为2TB。它的作用是阻止不能识别GPT分区的磁盘工具试图对其进行分区或格式化等操作，所以该扇区被称为“保护MBR”。实际上，EFI根本不使用这个分区表。
在这里插入图片描述

EFI部分

EFI部分又可以分为4个区域：EFI信息区(GPT头)、分区表、GPT分区、备份区域。

EFI信息区(GPT头)

起始于磁盘的LBA1，通常也只占用这个单一扇区。其作用是定义分区表的位置和大小。GPT头还包含头和分区表的校验和，这样就可以及时发现错误。

分区表

分区表区域包含分区表项。这个区域由GPT头定义，一般占用磁盘LBA2～LBA33扇区。分区表中的每个分区项由起始地址、结束地址、类型值、名字、属性标志、GUID值组成。分区表建立后，128位的GUID对系统来说是唯一的。

GPT分区

最大的区域，由分配给分区的扇区组成。这个区域的起始和结束地址由GPT分区表定义。

备份区

备份区域位于磁盘的尾部，包含GPT头和分区表的备份。它占用GPT结束扇区和EFI结束扇区之间的33个扇区。其中最后一个扇区用来备份1号扇区的EFI信息，其余的32个扇区用来备份LBA2～LBA33扇区的分区表。

EFI信息区数据结构

EFI信息区位于磁盘的1号扇区(LBA1)，也称为GPT头。其具体结构如下表所示

EFI信息区结构
在这里插入图片描述
分区项
在这里插入图片描述
注意，扇区尺寸不能假定为512字节，也就是说，一个扇区内可能存放4个以上的分区项，也可能只存放一个分区项的一部分。也就是说，除了头两个扇区(LBA 0 和 LBA 1)之外，GPT规范仅定义了数据结构的尺寸，而不关心使用多少个扇区进行存储。

分区类型
在这里插入图片描述
Microsoft还进一步对分区的属性进行了细分：低位4字节表示与分区类型无关的属性，高位4字节表示与分区类型有关的属性。Microsoft目前使用了下列属性：

分区属性
在这里插入图片描述

F2FS文件系统一 设计背景及框架结构
F2FS文件系统二 实验分析f2fs文件系统
f2fs系列之二： 重要的数据结构
F2FS文件系统架构与原理分析(一)——设计背景与功能
F2FS文件系统架构与原理分析(二)——磁盘布局
F2FS文件系统架构与原理分析(三) ——文件索引树
F2FS文件系统架构与原理分析(四)——F2FS的目录结构与目录哈希
F2FS文件系统架构与原理分析(五)——元数据组织及管理
F2FS文件系统架构与原理分析(六)——块分配与空间管理
F2FS源码分析-1.1 [F2FS 元数据布局部分] F2FS文件系统的总体结构

MURKFREE
关注
  • 0
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
[Firefly-Linux] RK3568 Ubuntu固件分区详解
Systemcall名屋
12-01 2074
RK为了方便开发与产品定制，自己定义了一套固件的分区，这些分区信息存放在文件中，Firefly参考这个文件定义了自己的Ubuntu分区，文件为，存放于Linux_SDK的目录下；另外在Ubuntu固件打包的时候也会用到一个文件，文件名为，存放于Linux_SDK的目录下。下面我带领大家简要分析一下这两个文件！
DB-GPT DB-GPT.zip
06-16
DB-GPT.zip
Rockchip Uboot 自定义文件系统分区以及启动命令
luohaha66的博客
10-20 508
简要说明：启动时会先读取 devnum 的值，如果 devnum 的值为 0，则表示从 mmc 启动，为 1 则表示从 sd 卡启动，然后读取 boot_recovery 的值，如果其为 1，则设置 part_uuid 的值为备份文件系统的 uuid，否则设置其为用户文件系统的 uuid，然后运行 boot_fat 命令启动内核。如果需要从备份文件系统启动，则只需要在内核启动完成后，使用 fw_setenv 命令设置 boot_recovery 的值为 1 即可。
uboot与分区表
最新发布
qq_46032550的博客
03-28 562
uboot与分区表
GPT-3-Encoder:适用于GPT-2 GPT-3的Javascript BPE编码解码器
05-14
适用于GPT-2 / GPT-3的GPT-3-Encoder Javascript BPE编码解码器 关于 GPT-2和GPT-3使用字节对编码将文本转换为一系列整数以输入模型。 这是OpenAI原始python编码器/解码器的javascript实现，可在找到 用npm安装 npm install gpt-3-encoder 用法 兼容Node> = 12 const {encode, decode} = require('gpt-3-encoder') const str = 'This is an example sentence to try encoding out on!' const encoded = encode(str) console.log('Encoded this string looks like: ', encoded) console.log('We
Linux固件开发 | 几分钟看透GPT分区
Systemcall名屋
03-08 1784
保护MBR 保护MBR包含一个DOS分区表(LBA0)，只包含一个类型值为0xEE的分区项，在小于2TB的磁盘上，大小为整个磁盘；在更大的磁盘上，它的大小固定为2TB。它的作用是阻止不能识别GPT分区的磁盘工具试图对其进行分区或格式化等操作，所以该扇区被称为“保护MBR”。实际上，EFI根本不使用这个分区表。 EFI部分 EFI部分又可以分为4个区域：EFI信息区(GPT头)、分区表、GPT分区、备份区域。 EFI信息区(GPT头) 起始于磁盘的LBA1，通常也只占用这个单一扇区。其作用是定义分区表的位置和
uboot 分区表概念
星星之火
04-24 914
每个分区可以挂载为独立的文件系统，即允许磁盘不同的空间用作不同的功能，如一个分区用于OS，另一个分区用于存放用户数据；BIOS/UEFI为bootrom中固化的程序，在上电后首先执行，并根据分区表加载bootloader，并由bootloader引导os的启动。在嵌入式领域，soc的bootrom程序在上电后执行，并根据分区表加载uboot，由uboot引导os启动；在PC领域，常见的2种引导程序BIOS（对应MBR格式分区表）、UEFI（对应GPT格式分区表）；
RK3399 GPT分区
fhy00229390的博客
01-22 5212
RK3399 GPT分区前言一、RK3399烧写分区二、GPT分区1. MBR分区2. GPT分区总结参考资料 前言 之前学习s3c2440时，分区信息是保存在uboot的环境变量中。通过uboot的内核命令行给MTD层传递MTD分区信息, 内核读取到的分区信息始终和u-boot中的保持一致。 如： s3c2440分区信息 /* uboot */ $printenv bootargs=console=ttySAC0 root=/dev/mtdblock3 rootfstype=jffs2 mtdparts=
深度探索uboot
我的专栏
10-21 4508
概要 Uboot 是操作系统启动前的运行的一段引导程序，他主要负责初始化部分硬件，包括时钟、内存等等，加载内核、文件系统、设备树等到内存上，启动操作系统。当然uboot作用远不止这些，比如由于uboot是裸机单任务运行，我们也可以在这里面对硬件进行初步的测试、升级系统等等。 嵌入式开发中我们多多少少会涉及到uboot，所以还是有必要对这块做一些功课。我也是最近移植系统，遇到一些麻烦，对uboot做了一些研究，把他记录下来。本篇主要基于rockchip px...
uboot分区介绍
steel0205的专栏
03-08 464
uboot分区介绍
keras-gpt-2：加载GPT-2检查点并生成文本
02-03
凯拉斯GPT-2 [| ] 加载预训练的权重并使用预测。 安装 pip install keras-gpt-2 演示版 import os from keras_gpt_2 import load_trained_model_from_checkpoint , get_bpe_from_files , generate model_folder = ...
image-gpt:OpenAI图像GPT的PyTorch实现
04-13
图片GPT 图像GPT的PyTorch实施基于像素的纸张生成式预训练和随附的。 模型生成的来自测试集的半图像的完成。 输入第一列； 最后一栏是原始图片 iGPT-S已在CIFAR10上进行了预培训。 由于该模型仅在CIFAR10而非所有...
GPT2-Chinese.zip_gpt-2_gpt2 小模型_gpt2 模型下载_gpt2-Chinese_gpt2代码
07-15
中文的GPT2模型训练代码，基于Pytorch-Transformers，可以写诗，写新闻，写小说，或是训练通用语言模型等。
GPT-9804.pdf
07-28
安规高压Hi-Pot测试仪器说明书。安规高压Hi-Pot测试仪器说明书。安规高压Hi-Pot测试仪器说明书。
GPT自我揭秘GPT-3.5模型原理
04-25
ChatGPT是一个基于GPT-3.5架构的大型语言模型。GPT-3是一个由OpenAI开发的自然语言处理模型，使用了神经网络技术来生成自然语言文本。ChatGPT的设计初衷是作为一个智能对话系统，可以进行人机对话，提供服务和娱乐。...
经典网络模型系列——Swin-Transformer详细讲解与代码实现
hellozhxy的博客
10-19 2556
【代码】经典网络模型系列——Swin-Transformer详细讲解与代码实现。
2021-02-22
chocolate2018的博客
02-22 1621
TI jacinto uboot – 下 3.1.1.11. SATA 请注意 J721E平台不支持SATA。 U-boot中SATA和eSATA设备显示为SCSI设备. 3.1.1.11.1. 查看SATA设备 要查看U-boot看到的所有SCSI设备，可以使用命令“SCSI info”。 在AM57x通用EVM上运行时，此命令的输出如下所示。 scsi part Device 0: (0:0) Vendor: ATA Prod.: PLEXTOR PX-64M6M Rev: 1.08
Tina R329 swupdate OTA升级步骤
DOT小文哥的博客
08-17 1843
第一步： 编译路径执行make menucinfig和make ota_menucinfig中分别选中： （1）Allwinner > swupdate （2）Allwinner > swupdate > Swupdate Settings > General Configuration > MTD support （3）Allwinner > swupdate > Image Handlers > ubivol 第二步： sys_config.fex中的s
fdisk -lu后如何识别分区类型是MBR或者GPT
06-03
在Linux中，可以使用fdisk命令来查看磁盘分区的类型： 1. 使用fdisk -lu命令查看磁盘分区表： ``` sudo fdisk -lu ``` 该命令会列出所有分区的信息，其中的Disklabel列会显示磁盘分区类型，如果显示的是"DOS"，则代表是MBR分区表；如果显示的是"GPT"，则代表是GPT分区表。 2. 使用parted命令查看磁盘分区的类型： ``` sudo parted /dev/sda print ``` 该命令会列出磁盘的分区信息，其中的Partition Table列会显示磁盘分区类型，如果显示的是"msdos"，则代表是MBR分区表；如果显示的是"gpt"，则代表是GPT分区表。 通过以上命令，你可以确认磁盘分区是MBR还是GPT类型。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值