1. 项目概述为什么我们需要调整eMMC分区如果你正在使用像ELF 2这样基于RK3588这类高性能处理器的开发板大概率会遇到一个非常实际的问题板载eMMC存储的默认分区方案可能并不完全符合你的项目需求。比如默认的根文件系统分区rootfs可能太小导致你无法安装更多的系统软件或存放大型数据集而用户数据分区userdata又可能分配得过大造成了存储空间的浪费。尤其是在进行AI应用开发、边缘计算或者构建复杂的嵌入式系统时一个合理的存储布局是系统稳定和高效运行的基础。调整eMMC分区本质上是对嵌入式设备的“硬盘”进行重新规划。这不同于在PC上使用图形化工具调整分区那么简单它涉及到修改引导参数、重新打包系统镜像等一系列底层操作。很多开发者尤其是刚接触嵌入式Linux的朋友可能会觉得这个过程有些“黑盒”和危险担心操作失误导致开发板“变砖”。实际上只要理解了其背后的原理和规则这个过程是清晰且可控的。本文将基于ELF 2开发板的官方资料为你彻底拆解eMMC分区调整的全过程从原理分析、参数计算到实操验证并附上我踩过的一些坑和总结的经验技巧让你能安全、自信地定制属于自己的存储方案。2. 核心原理理解parameter.txt与分区表在动手修改之前我们必须先搞清楚我们修改的到底是什么以及它如何影响系统。这是避免“盲操作”导致系统无法启动的关键。2.1 parameter.txt文件的作用在RK3588平台的开发板包括ELF 2上parameter.txt文件是一个至关重要的配置文件。它并不是一个在系统运行时才读取的普通文本文件而是被打包进最终的固件镜像update.img中。当开发板上电Bootloader通常是U-Boot在初始化阶段就会从存储设备的特定位置读取这个文件并根据其中的指令来设置内存布局、内核命令行参数以及最关键的分区表信息。你可以把它理解为写给Bootloader的一封“启动指南信”。这封信里详细说明了“硬盘eMMC从哪个地址开始是U-Boot的家从哪个地址开始是内核的家文件系统又住在哪里。” 如果这封信写错了地址Bootloader就会找不到对应的“住户”系统自然就无法启动。2.2 分区表格式深度解析让我们仔细看看ELF 2默认的parameter.txt中CMDLINE这一行它是所有秘密的所在CMDLINE: mtdparts:0x000020000x00004000(uboot),0x000020000x00006000(misc),0x000200000x00008000(boot),0x000400000x00028000(recovery),0x000100000x00068000(backup),0x01c000000x00078000(rootfs),0x000400000x01c78000(oem),-0x01cb8000(userdata:grow)这个字符串定义了一个名为mtdparts的内核命令行参数其格式遵循sizeoffset(name)的规则。我们来逐一拆解size(分区大小)以十六进制表示单位是扇区。1个扇区 512字节。这是所有计算的基础务必牢记。例如0x00002000换算成十进制是8192个扇区。那么它的字节大小就是8192 * 512 4,194,304字节也就是4MB。offset(起始地址)同样以十六进制扇区数表示代表该分区从存储设备的哪个逻辑扇区开始。例如0x00004000表示从第0x4000十进制16384个扇区开始。name(分区名)括号内的名字如ubootbootrootfs等用于在系统和Bootloader中标识这个分区。几个关键分区的角色uboot: 存放Bootloader负责最基础的硬件初始化和加载内核。boot: 通常存放Linux内核镜像Image和设备树文件.dtb。rootfs:根文件系统分区这是系统的“C盘”包含了整个操作系统的基础文件、库、配置文件和你安装的软件。userdata:用户数据分区这是给应用程序使用的“D盘”用于存放用户数据、日志、数据库以及你的应用程序本身。末尾的:grow关键字表示这个分区可以“增长”即占用剩余的所有空间在旧格式中常用GPT分区表下意义略有不同但此处遵循此约定。2.3 修改分区的核心规则与“安全边界”官方文档提到了几条修改规则这里我结合自己的经验再强调和解释一下地址连续性规则这是最核心、最容易出错的规则。整个存储空间被视为一个连续的线性地址空间。下一个分区的起始地址必须等于上一个分区的起始地址加上其分区大小。如果你增大了rootfs的大小那么它后面的oem和userdata分区的起始地址必须随之向后移动。否则地址就会重叠导致数据覆盖和系统崩溃。4MB对齐原则官方建议分区大小是4MB8192扇区的整数倍。这并非强制但强烈建议遵守。原因有二一是与Flash存储器的擦除块大小对齐可以提高读写效率和寿命二是与内存页对齐有利于操作系统内核进行高效的内存管理。不对齐虽然可能也能工作但会在性能和稳定性上埋下隐患。计算单位统一所有计算请统一使用扇区Sector作为单位并在parameter.txt中以十六进制表示。避免在字节、KB、MB、GB之间来回换算时出错。我的习惯是先确定想要的大小如28GB换算成字节再除以512得到扇区数最后转换成十六进制。最后一个分区的“grow”对于最后一个分区通常是userdata其大小用-表示意为占用剩余所有空间。同时需要保留:grow标识。在你调整了前面分区的大小后这个分区会自动适应新的剩余空间。注意修改parameter.txt并重新烧录后仅仅改变了分区表。它就像重新画了一张硬盘的“分区规划图”。但是原来分区里的数据比如rootfs里的系统文件并不会自动迁移或扩容。你需要通过后续步骤通常是重新烧录完整的系统镜像或者使用resize2fs等工具在线扩容来让文件系统实际占用新的空间。本文演示的“调整rootfs为28GB”并打包烧录update.img通常意味着你会烧录一个包含了已按新分区表布局好的文件系统内容的完整镜像。3. 实战演练将rootfs分区扩容至28GB现在我们以最经典的需求——扩大根文件系统分区为例进行一步步的实战操作。假设我们觉得默认的rootfs不够用希望将其扩大到28GB以便安装更多开发工具和库。3.1 准备工作与环境确认在开始修改之前请确保你的开发环境是就绪的获取SDK源码你已经从ElfBoard或相关渠道获取了ELF 2开发板的Linux SDK源码。完成基础编译非常重要如果你是首次使用这份SDK或者之前没有进行过全编译请务必先参考官方文档《ELF 2开发板编译手册》完成一次完整的系统镜像构建。这能确保你的编译环境、工具链和依赖包都是正确的避免在修改分区后打包镜像时出现意外错误。定位关键文件找到SDK目录下的分区表文件通常路径是ELF2-linux-source/rockdev/parameter.txt。在修改前强烈建议先备份这个文件cp ELF2-linux-source/rockdev/parameter.txt ELF2-linux-source/rockdev/parameter.txt.backup3.2 精确计算扇区、字节与十六进制的转换这是整个过程中最需要细心的一步。我们的目标是将rootfs分区大小设置为28GB。第一步将目标大小转换为字节。这里要特别注意单位换算。在计算机存储中1GB 1024MB1MB 1024KB1KB 1024Byte。 所以28GB 28 * 1024 * 1024 * 1024 Bytes 30,064,771,072 Bytes。第二步将字节数转换为扇区数。已知1扇区 512字节。 扇区数 总字节数 / 每扇区字节数 30,064,771,072 / 512 58,720,256 个扇区。 这个数字看起来很大但它是精确的。第三步将十进制扇区数转换为十六进制。我们需要将58,720,256转换为十六进制以便填入parameter.txt。可以使用计算器程序员模式或者Python快速计算python3 -c “print(hex(58720256))”输出结果为0x3800000。 所以新的rootfs分区大小就是0x03800000个扇区通常保留前导零以保持格式美观。3.3 修改parameter.txt文件现在我们基于默认分区表计算新的起始地址链。默认情况如下分区名原大小 (扇区)原起始地址 (扇区)计算过程rootfs0x01c000000x00078000已知oem0x000400000x01c780000x00078000 0x01c00000 0x01c78000userdata-0x01cb80000x01c78000 0x00040000 0x01cb8000我们要将rootfs大小从0x01c00000改为0x03800000。那么后续分区的起始地址必须重新计算rootfs分区起始地址不变仍为0x00078000。大小更新为0x03800000。oem分区大小不变仍为0x00040000。其新的起始地址rootfs新起始地址 rootfs新大小 0x00078000 0x03800000 0x03878000。userdata分区大小仍为-。其新的起始地址oem新起始地址 oem大小 0x03878000 0x00040000 0x038b8000。打开ELF2-linux-source/rockdev/parameter.txt文件找到CMDLINE一行将其修改为CMDLINE: mtdparts:0x000020000x00004000(uboot),0x000020000x00006000(misc),0x000200000x00008000(boot),0x000400000x00028000(recovery),0x000100000x00068000(backup),0x038000000x00078000(rootfs),0x000400000x03878000(oem),-0x038b8000(userdata:grow)请注意parameter.txt文件末尾可能还有uuid等字段这些是文件系统的唯一标识符修改分区大小时通常不需要动它们保持原样即可。3.4 重新打包与烧录系统镜像修改完parameter.txt后它并不会立即生效。我们需要将它打包进完整的系统镜像中。重新打包update.img在SDK根目录下运行完整的镜像打包命令。具体命令可能因SDK版本而异通常类似于./build.sh updateimg或./mkimage.sh。请务必参考你的SDK中的编译文档。这个过程会读取你刚修改的parameter.txt并按照新的分区布局将内核、根文件系统等组件打包成一个新的update.img文件通常生成在rockdev/目录下。烧录镜像到开发板将ELF 2开发板进入Loader模式通常是通过按住某个按键再上电或使用命令sudo rkdeveloptool db加载Loader。使用瑞芯微官方工具如rkdeveloptool或 Windows下的RKDevTool进行烧录。关键点烧录时选择“Loader”模式下的“升级固件”选项然后选中新生成的update.img。千万不要只烧录parameter分区因为分区表变化后所有分区的相对位置都变了必须烧录完整的镜像确保文件系统被正确地放置到新的分区地址上。烧录过程会自动擦除整个eMMC并写入新的分区表和系统数据。因此烧录前请确认已备份开发板上所有重要数据。3.5 验证分区调整结果烧录完成后启动开发板进入系统。我们可以通过命令行工具验证分区是否已按预期调整。使用fdisk -l命令这个命令会列出所有块设备的分区表信息。找到你的eMMC设备通常是/dev/mmcblk0或/dev/mmcblk1。sudo fdisk -l /dev/mmcblk0在输出中你应该能看到一个分区的大小约为28GB显示为29G或28G左右因为计算方式差异其标签或序号对应着你的rootfs。使用lsblk命令这个命令以更清晰的树状图显示块设备能直观看到分区大小。lsblk查看对应设备的分区列表确认rootfs分区可能挂载在/的SIZE字段是否已变为28G左右。检查文件系统实际大小分区大小调整了但上面的文件系统未必立即填满新空间。对于ext4文件系统可以使用df -h查看挂载点容量并使用resize2fs命令来在线扩展文件系统以填满分区注意此操作有风险建议在确保数据已备份的新烧录系统中进行。# 查看根分区使用情况 df -h / # 如果分区已扩大但文件系统未扩展可以尝试假设rootfs是 /dev/mmcblk0p6 sudo resize2fs /dev/mmcblk0p6重要提示如果你烧录的是全新的、已根据新分区表制作好的系统镜像那么文件系统在烧录时就已经是扩容后的状态无需再执行resize2fs。4. 进阶技巧与避坑指南掌握了基本操作后下面分享一些能让你事半功倍、避免踩坑的进阶经验。4.1 分区规划策略不只是调大rootfs调整分区不应该只是“缺啥补啥”而应该有一个通盘考虑。对于RK3588这类性能强大的平台常见的项目分区规划思路如下AI项目rootfs需要足够大用于安装庞大的深度学习框架如TensorFlow, PyTorch、CUDA库、OpenCV等。userdata分区也要预留充足空间用于存放模型文件、数据集和推理结果。多媒体或边缘服务器如果应用涉及大量视频录制、图片缓存或日志记录可以适当缩小rootfs保证系统运行即可将大部分空间分配给userdata甚至可以考虑为日志或媒体文件创建独立的分区。双系统或恢复系统如果设计需要保留完整的恢复系统recovery分区切勿随意缩小该分区。boot分区也要保证能存放可能较大的内核和多个设备树文件。一个简单的规划表格可以帮助你理清思路分区建议大小主要用途调整考量uboot固定 (4MB)Bootloader绝对不要修改misc固定 (4MB)恢复系统通信一般不动boot32MB - 128MB内核、设备树、启动脚本确保能放下所有内核版本recovery256MB恢复系统镜像如需强大恢复功能可适当调大backup固定 (32MB)备份一般不动rootfs2GB - 32GB操作系统、基础软件根据安装的软件包数量决定oem固定 (128MB)厂商定制数据一般不动userdata剩余所有空间用户应用和数据项目数据的主要存放地4.2 常见问题排查与解决实录在实际操作中你可能会遇到以下问题问题1修改parameter.txt后烧录镜像失败工具报错“下载IDB失败”或“校验失败”。可能原因parameter.txt文件格式错误例如十六进制数写错、少了逗号、括号不匹配、地址计算错误导致重叠或溢出。排查步骤逐字符检查仔细核对修改的那一行特别是数字和标点。建议使用有语法高亮的文本编辑器。地址链验证将每个分区的起始地址大小手工计算一遍确保等于下一个分区的起始地址一直计算到最后一个分区。使用校验脚本有些SDK会提供检查parameter.txt格式的脚本运行一下。还原测试用之前备份的parameter.txt.backup替换回去重新打包烧录。如果成功则证明问题出在你的修改上。问题2系统能启动但无法挂载根文件系统卡在内核启动日志提示“VFS: Unable to mount root fs”。可能原因这是最典型的分区表与文件系统不匹配问题。你修改了parameter.txt中的rootfs地址但打包进update.img的根文件系统镜像如rootfs.img并没有被放置到新的地址上或者你只烧录了parameter分区而没有烧录完整的、包含已重新布局的根文件系统的update.img。解决方案必须重新打包完整的update.img并完整烧录。确保编译打包系统读取的是你修改后的parameter.txt。问题3使用fdisk -l查看分区大小正确但df -h显示的文件系统容量没变。可能原因分区表Partition Table已经扩大但分区内的文件系统File System本身还没有扩展。这就像给一个房子划了更大的宅基地分区但房子文件系统本身还是原来那么大。解决方案对于ext2/3/4文件系统可以使用resize2fs命令在线扩展。操作前务必确认分区未被损坏且数据已备份。# 首先使用 lsblk 或 fdisk -l 确认 rootfs 对应的实际设备节点例如 /dev/mmcblk0p6 sudo umount /dev/mmcblk0p6 # 如果可能先卸载。根分区无法卸载需在Live环境或恢复模式下操作。 sudo e2fsck -f /dev/mmcblk0p6 # 强制检查文件系统 sudo resize2fs /dev/mmcblk0p6 # 扩展文件系统以填满分区 sudo mount /dev/mmcblk0p6 /mnt # 重新挂载检查 df -h /mnt最稳妥的做法在SDK编译阶段就确保根文件系统镜像rootfs.img是根据新的分区大小生成的这样烧录后无需二次处理。问题4调整后userdata分区不见了或者大小不对。可能原因修改过程中userdata分区的起始地址计算错误或者忘记了最后的:grow标识。排查步骤重新检查parameter.txt中userdata的起始地址计算过程并确认其格式为-起始地址(userdata:grow)。4.3 高阶安全操作备份与恢复在进行任何分区操作前备份是黄金法则。备份原始完整镜像在修改之前如果开发板上已有重要数据可以使用rkdeveloptool的read命令将整个eMMC读取出来备份成镜像文件。这是一个底位操作能完整保留所有分区和数据。sudo rkdeveloptool rl 0x0 0x40000000 backup.img # 示例大小需根据eMMC容量调整备份parameter分区单独备份分区表也是一个好习惯。sudo rkdeveloptool rp parameter parameter_backup.bin制作“安全”的parameter.txt在SDK中保留一个经过验证的、能正常启动的parameter.txt副本。当你实验新分区布局导致无法启动时可以快速通过仅烧录parameter分区的方式回退到这个安全版本注意仅回退分区表可能导致文件系统错位最安全还是用完整备份恢复。修改嵌入式设备的分区表是一项底层且关键的操作它要求精确和谨慎。通过理解parameter.txt的工作原理掌握扇区地址的计算方法并遵循完整的打包烧录流程你就可以摆脱默认分区的束缚为你的ELF 2开发板量身定制最合适的存储空间布局。记住每次修改前做好备份计算后双重检查你就能在充分发挥硬件潜力的道路上稳步前行。
RK3588开发板eMMC分区调整实战：从parameter.txt原理到28GB rootfs扩容
发布时间：2026/5/16 14:48:25
1. 项目概述为什么我们需要调整eMMC分区如果你正在使用像ELF 2这样基于RK3588这类高性能处理器的开发板大概率会遇到一个非常实际的问题板载eMMC存储的默认分区方案可能并不完全符合你的项目需求。比如默认的根文件系统分区rootfs可能太小导致你无法安装更多的系统软件或存放大型数据集而用户数据分区userdata又可能分配得过大造成了存储空间的浪费。尤其是在进行AI应用开发、边缘计算或者构建复杂的嵌入式系统时一个合理的存储布局是系统稳定和高效运行的基础。调整eMMC分区本质上是对嵌入式设备的“硬盘”进行重新规划。这不同于在PC上使用图形化工具调整分区那么简单它涉及到修改引导参数、重新打包系统镜像等一系列底层操作。很多开发者尤其是刚接触嵌入式Linux的朋友可能会觉得这个过程有些“黑盒”和危险担心操作失误导致开发板“变砖”。实际上只要理解了其背后的原理和规则这个过程是清晰且可控的。本文将基于ELF 2开发板的官方资料为你彻底拆解eMMC分区调整的全过程从原理分析、参数计算到实操验证并附上我踩过的一些坑和总结的经验技巧让你能安全、自信地定制属于自己的存储方案。2. 核心原理理解parameter.txt与分区表在动手修改之前我们必须先搞清楚我们修改的到底是什么以及它如何影响系统。这是避免“盲操作”导致系统无法启动的关键。2.1 parameter.txt文件的作用在RK3588平台的开发板包括ELF 2上parameter.txt文件是一个至关重要的配置文件。它并不是一个在系统运行时才读取的普通文本文件而是被打包进最终的固件镜像update.img中。当开发板上电Bootloader通常是U-Boot在初始化阶段就会从存储设备的特定位置读取这个文件并根据其中的指令来设置内存布局、内核命令行参数以及最关键的分区表信息。你可以把它理解为写给Bootloader的一封“启动指南信”。这封信里详细说明了“硬盘eMMC从哪个地址开始是U-Boot的家从哪个地址开始是内核的家文件系统又住在哪里。” 如果这封信写错了地址Bootloader就会找不到对应的“住户”系统自然就无法启动。2.2 分区表格式深度解析让我们仔细看看ELF 2默认的parameter.txt中CMDLINE这一行它是所有秘密的所在CMDLINE: mtdparts:0x000020000x00004000(uboot),0x000020000x00006000(misc),0x000200000x00008000(boot),0x000400000x00028000(recovery),0x000100000x00068000(backup),0x01c000000x00078000(rootfs),0x000400000x01c78000(oem),-0x01cb8000(userdata:grow)这个字符串定义了一个名为mtdparts的内核命令行参数其格式遵循sizeoffset(name)的规则。我们来逐一拆解size(分区大小)以十六进制表示单位是扇区。1个扇区 512字节。这是所有计算的基础务必牢记。例如0x00002000换算成十进制是8192个扇区。那么它的字节大小就是8192 * 512 4,194,304字节也就是4MB。offset(起始地址)同样以十六进制扇区数表示代表该分区从存储设备的哪个逻辑扇区开始。例如0x00004000表示从第0x4000十进制16384个扇区开始。name(分区名)括号内的名字如ubootbootrootfs等用于在系统和Bootloader中标识这个分区。几个关键分区的角色uboot: 存放Bootloader负责最基础的硬件初始化和加载内核。boot: 通常存放Linux内核镜像Image和设备树文件.dtb。rootfs:根文件系统分区这是系统的“C盘”包含了整个操作系统的基础文件、库、配置文件和你安装的软件。userdata:用户数据分区这是给应用程序使用的“D盘”用于存放用户数据、日志、数据库以及你的应用程序本身。末尾的:grow关键字表示这个分区可以“增长”即占用剩余的所有空间在旧格式中常用GPT分区表下意义略有不同但此处遵循此约定。2.3 修改分区的核心规则与“安全边界”官方文档提到了几条修改规则这里我结合自己的经验再强调和解释一下地址连续性规则这是最核心、最容易出错的规则。整个存储空间被视为一个连续的线性地址空间。下一个分区的起始地址必须等于上一个分区的起始地址加上其分区大小。如果你增大了rootfs的大小那么它后面的oem和userdata分区的起始地址必须随之向后移动。否则地址就会重叠导致数据覆盖和系统崩溃。4MB对齐原则官方建议分区大小是4MB8192扇区的整数倍。这并非强制但强烈建议遵守。原因有二一是与Flash存储器的擦除块大小对齐可以提高读写效率和寿命二是与内存页对齐有利于操作系统内核进行高效的内存管理。不对齐虽然可能也能工作但会在性能和稳定性上埋下隐患。计算单位统一所有计算请统一使用扇区Sector作为单位并在parameter.txt中以十六进制表示。避免在字节、KB、MB、GB之间来回换算时出错。我的习惯是先确定想要的大小如28GB换算成字节再除以512得到扇区数最后转换成十六进制。最后一个分区的“grow”对于最后一个分区通常是userdata其大小用-表示意为占用剩余所有空间。同时需要保留:grow标识。在你调整了前面分区的大小后这个分区会自动适应新的剩余空间。注意修改parameter.txt并重新烧录后仅仅改变了分区表。它就像重新画了一张硬盘的“分区规划图”。但是原来分区里的数据比如rootfs里的系统文件并不会自动迁移或扩容。你需要通过后续步骤通常是重新烧录完整的系统镜像或者使用resize2fs等工具在线扩容来让文件系统实际占用新的空间。本文演示的“调整rootfs为28GB”并打包烧录update.img通常意味着你会烧录一个包含了已按新分区表布局好的文件系统内容的完整镜像。3. 实战演练将rootfs分区扩容至28GB现在我们以最经典的需求——扩大根文件系统分区为例进行一步步的实战操作。假设我们觉得默认的rootfs不够用希望将其扩大到28GB以便安装更多开发工具和库。3.1 准备工作与环境确认在开始修改之前请确保你的开发环境是就绪的获取SDK源码你已经从ElfBoard或相关渠道获取了ELF 2开发板的Linux SDK源码。完成基础编译非常重要如果你是首次使用这份SDK或者之前没有进行过全编译请务必先参考官方文档《ELF 2开发板编译手册》完成一次完整的系统镜像构建。这能确保你的编译环境、工具链和依赖包都是正确的避免在修改分区后打包镜像时出现意外错误。定位关键文件找到SDK目录下的分区表文件通常路径是ELF2-linux-source/rockdev/parameter.txt。在修改前强烈建议先备份这个文件cp ELF2-linux-source/rockdev/parameter.txt ELF2-linux-source/rockdev/parameter.txt.backup3.2 精确计算扇区、字节与十六进制的转换这是整个过程中最需要细心的一步。我们的目标是将rootfs分区大小设置为28GB。第一步将目标大小转换为字节。这里要特别注意单位换算。在计算机存储中1GB 1024MB1MB 1024KB1KB 1024Byte。 所以28GB 28 * 1024 * 1024 * 1024 Bytes 30,064,771,072 Bytes。第二步将字节数转换为扇区数。已知1扇区 512字节。 扇区数 总字节数 / 每扇区字节数 30,064,771,072 / 512 58,720,256 个扇区。 这个数字看起来很大但它是精确的。第三步将十进制扇区数转换为十六进制。我们需要将58,720,256转换为十六进制以便填入parameter.txt。可以使用计算器程序员模式或者Python快速计算python3 -c “print(hex(58720256))”输出结果为0x3800000。 所以新的rootfs分区大小就是0x03800000个扇区通常保留前导零以保持格式美观。3.3 修改parameter.txt文件现在我们基于默认分区表计算新的起始地址链。默认情况如下分区名原大小 (扇区)原起始地址 (扇区)计算过程rootfs0x01c000000x00078000已知oem0x000400000x01c780000x00078000 0x01c00000 0x01c78000userdata-0x01cb80000x01c78000 0x00040000 0x01cb8000我们要将rootfs大小从0x01c00000改为0x03800000。那么后续分区的起始地址必须重新计算rootfs分区起始地址不变仍为0x00078000。大小更新为0x03800000。oem分区大小不变仍为0x00040000。其新的起始地址rootfs新起始地址 rootfs新大小 0x00078000 0x03800000 0x03878000。userdata分区大小仍为-。其新的起始地址oem新起始地址 oem大小 0x03878000 0x00040000 0x038b8000。打开ELF2-linux-source/rockdev/parameter.txt文件找到CMDLINE一行将其修改为CMDLINE: mtdparts:0x000020000x00004000(uboot),0x000020000x00006000(misc),0x000200000x00008000(boot),0x000400000x00028000(recovery),0x000100000x00068000(backup),0x038000000x00078000(rootfs),0x000400000x03878000(oem),-0x038b8000(userdata:grow)请注意parameter.txt文件末尾可能还有uuid等字段这些是文件系统的唯一标识符修改分区大小时通常不需要动它们保持原样即可。3.4 重新打包与烧录系统镜像修改完parameter.txt后它并不会立即生效。我们需要将它打包进完整的系统镜像中。重新打包update.img在SDK根目录下运行完整的镜像打包命令。具体命令可能因SDK版本而异通常类似于./build.sh updateimg或./mkimage.sh。请务必参考你的SDK中的编译文档。这个过程会读取你刚修改的parameter.txt并按照新的分区布局将内核、根文件系统等组件打包成一个新的update.img文件通常生成在rockdev/目录下。烧录镜像到开发板将ELF 2开发板进入Loader模式通常是通过按住某个按键再上电或使用命令sudo rkdeveloptool db加载Loader。使用瑞芯微官方工具如rkdeveloptool或 Windows下的RKDevTool进行烧录。关键点烧录时选择“Loader”模式下的“升级固件”选项然后选中新生成的update.img。千万不要只烧录parameter分区因为分区表变化后所有分区的相对位置都变了必须烧录完整的镜像确保文件系统被正确地放置到新的分区地址上。烧录过程会自动擦除整个eMMC并写入新的分区表和系统数据。因此烧录前请确认已备份开发板上所有重要数据。3.5 验证分区调整结果烧录完成后启动开发板进入系统。我们可以通过命令行工具验证分区是否已按预期调整。使用fdisk -l命令这个命令会列出所有块设备的分区表信息。找到你的eMMC设备通常是/dev/mmcblk0或/dev/mmcblk1。sudo fdisk -l /dev/mmcblk0在输出中你应该能看到一个分区的大小约为28GB显示为29G或28G左右因为计算方式差异其标签或序号对应着你的rootfs。使用lsblk命令这个命令以更清晰的树状图显示块设备能直观看到分区大小。lsblk查看对应设备的分区列表确认rootfs分区可能挂载在/的SIZE字段是否已变为28G左右。检查文件系统实际大小分区大小调整了但上面的文件系统未必立即填满新空间。对于ext4文件系统可以使用df -h查看挂载点容量并使用resize2fs命令来在线扩展文件系统以填满分区注意此操作有风险建议在确保数据已备份的新烧录系统中进行。# 查看根分区使用情况 df -h / # 如果分区已扩大但文件系统未扩展可以尝试假设rootfs是 /dev/mmcblk0p6 sudo resize2fs /dev/mmcblk0p6重要提示如果你烧录的是全新的、已根据新分区表制作好的系统镜像那么文件系统在烧录时就已经是扩容后的状态无需再执行resize2fs。4. 进阶技巧与避坑指南掌握了基本操作后下面分享一些能让你事半功倍、避免踩坑的进阶经验。4.1 分区规划策略不只是调大rootfs调整分区不应该只是“缺啥补啥”而应该有一个通盘考虑。对于RK3588这类性能强大的平台常见的项目分区规划思路如下AI项目rootfs需要足够大用于安装庞大的深度学习框架如TensorFlow, PyTorch、CUDA库、OpenCV等。userdata分区也要预留充足空间用于存放模型文件、数据集和推理结果。多媒体或边缘服务器如果应用涉及大量视频录制、图片缓存或日志记录可以适当缩小rootfs保证系统运行即可将大部分空间分配给userdata甚至可以考虑为日志或媒体文件创建独立的分区。双系统或恢复系统如果设计需要保留完整的恢复系统recovery分区切勿随意缩小该分区。boot分区也要保证能存放可能较大的内核和多个设备树文件。一个简单的规划表格可以帮助你理清思路分区建议大小主要用途调整考量uboot固定 (4MB)Bootloader绝对不要修改misc固定 (4MB)恢复系统通信一般不动boot32MB - 128MB内核、设备树、启动脚本确保能放下所有内核版本recovery256MB恢复系统镜像如需强大恢复功能可适当调大backup固定 (32MB)备份一般不动rootfs2GB - 32GB操作系统、基础软件根据安装的软件包数量决定oem固定 (128MB)厂商定制数据一般不动userdata剩余所有空间用户应用和数据项目数据的主要存放地4.2 常见问题排查与解决实录在实际操作中你可能会遇到以下问题问题1修改parameter.txt后烧录镜像失败工具报错“下载IDB失败”或“校验失败”。可能原因parameter.txt文件格式错误例如十六进制数写错、少了逗号、括号不匹配、地址计算错误导致重叠或溢出。排查步骤逐字符检查仔细核对修改的那一行特别是数字和标点。建议使用有语法高亮的文本编辑器。地址链验证将每个分区的起始地址大小手工计算一遍确保等于下一个分区的起始地址一直计算到最后一个分区。使用校验脚本有些SDK会提供检查parameter.txt格式的脚本运行一下。还原测试用之前备份的parameter.txt.backup替换回去重新打包烧录。如果成功则证明问题出在你的修改上。问题2系统能启动但无法挂载根文件系统卡在内核启动日志提示“VFS: Unable to mount root fs”。可能原因这是最典型的分区表与文件系统不匹配问题。你修改了parameter.txt中的rootfs地址但打包进update.img的根文件系统镜像如rootfs.img并没有被放置到新的地址上或者你只烧录了parameter分区而没有烧录完整的、包含已重新布局的根文件系统的update.img。解决方案必须重新打包完整的update.img并完整烧录。确保编译打包系统读取的是你修改后的parameter.txt。问题3使用fdisk -l查看分区大小正确但df -h显示的文件系统容量没变。可能原因分区表Partition Table已经扩大但分区内的文件系统File System本身还没有扩展。这就像给一个房子划了更大的宅基地分区但房子文件系统本身还是原来那么大。解决方案对于ext2/3/4文件系统可以使用resize2fs命令在线扩展。操作前务必确认分区未被损坏且数据已备份。# 首先使用 lsblk 或 fdisk -l 确认 rootfs 对应的实际设备节点例如 /dev/mmcblk0p6 sudo umount /dev/mmcblk0p6 # 如果可能先卸载。根分区无法卸载需在Live环境或恢复模式下操作。 sudo e2fsck -f /dev/mmcblk0p6 # 强制检查文件系统 sudo resize2fs /dev/mmcblk0p6 # 扩展文件系统以填满分区 sudo mount /dev/mmcblk0p6 /mnt # 重新挂载检查 df -h /mnt最稳妥的做法在SDK编译阶段就确保根文件系统镜像rootfs.img是根据新的分区大小生成的这样烧录后无需二次处理。问题4调整后userdata分区不见了或者大小不对。可能原因修改过程中userdata分区的起始地址计算错误或者忘记了最后的:grow标识。排查步骤重新检查parameter.txt中userdata的起始地址计算过程并确认其格式为-起始地址(userdata:grow)。4.3 高阶安全操作备份与恢复在进行任何分区操作前备份是黄金法则。备份原始完整镜像在修改之前如果开发板上已有重要数据可以使用rkdeveloptool的read命令将整个eMMC读取出来备份成镜像文件。这是一个底位操作能完整保留所有分区和数据。sudo rkdeveloptool rl 0x0 0x40000000 backup.img # 示例大小需根据eMMC容量调整备份parameter分区单独备份分区表也是一个好习惯。sudo rkdeveloptool rp parameter parameter_backup.bin制作“安全”的parameter.txt在SDK中保留一个经过验证的、能正常启动的parameter.txt副本。当你实验新分区布局导致无法启动时可以快速通过仅烧录parameter分区的方式回退到这个安全版本注意仅回退分区表可能导致文件系统错位最安全还是用完整备份恢复。修改嵌入式设备的分区表是一项底层且关键的操作它要求精确和谨慎。通过理解parameter.txt的工作原理掌握扇区地址的计算方法并遵循完整的打包烧录流程你就可以摆脱默认分区的束缚为你的ELF 2开发板量身定制最合适的存储空间布局。记住每次修改前做好备份计算后双重检查你就能在充分发挥硬件潜力的道路上稳步前行。
