深入海思Hi3536双系统架构：NAND扩容后如何重新规划主从系统分区与内存布局

海思Hi3536双系统架构深度解析：NAND扩容后的分区重构与内存映射优化

当一块海思Hi3536开发板从256MB NAND闪存升级到1GB时，看似简单的存储扩容背后隐藏着一场精密的"空间重构手术"。这颗集成了A17主控核心与A7多媒体协处理器的异构芯片，通过独特的双系统架构在安防监控、智能视觉等领域大放异彩。但正是这种主从系统协同工作的设计，使得存储扩容不再是简单的分区表调整，而需要工程师深入理解地址空间的"多米诺效应"。

1. 海思双系统架构的内存拓扑探秘

Hi3536的双系统异构架构犹如一座精心设计的双子大厦：A17四核主系统负责高算力任务调度，A7从系统专精多媒体流处理。这种分工在物理层面体现为两套独立的执行环境，却在存储空间上共享同一块NAND闪存。原始布局中，235MB的主系统rootfs分区就像占据了大厦低区的公司总部，而位于240MB起始位置的从系统则是楼上的专业实验室。

典型的NAND原始分区结构如下表所示：

当主系统rootfs从235MB扩容到900MB时，相当于总部突然需要占用整栋大厦的90%空间。此时从系统必须整体"搬迁"到新的物理地址——905MB处（0x38900000）。这个看似简单的数字变动，实则引发三个关键问题链式反应：

1. 地址重计算：所有从系统分区的绝对偏移量需要重新推导
2. 时序保障：主系统启动过程中对从系统的加载时序可能受影响
3. 边界校验：新分区布局不能超出物理存储容量上限

2. NAND地址空间的精密重构工程

扩容后的分区调整不是简单的数值替换，而需要建立完整的地址映射数学模型。假设原始从系统起始地址为Offset_old，新起始地址为Offset_new，则地址转换公式为：

Offset_new = Offset_old + (New_rootfs_size - Old_rootfs_size) = 240MB + (900MB - 235MB) = 905MB (0x38900000)

这个计算过程在U-Boot环境变量中体现为slave_bootcmd的重新配置。原始配置中的十六进制地址需要全部更新：

# 原始从系统加载命令（240MB起始） setenv slave_bootcmd 'nand read 0x81000000 0xF000000 0x80000...' # 扩容后配置（905MB起始） setenv slave_bootcmd 'nand read 0x81000000 0x38900000 0x80000...'

地址转换时的常见陷阱包括：

• 字节对齐问题：NAND操作需遵循4096字节页对齐
• 大小端转换：ARM架构的字节序影响地址解析
• 内存窗口限制：A7协处理器可能有特定的DDR访问范围

提示：使用nand dump命令验证物理地址内容时，建议先通过nand bad检查坏块分布，避免将关键分区部署在不可靠存储区域。

3. U-Boot参数系统的动态适配机制

Hi3536的U-Boot如同双系统的交通指挥中心，其环境变量构成了动态配置数据库。在修改mtdparts分区表声明后，必须同步更新三组关键参数：

1. 主系统启动参数：反映新的rootfs大小

   setenv bootargs 'mem=512M... mtdparts=hinand:1M(boot),4M(kernel),900M(rootfs)'

2. 从系统内存映射：调整加载地址与大小

   setenv slave_bootcmd 'nand read 0x81000000 0x38900000 0x80000...'

3. 异构内存划分：保持主从系统的DDR空间隔离

   setenv slave_bootargs 'mem=96M...' # 从系统独占96MB内存

实际操作中推荐采用参数分段验证法：

• 先单独测试主系统启动流程
• 再通过slave_autostart 0临时关闭从系统自启
• 最后用run slave_bootcmd手动验证从系统加载

4. 双系统协同优化的进阶策略

当主系统rootfs大幅扩容后，工程师面临一个架构级抉择：是否同步调整从系统分区大小？这需要权衡多个维度：

在视频分析类应用中，建议采用动态存储配额方案：

// 在从系统驱动中增加动态内存检测 if (check_slave_memory() < threshold) { adjust_frame_buffer(FRAME_BUFFER_REDUCE); syslog(LOG_WARNING, "Slave memory low, adjust QoS"); }

对于需要频繁更新多媒体算法的场景，可以尝试混合分区布局：

1. 保留从系统核心分区最小必需空间
2. 将扩展存储映射为/mnt/slave_expand
3. 通过RAM disk实现临时文件缓存

5. 实战中的异常诊断与修复

扩容过程中最棘手的莫过于YAFFS2文件系统兼容性问题。当出现pagesize:4096, ecctype:24bits/1K报错时，说明烧写工具与实际硬件参数不匹配。此时需要：

1. 确认NAND芯片的物理参数：

   dmesg | grep NAND # 查找原始设备识别信息

2. 重新制作YAFFS2镜像：

   ./mkyaffs2image610 rootfs_glibc_master output.yaffs2 2 4

   参数说明：

   • 2：页大小对应值（2K/4K）
   • 4：ECC位宽配置

3. 验证镜像完整性：

   nand write.yaffs 0x82000000 0x500000 ${filesize} nand read.yaffs 0x83000000 0x500000 ${filesize} cmp 0x82000000 0x83000000 ${filesize}

在双系统环境下，建议采用分级烧写验证流程：

• 先烧写主系统并验证基本功能
• 再通过主系统环境准备从系统镜像
• 最后使用hiburn工具单独烧写从系统分区

某次实际项目中的教训：当主系统rootfs扩容到900MB后，未及时调整从系统的DMA缓冲区参数，导致H.265编码时出现随机花屏。最终通过修改/proc/slabinfo中的dma-kmalloc-8192配置项解决了该问题。这提醒我们，存储布局变更后必须全面验证跨系统通信机制。