从eMMC到SPI+SSD：双存储方案下Vendor Storage适配指南

 

 

在嵌入式 Linux 开发中，存储方案的切换是常见需求，比如从传统 eMMC 改为 SPI NOR Flash+SSD（SATA/NVMe）双存储架构。这种调整能兼顾启动速度与存储容量，但也可能引发 Vendor Storage 访问异常。本文将结合实际调试案例，拆解适配过程中的核心问题与解决方案，帮助开发者快速踩坑。

一、问题根源：存储切换为何影响 Vendor Storage？

 

Vendor Storage 是嵌入式系统中用于存放 SN（序列号）、MAC 地址、硬件配置等关键信息的专用存储区域，其正常工作依赖存储设备驱动、分区配置、内核参数三者的协同。从 eMMC 切换到 SPI+SSD 方案后，原有适配逻辑失效，主要源于以下 3 点差异：

 

 

1.存储介质特性不同：eMMC 属于块设备，Vendor Storage 通常依托 eMMC 的专用分区实现；而 SPI NOR Flash 是字符设备（MTD 设备），需通过 MTD 子系统驱动管理，原有块设备驱动无法直接复用。

 

 

2.分区表定义规则变化：eMMC 的分区表由厂商预设或通过工具分区，SPI NOR Flash 需在parameter.txt（启动参数文件）和内核设备树（DTS）中手动定义分区，且分区起始地址、大小必须满足 64KB 整数倍（SPI NOR 擦除块对齐要求）。

 

 

3.内核配置依赖不同：eMMC 方案下启用的 Vendor Storage 配置（如CONFIG_ROCKCHIP_FLASH_VENDOR_STORAGE），在 SPI 方案中需切换为 MTD 子系统对应的配置（CONFIG_ROCKCHIP_MTD_VENDOR_STORAGE），同时需启用 SPI NOR 驱动支持。

二、核心适配步骤：四步打通 SPI+SSD 下的 Vendor Storage

 

结合实际调试经验，从 eMMC 迁移到 SPI+SSD 方案时，需按以下步骤完成 Vendor Storage 适配，每一步都需严格验证，避免后续问题：

 

 

1. 内核配置：启用 SPI NOR 与 MTD Vendor Storage 支持

 

首先需在 Linux 内核配置（.config文件）中开启关键选项，确保 SPI NOR 设备能被识别，且 Vendor Storage 能依托 MTD 子系统工作：

 

 

•启用 SPI NOR 驱动：勾选CONFIG_MTD_SPI_NOR（路径：Device Drivers > Memory Technology Device (MTD) > SPI-NOR device support），同时确保对应厂商驱动（如 Macronix、Winbond）被编译（可通过spi-nor-dev_ids数组确认芯片型号匹配，如本文中mx25u12832f需在列表中）。

 

 

•启用 MTD Vendor Storage：勾选CONFIG_ROCKCHIP_MTD_VENDOR_STORAGE（路径：Device Drivers > Memory Technology Device (MTD) > Rockchip MTD Vendor Storage Support），禁用原 eMMC 方案的CONFIG_ROCKCHIP_FLASH_VENDOR_STORAGE，避免驱动冲突。

 

 

•验证配置：编译内核后，通过dmesg | grep spi查看 SPI NOR 是否被识别（如出现 “spi-nor: detected mx25u12832f” 日志，说明驱动加载成功）。

 

 

2. 分区配置：双文件同步定义 “vnvm” 专用分区

 

SPI NOR 需单独划分 “vnvm” 分区存放 Vendor Storage 数据，且 **parameter.txt与 DTS 中的分区定义必须完全一致 **（仅单位不同），这是适配过程中的高频踩坑点：

 

 

配置文件	配置规则	示例（以 256KB vnvm 分区为例）
parameter.txt（启动参数）	单位：sector（512 字节），格式为 “分区大小@起始地址(分区名)”，需为 64KB 整数倍（即 128 个 sector）	mtdparts=rk29xxnand:0x00000200@0x00000c00(vnvm),0x00004000@0x00004000(uboot)
DTS（设备树）	单位：byte，格式与parameter.txt一致，需转换为 byte（sector 值 ×512）	bootargs = "... mtdparts=sfc_nor:0x00040000@0x00018000(vnvm),0x00600000@0x00020000(uboot) ..."

 关键注意事项：

 

 

•分区单位不可混淆：parameter.txt用 sector，DTS 用 byte，若单位错误会导致分区无法识别，进而出现 “vendor_storage open fail” 错误。

 

 

•避免冲突：“vnvm” 分区起始地址需避开 uboot、boot 等已有分区，建议放在 uboot 分区之前（如起始地址 0x00000c00），大小根据需求设置（最小 64KB，需为 64KB 整数倍）。

 

 

3. 驱动验证：确认 MTD Vendor Storage 设备生成

 

完成内核与分区配置后，需验证系统是否生成/dev/vendor_storage设备节点（这是 Vendor Storage 工具调用的关键）：

 

 

1.启动系统后，执行ls /dev | grep vendor_storage，若能看到设备节点，说明配置基本正常；

 

 

2.若未生成节点，通过dmesg | grep vendor排查问题：

 

 

◦若出现“vendor_storage_probe ret=-1”，可能是分区定义错误（如地址冲突、单位错误），需重新核对parameter.txt与 DTS；

 

 

◦若出现“spi nor not initialized”，需检查 SPI NOR 驱动是否启用（参考步骤 1 的内核配置）。

 

 

4. 功能测试：用工具验证读写可用性

 

最后通过vendor_storage工具测试读写功能，确认关键信息能正常存储：

 

 

•写入测试：执行vendor_storage -w VENDOR_SN_ID -t string -i "TEST_SN_123456"，无报错说明写入成功；

 

 

•读取测试：执行vendor_storage -r VENDOR_SN_ID -t string，若能输出“TEST_SN_123456”，说明 Vendor Storage 完全可用；

 

 

•异常排查：若出现“输入 / 输出错误”，需检查 “vnvm” 分区是否可读写（通过cat /proc/mtd查看分区状态，确保“vnvm” 分区为 “rw” 模式）。

 

 

三、常见问题排查：3 个高频场景的解决方案

 

在实际适配中，即使步骤正确，也可能因细节遗漏导致问题。以下是 3 个典型场景的排查思路：

 

 

1. 场景 1：vendor_storage工具提示“open fail”

 

•可能原因：

 

 

a.SPI NOR 驱动未加载（dmesg | grep spi无识别日志）；

 

 

b.“vnvm” 分区未定义或定义错误（单位混淆、地址冲突）；

 

 

c.内核未启用CONFIG_ROCKCHIP_MTD_VENDOR_STORAGE。

 

 

•排查步骤：先确认 SPI NOR 驱动加载（步骤 1），再核对分区配置（步骤 2），最后检查内核配置（步骤 1）。

 

 

2. 场景 2：dmesg中出现“vendor_storage_probe ret=-1”

 

•可能原因：MTD 子系统未找到 “vnvm” 分区，通常是分区表中未定义该分区，或parameter.txt与 DTS 的分区信息不一致。

 

 

•排查步骤：对比parameter.txt与 DTS 中的 “vnvm” 分区起始地址、大小，确保单位转换正确（sector×512=byte），且无地址冲突。

 

 

3. 场景 3：SPI NOR 芯片未被识别（无 “detected xxx” 日志）

 

•可能原因：

 

 

a.内核未勾选对应芯片的驱动（如mx25u12832f需在spi-nor-dev_ids数组中）；

 

 

b.硬件接线问题（SPI 引脚接触不良）。

 

 

•排查步骤：先检查内核drivers/mtd/spi-nor/core.c中的spi_nor_dev_ids数组，确认芯片型号已添加；若软件配置正确，再排查硬件接线。

 

 

四、总结：适配的核心原则

 

从 eMMC 到 SPI+SSD 的 Vendor Storage 适配，本质是 **“从块设备逻辑切换到 MTD 字符设备逻辑”**，关键在于抓住 3 个核心原则：

 

 

1.驱动匹配：明确 SPI NOR 芯片型号，确保驱动被编译且加载成功；

 

 

2.分区同步：parameter.txt与 DTS 的 “vnvm” 分区定义必须一致，单位不可混淆；

 

 

3.配置唯一：禁用 eMMC 方案的 Vendor Storage 配置，仅保留 MTD 方案的配置，避免冲突。

 

 

只要按“内核配置→分区定义→驱动验证→功能测试” 的步骤推进，同时做好每一步的日志排查，就能高效解决适配过程中的问题，确保 Vendor Storage 在双存储方案下稳定工作。