某Android 设备的物理存储（Nand）分区分析

最新推荐文章于 2022-08-11 16:40:21 发布

勤奋专注

最新推荐文章于 2022-08-11 16:40:21 发布

阅读量3.5k

点赞数

分类专栏： android 学习开发

本文链接：https://blog.csdn.net/do_script/article/details/8789638

版权

android 学习开发专栏收录该内容

57 篇文章 0 订阅

订阅专栏

只是记录自己的理解，难免有些错误，有时间会补充和更正。

以某具体 android 设备为例(Cortex A9双核 + 4GB iNand + 1GB DDR3)，

记录获取该设备存储分区信息的方法，获取驱动设备信息，主要让大家有一个形象的认识，不涉及驱动具体实现（据说4层）；

本文是从iNand存储的角度出发理解分区信息(YAFFS2)，涉及到基于RAM的文件系统(EXT4,VFS)，仅限于帮助理解物理存储分区。

一. 分区信息的读取

1. 获取分区及大小，执行命令 cat /proc/partitions, 执行结果见下面：

#本处的1block=1KB；不要和NAND里面的block概念（64pages or 128pages）混淆了。结合下面步骤2.中 mount 命令得到的对应关系，估算其 system 分区（即mtdblock8）大小为 1048576 * 1024 KB = 1GB

 shell@android:/ # cat /proc/partitions	 	 
   major minor  #blocks  name   
   31        0       4096 mtdblock0
   31        1       8192 mtdblock1
   31        2      16384 mtdblock2
   31        3      16384 mtdblock3
   31        4     393216 mtdblock4
   31        5     131072 mtdblock5
   31        6     524288 mtdblock6
   31        7       4096 mtdblock7
   31        8    1048576 mtdblock8
   31        9      16384 mtdblock9
   31       10    1482752 mtdblock10

2. 显示分区属性及对应情况执行 mount

从下面的执行返回可以看出 mtdblock8 对应 system 分区，文件系统是 ext4 ，权限是只读。

shell@android:/ # mount 
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mtdblock8 /system ext4 ro,noatime,nodiratime,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/block/mtdblock6 /data ext4 rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/block/mtdblock5 /cache ext4 rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered,noauto_da_alloc 0 0   
/dev/block/mtdblock9 /oem ext4 rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered,noauto_da_alloc 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
/dev/block/vold/31:10 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/31:10 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

3. 执行命令 busybox df -h #如果没有busybox push进去一个，chmod之后到该文件夹下执行这个命令。

其实第一步的手工计算是没有必要的，就一目了然了，但也验证了我们的计算没错。^&^

     shell@android:/sdcard # busybox df -h
     Filesystem                Size      Used Available Use% Mounted on
     tmpfs                   438.0M     36.0k    438.0M   0% /dev
     tmpfs                   438.0M         0    438.0M   0% /mnt/asec
     tmpfs                   438.0M         0    438.0M   0% /mnt/obb
     /dev/block/mtdblock8   1023.2M    497.6M    525.6M  49% /system
     /dev/block/mtdblock6    503.9M    155.3M    348.7M  31% /data
     /dev/block/mtdblock5    126.0M      4.0M    121.9M   3% /cache
     /dev/block/mtdblock9     15.7M      4.0M     11.7M  26% /oem
     /dev/block/vold/31:10     1.4G    269.6M      1.1G  19% /mnt/sdcard                               
     /dev/block/vold/31:10     1.4G    269.6M      1.1G  19% /mnt/secure/asec

二：分区的创建过程，形象起见，从上层说起。

1. 创建映射，将底层创建好的块设备加载。这一步很简单，使用mount命令，指定参数创建。

具体是通过在 init.rc 或者 init.YourProject.rc 中添加，而init.rc 是由 android第一个被启动的程序 init去解释执行的，非本文内容。

    on fs
    # mount mtd partitions
    mount ext4 mtd@system /system wait ro noatime nodiratime noauto_da_alloc
    start readahead
    mount ext4 mtd@userdata /data wait noatime nodiratime nosuid nodev noauto_da_alloc

2. 驱动创建块设备，这里是MTD驱动，真正涉及驱动代码，本文只简单的说能形象认知的部分。

2.1 查看驱动产生的block设备，得到如下返回信息，只关注 mtdblockX就可以，是可读写的block设备。

	 shell@android:/dev/block # ls -l
   ls -l
   brw------- root     root       7,   0  loop0
   brw------- root     root       7,   1  loop1
   brw------- root     root       7,   2  loop2
   brw------- root     root       7,   3  loop3
   brw------- root     root       7,   4  loop4
   brw------- root     root       7,   5  loop5
   brw------- root     root       7,   6  loop6
   brw------- root     root       7,   7  loop7
   drwxr-xr-x root     root               mtd
   brw------- root     root      31,   0  mtdblock0
   brw------- root     root      31,   1  mtdblock1
   brw------- root     root      31,  10  mtdblock10
   brw------- root     root      31,   2  mtdblock2
   brw------- root     root      31,   3  mtdblock3
   brw------- root     root      31,   4  mtdblock4
   brw------- root     root      31,   5  mtdblock5
   brw------- root     root      31,   6  mtdblock6
   brw------- root     root      31,   7  mtdblock7
   brw------- root     root      31,   8  mtdblock8
   brw------- root     root      31,   9  mtdblock9
   drwx------ root     root               vold

继续深入到子目录 mtd/by-name 获取到如下信息，是软链接到 mtdblockX 的某些名字，这些名字使用场景本文不再深究，应该是RAM中调用有关系。

   shell@android:/dev/block # cd mtd/by-name
   cd mtd/by-name
   shell@android:/dev/block/mtd/by-name # ls -l
   ls -l
   lrwxrwxrwx root     root      backup -> /dev/block/mtdblock4
   lrwxrwxrwx root     root      boot -> /dev/block/mtdblock2
   lrwxrwxrwx root     root      cache -> /dev/block/mtdblock5
   lrwxrwxrwx root     root      kernel -> /dev/block/mtdblock1
   lrwxrwxrwx root     root      kpanic -> /dev/block/mtdblock7
   lrwxrwxrwx root     root      misc -> /dev/block/mtdblock0
   lrwxrwxrwx root     root      oem -> /dev/block/mtdblock9
   lrwxrwxrwx root     root      recovery -> /dev/block/mtdblock3
   lrwxrwxrwx root     root      system -> /dev/block/mtdblock8
   lrwxrwxrwx root     root      user -> /dev/block/mtdblock10
   lrwxrwxrwx root     root      userdata -> /dev/block/mtdblock6

2.2 与虚拟内存空间的关系

虚拟内存是经过MMU管理的4G内存空间，是一个逻辑内存的线性映射，而只有MMU和cache才是ARM core必须集成的，只能说神奇的MMU；

下面的信息是 ./kernel/drivers/mtd/mtdpart.c 中 printk 出来的；

    Creating 11 MTD partitions on "YOUR_DEVICE_DRIVER_NAME":
    0x000000400000-0x000000800000 : "misc"
    0x000000800000-0x000001000000 : "kernel"    #8MB~16MB = 8MB
    0x000001000000-0x000002000000 : "boot"
    0x000002000000-0x000003000000 : "recovery"
    0x000003000000-0x00001b000000 : "backup"
    0x00001b000000-0x000023000000 : "cache"
    0x000023000000-0x000043000000 : "userdata"   #512MB 
    0x000043000000-0x000043400000 : "kpanic"
    0x000043400000-0x000083400000 : "system"     #1024MB
    0x000087400000-0x000088400000 : "oem"        #2164MB~2180MB = 16MB
    0x000088400000-0x0000e2c00000 : "user"       #2180MB~3628MB = 1448MB

至于上面显示的内存地址为什么是 12*4 = 48bit，估计是高位内存预留，即最大内存可支持 2^4 * 4GB = 64GB；

由于本处高16bit都是0，所以最大虚拟内存还是4GB，与本文无关，忽略。

2.3 iomem空间信息

对外部硬件的读取是io口映射到io memory的方式来进行的，而x86平台的ioports在arm版的linux下仅保留了节点。

从下面的地址范围可以看出

0x1009 0000 ~ 0x1050 3fff 在backup区；

0x2001 8000 ~ 0x2007 bfff 在cache区；

0x6000 0000 ~ 0x8edf ffff 跨越 system / oem / user 三个区。

shell@android:/ # cat /proc/iomem
   cat /proc/iomem
   10090000-10090097 : Mali-400 GP
   10091000-1009102f : Mali-400 L2 cache
   10093000-10093023 : Mali-400 MMU for GP
   10094000-10094023 : Mali-400 MMU for PP 0
   10095000-10095023 : Mali-400 MMU for PP 1
   10096000-10096023 : Mali-400 MMU for PP 2
   10097000-10097023 : Mali-400 MMU for PP 3
   10098000-100990ef : Mali-400 PP 0
   1009a000-1009b0ef : Mali-400 PP 1
   1009c000-1009d0ef : Mali-400 PP 2
   1009e000-1009f0ef : Mali-400 PP 3
   10104000-1010428f : hx280enc
   10104400-10104593 : vdpu_io
   10108000-10109fff : rk-camera-rk30.33
     10108000-10109fff : rk-camera-rk30
   1010c000-1010dfff : lcdc0 reg
     1010c000-1010dfff : rk30-lcdc
   1010e000-1010ffff : lcdc1 reg
   10110000-10113fff : rk29-ipp
   10114000-10115fff : rga
     10114000-10115fff : rga_io
   10118000-10119fff : rk29_i2s.0
     10118000-10119fff : rk29_i2s
   10124000-10125fff : rk_serial.0
     10124000-10125fff : rk_serial
   10180000-101bffff : usb20_otg
   101c0000-101fffff : usb20_host
   10214000-10217fff : rk29_sdmmc.0
   10500000-10503fff : rk29xxnand
   20018000-2001bfff : rk29-pl330.1
     20018000-2001bfff : rk29-pl330
   2002d000-2002dfff : rk30_i2c.0
     2002d000-2002dfff : rk30_i2c
   2002f000-2002ffff : rk30_i2c.1
     2002f000-2002ffff : rk30_i2c
   20056000-20057fff : rk30_i2c.2
     20056000-20057fff : rk30_i2c
   2005a000-2005bfff : rk30_i2c.3
     2005a000-2005bfff : rk30_i2c
   2005e000-2005ffff : rk30_i2c.4
     2005e000-2005ffff : rk30_i2c
   20060000-20063fff : rk30-tsadc
     20060000-20063fff : rk30-tsadc
   20068000-2006bfff : rk_serial.3
     20068000-2006bfff : rk_serial
   2006c000-2006ffff : rk30-adc
     2006c000-2006ffff : rk30-adc
   20078000-2007bfff : rk29-pl330.2
     20078000-2007bfff : rk29-pl330
   60000000-8edfffff : System RAM
     604c5000-60a7013b : Kernel text
     60a72000-615dc217 : Kernel data
   8f400000-8fffffff : fb2 buf
   90000000-90bfffff : ipp buf
   90c00000-917fffff : fb0 buf
     90c00000-917fffff : rk-fb
   96800000-9fffffff : System RAM

2.4 ioports 信息

ARM嵌入式Linux已经很少使用，所以打印出来是空返回。

shell@android:/ # cat /proc/ioports
cat /proc/ioports
shell@android:/ #

勤奋专注

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
某Android 设备的物理存储（Nand）分区分析

只是记录自己的理解，难免有些错误，有时间会补充和更正。以某具体 android 设备为例(Cortex A9双核 + 4GB iNand + 1GB DDR3)，记录获取该设备存储分区信息的方法，获取驱动设备信息，主要让大家有一个形象的认识，不涉及驱动具体实现（据说4层）；本文是从iNand存储的角度出发理解分区信息(YAFFS2)，涉及到基于RAM的文件系统(EXT4,VFS)，
复制链接

扫一扫