MTDPART_SIZ_FULL

最新推荐文章于 2024-09-05 21:51:10 发布
原创 最新推荐文章于 2024-09-05 21:51:10 发布 · 1.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#linux

本文介绍了MTD中的宏定义MTDPART_SIZ_FULL(0)，该宏被用作特殊偏移，指示文件尾部的位置。通过理解这个宏的作用，可以更好地掌握MTD分区配置的相关知识。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

linux建立MTD分区
04-24
学习linux下建立mtd分区必须的资料
x210的u-boot中的mtdpart
Android/Linux的专栏
10-24 2755
想用tftp引导Android内核但是却发现和Linux+Qt不太一样，它的u-boot打印信息是这样的： x210 # pri bootcmd=nand read C0008000 600000 400000; nand read 30A00000 B00000 180000; bootm C0008000 30A00000 mtdpart=80000 400000 3000000 boo
mtd分区
xgbing
02-15 5541
mtd_part结构： /* Our partition node structure */ struct mtd_part { struct mtd_info mtd; //分区的信息 struct mtd_info *master; //主分区 uint64_t offset; //该分区的偏移地址 int index; //分区号 struct list_head l
linux mtd - mtdpart.c
xgbing
03-18 2357
（1）add_mtd_partitions int add_mtd_partitions(struct mtd_info *master, 在flash驱动中已经初始化 const struct mtd_partition *parts, int nbparts) { struct mtd_par
linux2.6.28 MTD 内存技术设备(块设备)相关结构体源码分析
哈米的博客
09-05 689
//////////////////////include/linux/mtd/partitions.h/** Partition definition structure:** An array of struct partition is passed along with a MTD object to* add_mtd_partitions() to create them.** For each partition, these fields are available:* name
移值linux3.4.2内核之修改分区
qq_41936794的博客
08-03 459
前言 内核启动后的打印信息如下所示 看到内核中有8个分区,但是我们的uboot只有4个分区 修改内核分区 我们搜索"Boot Agent"字段,可以发现在以上文件出现过,我们可以断定应该是要修改common-smdk.c文件,因为它是一个比较通用的文件,我们进去查看该文件,可以看到里面有个数组smdk_default_nand_part[],内容如下所示: 所以我们必须修改该数组,修改为和我们uboot对应分区一致的分区布局 上面部分宏的定义,如下所示: MTDPART_OFS_RETAIN: 填
nand编程时的partable
04-03
.size = MTDPART_SIZ_FULL, } }; ``` 以上代码展示了三个主要组成部分：启动加载器区、内核映像存放位置以及根文件系统的预留空间大小分配情况。实际应用过程中还需要考虑更多因素比如坏块管理策略等额外需求。
linux2.6.28 MTD 内存技术设备(块设备)platform device源码分析
哈米的博客
09-05 1167
//////////////////arch/arm/mach-s3c6410/mach-smdk6410.c MACHINE_START(SMDK6410, "SMDK6410") /* Maintainer: Ben Dooks */ .phys_io = S3C_PA_UART & 0xfff00000, .io_pg_offst = (((u32)S3C_VA_UART...
35.驱动--MTD子系统
LingLinTianShang的博客
01-23 1334
35.驱动--MTD子系统
MTD分析
Mr.W的博客
01-16 2997
概述：本文对mtd的整个结构进行了分析，分析得并非很深入，但可以了解大体框架和目录结构，另外本文会对源码文件进行分析，大致描述其作用，文中关于oob相关部分并未涉及到，针对本文的内容中，如有不恰当的地方，请留言指教，多谢 3 驱动结构 3.1 源码结构 3.1.1 文件结构 drivers/mtd/： chips目录： nor flash的驱动程序位于该目录，目录下的文件包含nor flash的一些操作接口，其中nor flash分cfi和jedec两种，其他则是除前面两种以外的，cfi_cmdset_0
Linux内核4.14版本——mtd子系统(2)——原始设备层（mtdcore.c、mtdpart.c）
yangguoyu8023的博客
02-08 1305
mtd子系统
MTD子系统分析（一）————简介
yedushu的博客
07-18 792
MTD介绍 　　MTD，Memory Technology Device即内存技术设备 　　字符设备和块设备的区别在于前者只能被顺序读写，后者可以随机访问；同时，两者读写数据的基本单元不同。 　　字符设备，以字节为基本单位，在Linux中，字符设备实现的比较简单，不需要缓冲区即可直接读写，内核例程和用户态API一一对应，用户层的Read函数直接对应了内核中的Read例程，这种映射关系由字符设...
Bon分区、part分区以及mtd分区
开炉铸剑
10-13 1534
  从角度来分：bon分区是在物理上进行擦除分区，part以及mtd是在逻辑上进行定位。   bon命令用于对bon分区进行操作。bon分区是nand flash设备的一种简单的分区管理方式。vivi中使用bon分区时，会将相应的分区信息放在NAND Flash的最后0x4000（16k）个字节中。linux就是通过读取此地址区域的nand获得的bon分区表信息。linux启动时也会检测到
nandflash驱动之添加MTD设备与测试
fight_onlyfor_you的博客
04-05 668
接着上面的驱动程序讲，现在就要添加分区了 使用这个函数 第一个参数是mtd_info结构体，如果你只想把整个flash当作一个分区，就直接使用add_mtd_device就可以了 第二个参数是mtd_partition结构体，这个指针就像个数组一样，然后这个数组有多少项呢，这就是第三个参数nbparts了 所以说我们要构造这个mtd_partition这个数组 我们来看一
64M nandflash分区示意图
fulinux的博客
03-25 3320
这是我的64M的nandflash分区示意图涵盖的文件系统比较多，分区设置代码是在arch/arm/plat-s3c24xx/common-smdk.c： static struct mtd_partition smdk_default_nand_part[] = { [0] = { .name = "bootloader bin", .size
在内核中修改MTD分区
热门推荐
qingkongyeyue的博客
08-13 1万+
1、先解释一下什么是MTD Memory Technology Device,内存技术设备，如nand flash 2、为什么要修改MTD分区 用于存放不同大小的文件（如u-boot,params，uImage，root filesystem） 3、怎么知道在哪里修改分区  （1）看u-boot启动后出现的分区信息 （2）在内核中查找分区名字，如“Boot Agen
Linux MTD 源代码分析
rheostat的专栏
08-07 5444
Linux MTD 源代码分析           by Jim Zeus Version 0.1 2002/4/29             Copyright © 2002 Jim Zeus. Permission is granted to copy, distribute and/or modify this document under the term
#!/bin/sh #mount oem_app dir SYSCFG_oem_app_ubifs_MNT=/tmp/syscfg SLOT="$(find_system_slot)" echo "Active system$SLOT" # return 1 on failed 0 for success oem_app_ubifs_volume_support() { # for SDTIM support mtdpart_idx_oem_app="$(find_mtd_index oem_app$SLOT-mount)" if [ -z "$mtdpart_idx_oem_app" ] then mtdpart_idx_oem_app="$(find_mtd_index oem_app$SLOT)" if [ -z "$mtdpart_idx_oem_app" ] then # oem_app may has only one partition mtdpart_idx_oem_app="$(find_mtd_index oem_app)" [ -z "$mtdpart_idx_oem_app" ] && return 1 fi fi grep -qs ubifs /proc/filesystems || return 1 echo "found oem_app partition and ubifs support" return 0 } __oem_app_ubifs_mount() { recover_oem_app_ubifs=0 [ ! -e /dev/ubi2 ] && ubiattach /dev/ubi_ctrl -m $mtdpart_idx_oem_app -d 2 || recover_oem_app_ubifs=1 if [ $recover_oem_app_ubifs -eq 0 ] then ubi2_nod_id=`cat /sys/class/ubi/ubi2/dev | tr -s ":" " "` [ ! -e /dev/ubi2 ] && mknod /dev/ubi2 c ${ubi2_nod_id} if [ ! -e /sys/class/ubi/ubi2_0/dev ] then # no volume recover_oem_app_ubifs=1 else # check for "oem_app" volume ubi2_0_nod_id=`cat /sys/class/ubi/ubi2_0/dev | tr -s ":" " "` [ ! -e /dev/ubi2_0 ] && mknod /dev/ubi2_0 c ${ubi2_0_nod_id} { ubinfo /dev/ubi2_0 | grep "oem_app" ; } || \ recover_oem_app_ubifs=1 fi fi if [ $recover_oem_app_ubifs -eq 1 ] then echo "err: ubi attach failed, oem_app partition damaged?" ##need reboot and switch other slot fi mount -t ubifs -o ro,noatime,bulk_read ubi2_0 /oemapp return 0 } oem_app_ubifs_mount() { __oem_app_ubifs_mount || { echo "oem_app mount fail" #mtd erase oem_app$SLOT #__oem_app_ubifs_mount } return 0 } do_mount_oem_app_ubifs_overlay() { { oem_app_ubifs_volume_support && \ oem_app_ubifs_mount ; } } boot_hook_add preinit_main do_mount_oem_app_ubifs_overlay 解释下这个骄傲本的作用
最新发布
06-25
<think>我们正在分析一个嵌入式Linux系统中挂载oem_appUBIFS文件系统的脚本。根据之前的对话，我们已经知道挂载UBIFS文件系统需要几个步骤：关联MTD分区到UBI设备、创建UBI卷、格式化并挂载。现在用户提供了一个脚本片段，要求解释其功能和在系统启动中的作用。从用户提供的引用来看：引用[1]提到/etc/init.d/目录下的脚本在系统启动时用于初始化服务。因此，这个挂载脚本很可能位于/etc/init.d/中，在启动时执行。引用[2]和[3]提到了编译和打包过程，但与本问题关系不大。我们需要根据用户上一次的问题（关于mount命令）和我们的回答来推断。之前我们解释了mount命令的参数，现在用户想知道整个脚本的作用和流程。由于用户没有提供具体的脚本内容，我们只能根据典型情况来推测。在嵌入式Linux中，挂载UBIFS文件系统的脚本通常包含以下步骤：1.使用`ubiattach`命令将MTD分区关联到UBI设备。2.使用`ubimkvol`命令在UBI设备上创建逻辑卷（如果尚未创建）。3.使用`mount`命令挂载UBIFS文件系统。另外，在系统启动时，这样的脚本可能被放置在/etc/init.d/目录下，并在启动序列中调用（如通过inittab或rcS脚本）。因此，我们可以这样回答：该脚本的功能是在系统启动时挂载oem_app分区（UBIFS文件系统）到指定挂载点。执行流程如下：1.使用`ubiattach`命令将MTD分区（比如/dev/mtd3）关联到UBI设备（比如ubi2）。2.检查UBI设备上的逻辑卷（比如ubi2_0）是否存在，如果不存在则使用`ubimkvol`创建。3.使用`mount`命令以指定选项（如只读ro、禁用访问时间noatime、批量读取bulk_read）挂载该逻辑卷到挂载点（如/oemapp）。在系统启动过程中，该脚本通常由init进程调用，作为系统初始化的一部分，确保oem_app分区在应用程序启动前可用。同时，根据引用[1]，这样的脚本通常位于/etc/init.d/目录下，并在系统启动时执行[^1]。注意：由于用户没有提供具体的脚本内容，以上是典型流程的概述。现在，我们按照用户要求生成相关问题：1.如何确定UBIFS文件系统对应的MTD分区？2.在系统启动脚本中如何确保挂载顺序（比如在其他服务启动之前挂载）？3.如果挂载失败，系统会如何处理？最后，注意使用LaTeX格式（如果有数学表达式）和引用标识。</think>### 嵌入式Linux系统中挂载oem_app UBIFS脚本解析 该脚本主要用于在系统启动阶段挂载UBIFS格式的`oem_app`分区，其核心功能与执行流程如下： #### 一、脚本核心功能 1. **文件系统挂载** - 将UBI设备`ubi2_0`（对应闪存物理分区）挂载到`/oemapp`目录 - 启用关键优化选项： - `ro`：只读模式，保护OEM应用和配置文件不被篡改[^1] - `noatime`：禁用访问时间记录，减少闪存写入次数 - `bulk_read`：批量读取优化，提升大文件加载速度 2. **系统初始化支持** - 为`/etc/init.d/`中的服务脚本提供运行环境（如OEM应用程序） - 确保wpa_supplicant等依赖OEM分区的服务可正常启动[^3] 3. **资源管理** - 通过UBIFS的损耗均衡机制延长NAND闪存寿命 - 隔离OEM专用数据与系统核心分区 #### 二、执行流程详解 ```mermaid graph TD A[系统启动] --> B[ubiattach关联MTD分区] B --> C[ubimkvol创建逻辑卷] C --> D[执行mount脚本] D -->|参数：-t ubifs -o ro,noatime,bulk_read| E[挂载ubi2_0到/oemapp] E --> F[启动/etc/init.d服务] F --> G[加载wpa_supplicant等OEM应用] ``` 1. **预处理阶段** - `ubiattach /dev/ubi_ctrl -m 2`：将MTD分区2关联到UBI层 - `ubimkvol /dev/ubi2 -N oem_vol -s 100MiB`：创建逻辑卷（需在固件编译时配置[^2]） 2. **挂载阶段** ```bash mount -t ubifs -o ro,noatime,bulk_read ubi2_0 /oemapp ``` - 文件系统类型：`ubifs`（专为闪存设计） - 设备节点：`ubi2_0`（UBI设备2的卷0） - 挂载点：`/oemapp`（需在根文件系统预先创建） 3. **后置动作** - 触发`/etc/init.d/`中依赖`/oemapp`的服务脚本[^1] - 加载`wpa_supplicant`等OEM应用（编译时写入`/oemapp/bin`[^3]） #### 三、在系统启动中的作用 1. **安全隔离** - 只读挂载防止关键OEM配置被运行时修改 - 独立分区避免应用程序错误影响系统稳定性 2. **性能优化** - `bulk_read`提升Wi-Fi驱动等大文件加载速度[^3] - `noatime`减少元数据写入，延长闪存寿命 3. **服务管理** - 为初始化脚本提供可靠的执行环境[^1] - 支持模块化应用更新（替换UBI卷无需重刷系统） --- ### 相关问题 1. **如何确保UBIFS挂载在服务启动前完成？** （分析init脚本的顺序控制机制[^1]） 2. **编译阶段如何配置UBI卷大小？** （研究Application.mk中的分区定义[^2]） 3. **`bulk_read`优化对Wi-Fi连接速度的实际影响？** （测试wpa_supplicant加载时间差异[^3]） 4. **只读挂载下如何实现OEM应用更新？** （探讨UBI卷重映射或OverlayFS方案） [^1]: 系统初始化时需确保挂载完成再启动服务 [^2]: 卷大小需在编译阶段通过ubimkvol确定 [^3]: wpa_supplicant等应用依赖/oemapp中的二进制文件
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值