1. ElfBoard ELF 1板卡OTG烧写基础原理在嵌入式系统开发中OTG(On-The-Go)烧写是一种常用的固件烧录方式它通过USB接口实现开发板与主机之间的高速数据传输。ElfBoard ELF 1板卡采用的MfgTool工具是NXP提供的专业烧录工具其工作流程可以分为以下几个关键阶段首先开发板上电后内部的boot ROM代码会初始化USB外设将板卡枚举为HID设备。这个阶段是硬件层面的自动处理开发者无需干预。当MfgTool检测到HID设备后会建立连接并开始解析预置的uboot镜像利用其中的内存配置信息对开发板的DDR进行初始化。DDR初始化完成后工具会按照ucl2.xml脚本的指令将firmware目录下的uboot镜像、内核镜像、设备树以及ramfs加载到DDR内存的指定地址。这个过程涉及精确的内存地址分配内核镜像(zImage)加载到0x80800000虚拟文件系统(ramfs)加载到0x83800000设备树(dtb)加载到0x83000000系统启动后会重新枚举USB为MSC设备此时传输速度大幅提升。MfgTool继续执行ucl2.xml中的命令将files目录下的完整系统镜像烧写到存储介质中。这个设计巧妙利用了USB协议的不同工作模式既保证了初始连接的可靠性又确保了大数据量传输的效率。2. 分区表修改的核心步骤2.1 理解默认分区方案ElfBoard ELF 1的默认分区方案由mksdcard.sh脚本定义主要包含两个分区${BOOT_ROM_SIZE}M,500M,0c # FAT32格式的boot分区 600M,,83 # EXT3格式的rootfs分区这种设计将前10MB保留给uboot500MB FAT32分区用于存放内核、设备树等启动文件剩余空间作为根文件系统。但在实际项目中我们经常需要调整这个布局。2.2 修改分区脚本要增加新的分区需要编辑mksdcard.sh脚本中的sfdisk命令部分。例如增加一个512MB的数据分区sfdisk --force ${node} EOF ${BOOT_ROM_SIZE}M,500M,0c 600M,512M,83 1200M,,83 EOF这个修改创建了三个分区保持原有的500MB FAT32分区(0c类型)新增512MB的EXT3分区(83类型)作为数据存储剩余空间仍作为根文件系统分区注意分区大小需要根据实际存储介质容量调整确保总和不超过设备容量。EMMC通常会有少量保留空间建议保留至少2%的未分配空间。2.3 更新烧录流程分区脚本修改后需要在ucl2.xml中添加对新分区的处理。在原有的rootfs烧录步骤前插入!-- 格式化并挂载data分区 -- CMD stateUpdater typepush body$ mkfs.ext3 -F /dev/mmcblk%mmc%p3Formatting data partition/CMD CMD stateUpdater typepush body$ mkdir -p /mnt/mmcblk%mmc%p3/ CMD stateUpdater typepush body$ mount -t ext3 /dev/mmcblk%mmc%p3 /mnt/mmcblk%mmc%p3/ !-- 可在此添加data分区初始化内容 -- CMD stateUpdater typepush body$ echo Data Partition /mnt/mmcblk%mmc%p3/README/ CMD stateUpdater typepush body$ umount /mnt/mmcblk%mmc%p3/3. 分区方案设计实践3.1 典型多分区配置对于工业应用推荐以下分区方案1. uboot : 1MB (原始保留区域) 2. uboot-env : 1MB (环境变量存储) 3. boot : 128MB (FAT32内核和设备树) 4. recovery : 128MB (EXT3恢复系统) 5. data : 512MB (EXT4应用数据) 6. rootfs : 剩余空间 (EXT4主系统)对应的sfdisk命令为dd if/dev/zero of${node} bs1024 count1 sfdisk --force ${node} EOF ,1M,83 ,1M,83 ,128M,0c ,128M,83 ,512M,83 ,,83 EOF3.2 分区挂载配置修改根文件系统中的/etc/fstab文件添加自动挂载项/dev/mmcblk1p3 /data ext4 defaults,noatime 0 2 /dev/mmcblk1p4 /recovery ext4 ro,noauto 0 23.3 动态分区调整技巧对于需要灵活调整分区的场景可以采用以下方法使用parted工具替代sfdiskparted -s ${node} mklabel gpt parted -s ${node} mkpart primary fat32 1MiB 129MiB parted -s ${node} mkpart primary ext4 129MiB 257MiB parted -s ${node} mkpart primary ext4 257MiB 769MiB parted -s ${node} mkpart primary ext4 769MiB 100%在烧录脚本中添加分区校验逻辑# 检查分区是否创建成功 while [ ! -e /dev/mmcblk%mmc%p4 ]; do sleep 1 echo 等待分区初始化... done4. 常见问题与解决方案4.1 分区未正确识别现象系统启动后无法找到新增分区 排查步骤检查内核启动日志dmesg | grep mmcblk确认分区表信息fdisk -l /dev/mmcblk1验证文件系统类型blkid /dev/mmcblk1p*常见原因分区表未正确写入 → 增加sync命令确保写入完成内核不支持文件系统 → 检查内核配置中的文件系统支持选项4.2 烧录过程卡死现象烧录到新分区步骤时工具无响应 解决方法降低传输速度在ucl2.xml的push命令中添加sleep 1间隔检查USB连接质量更换高质量数据线增加超时检测机制CMD stateUpdater typepush bodytimeout 60 dd if$FILE of/dev/mmcblk%mmc%p3 bs4M4.3 分区大小计算错误精确计算分区大小的公式实际可用空间 (总块数 - 1) * 块大小 - 2 * 块大小建议在脚本中添加计算校验TOTAL_SIZE$(blockdev --getsize64 /dev/mmcblk1) REQUIRED_SIZE$(( (128 128 512) * 1024 * 1024 )) if [ $TOTAL_SIZE -lt $REQUIRED_SIZE ]; then echo 错误存储空间不足 exit 1 fi5. 高级应用技巧5.1 保留分区配置对于需要频繁修改分区的场景可以采用以下策略将分区表信息单独保存到文件中sfdisk -d /dev/mmcblk1 partition_table.backup烧录时直接应用备份CMD stateUpdater typepush bodysend fileconfig/partition_table.backup CMD stateUpdater typepush body$ sfdisk /dev/mmcblk%mmc% $FILE5.2 动态分区挂载在系统启动脚本中实现智能挂载# 检查分区是否存在 if [ -b /dev/mmcblk1p3 ]; then # 检查文件系统完整性 fsck.ext4 -p /dev/mmcblk1p3 # 动态创建挂载点 mkdir -p /data mount /dev/mmcblk1p3 /data fi5.3 安全擦除技术对于需要安全擦除的场景可以在分区前执行CMD stateUpdater typepush body$ blkdiscard -f /dev/mmcblk%mmc% CMD stateUpdater typepush body$ echo -e o\nn\np\n1\n\n128M\nn\np\n2\n\n128M\nw | fdisk /dev/mmcblk%mmc%在实际项目中我曾遇到一个案例客户需要在同一块板卡上支持两种不同的应用场景。通过设计灵活的分区方案我们实现了前128MB存放公共内核和基础驱动中间512MB作为场景A的专用分区剩余空间用于场景B的系统 这种设计减少了30%的存储空间需求同时提高了系统切换效率。关键点在于精确计算每个分区的最小需求并在ucl2.xml中添加智能检测逻辑。