Linux kernel mmc 框架说明，包括mmc_test使用方法

最新推荐文章于 2024-09-22 05:12:39 发布
最新推荐文章于 2024-09-22 05:12:39 发布
阅读量1.4k 收藏 10
点赞数
分类专栏： 嵌入式 SD/EMMC 文章标签： eMMC SD mmc_test sdio
原文链接：https://blog.youkuaiyun.com/kivy_xian/article/details/53333831
版权
本文深入解析Linux下的MMC模块，涵盖总线模型、MMC协议、eMMC特性及MMC测试driver使用。详细介绍了平台总线、MMC与SDIO总线的运作机制，以及驱动与设备的匹配过程。

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

FROM：https://blog.youkuaiyun.com/kivy_xian/article/details/53333831

请看原文，排版看得方便，转载留作记录，谢谢kivy_xian

1.Linux 总线模型

        Linux下的任何驱动在内核中最终都抽象为bus, driver以及device三者间的相互作用。

        总线是处理器和一个或多个设备之间的通道，在设备模型中，所有的设备都通过总线相连接。总线将设备和驱动绑定，在系统每注册一个设备的时候，会遍历该总线上的driver list，通过bus的math函数寻找与之匹配的驱动；相反的，在系统每注册一个驱动的时候，会便利该总线上的device 寻找与之匹配的设备，而匹配由总线的match函数完成。一但匹配，则会调用总线的probe函数。

        在此模型下，如果存在实际总线当然很好，比如mmc总线，i2c总线和spi总线，相应的device和driver都可以直接注册在总线上。但是总是有一些设备和总线无关，为此，linux kernel引入了platform 虚拟总线，

Platform总线是一种虚拟的总线，相应的设备则为platform_device，通过platform_driver_register；而驱动则为platform_driver，通过platform_driver_register 注册。内核中该总线定义如下：


struct bus_type platform_bus_type = {

       .name            = "platform",

       .dev_groups= platform_dev_groups,

       .match          = platform_match,

       .uevent         = platform_uevent,

       .pm        = &platform_dev_pm_ops,

};

    platform_总线match采用名称匹 配的方式，即driver和device两者的name一样则认为该device对应该driver，详见下图:

2.MMC 简介

MMC

MMC全称MultiMedia Card，由西门子公司和SanDisk公司1997年推出的多媒体记忆卡标准。MMC卡尺寸为32mm x24mm x 1.4mm，它将存贮单元和控制器一同做到了卡上，智能的控制器使得MMC保证兼容性和灵活性。

MMC卡具有MMC和SPI两种工作模式，MMC模式是默认工作模式，具有MMC的全部特性。而SPI模式则是MMC协议的一个子集，主要用于低速系统。

 

SD

        SD卡全称Secure DigitalMemory Card，由松下、东芝和SanDisk公司于1999年8月共同开发的新一代记忆卡标准，已完全兼容MMC标准。SD卡比MMC卡多了一个进行数据著作权保护的暗号认证功能。

        SD卡尺寸为32mm x 24mm x2.1mm，长宽和MMC卡一样，只是比MMC卡厚了0.7mm，以容纳更大容量的存贮单元。SD卡与MMC卡保持向上兼容，也就是说，MMC卡可以被新的设有SD卡插槽的设备存取，但是SD卡却不可以被设有MMC插槽的设备存取。

 

SDIO

        SDIO全称Secure DigitalInput and Output Card，SDIO是在SD标准上定义了一种外设接口，它使用SD的I/O接口来连接外围设备，并通过SD上的I/O数据接口与这些外围设备传输数据。现在已经有很多手持设备支持SDIO功能，而且许多SDIO外设也被开发出来，目前常见的SDIO外设有：WIFI Card、GPS Card、 Bluetooth Card等等。

 

eMMC

        eMMC全称Embedded MultiMediaCard，是MMC协会所制定的内嵌式存储器标准规格，主要应用于智能手机和移动嵌入式产品等。eMMC是一种嵌入式非易失性存储系统，由闪存和闪存控制器两部分组成，它的一个明显优势是在封装中集成了一个闪存控制器，它采用JEDEC标准BGA封装，并采用统一闪存接口管理闪存。

        eMMC结构由一个嵌入式存储解决方案组成，带有MMC接口、快闪存储设备及主控制器，所有这些由一个小型BGA封装。由于采用标准封装，eMMC也很容易升级，并不用改变硬件结构。

        eMMC的这种将Nand Flash芯片和控制芯片封装在一起的设计概念，就是为了简化产品内存储器的使用，客户只需要采购eMMC芯片放进产品中，不需要处理其它复杂的Nand Flash兼容性和管理问题，减少研发成本和研发周期。

3.MMC 模块总线模型

mmc子系统涉及到三条总线，如下：

Host驱动相应的driver和device挂载在Linux内核内置的虚拟抽象总线platform_bus_type。两者的匹配采用名称匹配的方式，即driver和device两者的name一样则认为该device对应该driver，这里是”rda,hsmmc”。

Card驱动相应的driver和device挂载在mmc自己创建的虚拟总线mmc_bus_type下，直接匹配。

Sdio驱动相应的driver和device挂载在mmc自己创建的虚拟总线sdio_bus_type下，ID匹配。

 

按照时间先后顺序，mmc模块中bus，device和driver的注册顺序如下:

3.1.host device

linux kernel 通过下图所示流程，解析dts文件mmc模块相关配置，生成名为rda,hsmmc的platformdevice，挂在platform平台总线上。

2.2.mmc_bus, sdio_bus

mmc core初始化时，文件core.c中的subsys_initcall(mmc_init)， 调用mmc_register_bus和sdio_register_bus注册mmc bus 和sdio bus，具体如图下图所示。


由上图可以看出，任何挂在mmc总线上的device 和driver都会匹配，而挂在sdio总线上的设备和deriver需要通过id进行匹配。

2.3.card driver

    card目录下，block.c中module_init(mmc_blk_init)调用mmc_register_driver函数创建mmcblk driver，并将之挂载到mmc_bus_type总线的driver list链表上。

    注意：mmc core提供了mmc_test.c作为mmc driver的测试文件。mmc_test.c中，module_init(mmc_test_init)函数中，调用mmc_register_driver函数创建了mmc_test driver，并且将之挂载在mmc_bus_type总线的driver list链表上。

mmc模块如果需要使用mmc_test功能，需要把CONFIG_MMC_BLOKC宏关闭，然后把CONFIG_MMC_BLOCK=y。否则，card将会匹配blockdreiver，不会再次匹配mmc_test  driver,具体见下图。

2.4.host driver

    host目录下，rda_sgmmc.c文件中，module_init(rda_mmc_init)，把rda_mmc_init链接到相应的init字段中。在初始化时候，执行rda_mmc_init（），调用platform_driver_register注册名为rda,hsmmc的host driver，此driver挂在platform虚拟总线上。

2.5. card device

在第四步中，hostdriver注册成功后，platform总线会把此driver和1中注册的host dev匹配，然后执行host driver的probe 函数rda_mmc_probe。该函数中完成mmc_alloc_host申请mmc host 结构体，然后完成初始化，以及中断等的申请等，最后调用mmc_add_host完成card 的探测，如果card存在，生成card device。

因为sd卡支持热插拔，所以在probe阶段，sd卡没有插入的情况下，不会生成card device。而是在后期插入sd卡时候，产生中断，中断处理函数中调用mmc_detect_change函数探测sd card是否存在，完成初始化并且生成card device。具体见下图。

从上图中，我们并没有看到card设备的生成。这是因为我们通过detect work完成了sd，mmc，或sdio设备的初始化，并且生成相应的block设备，具体见下图:

 

2.6. card driver执行

    在第五步中，card device已经挂到mmc总线上，此时会匹配到carddriver，自动执行driver 的probe函数。如果在3中，CONFIG_MMC_BLOCK=y，则会执行mmc_blk_probe，生成block设备。如果CONFIG_MMC_BLOCK=n, CONFIG_MMC_TEST=y,则会自动执行mmc_test_probe。

综上所述，设备通过dts文件把mmc host dev(platform设备)挂在虚拟平台总线上，然后注册sdio和mmc总线，紧接着注册card driver，挂在mmc总线上。其后，在host目录下，我们自己的driver中，调用platform_driver_register注册platform平台驱动，即host driver。此时，platform会匹配host dev 和driver，执行driver的probe函数，通过mmc_add_host注册card

device,挂载到mmc总线上。最后，mmc总线会匹配card dev 和driver，执行card driver的probe函数，生成block设备或者mmc_test相关的属性文件。

4.MMC 协议实现

到此为止，mmc 的相关框架已经介绍清楚了。因为在框架明了的情况下，驱动已经很简单了，所以后面仅仅会简单介绍一下mmc驱动。

sd，sdio或者mmc的协议实现在哪里呢？可以在图5中看到，初始化就是在mmc_attach_sdio, mmc_attach_sd或者mmc_attach_mmc函数中。

1.初始化时候，首先发送cmd0使卡进入idle状态;

2.接着发送cmd8，检测卡是否SD2.0。SD1.1不支持cmd8，因此如果发送cmd8无回应，则卡为SD1.1，否则就是SD2.0；

3. mmc_attach_sdio发送cmd5读取OCR 寄存器，判断是否为sdio，如果是就绑定sdio总线；

4. mmc_attach_sd发送命令acmd55、cmd41，使卡进入工作状态。如果通过，则认为是sd卡，绑定sd总线。mmc卡不支持acmd55,和cmd41，所以如果无回应，则认为卡是mmc卡；

5. mmc_attach_mmc中发送命令1，判断是否为mmc卡，如果回应，则绑定mmc总线。如果cmd1无回应，则不是mmc卡。

具体实现和协议强相关，只要对照协议来看，很简单，就不再多述了。
    ls kernel/drivers/mmc,可以看到如下三个目录：

card core host

card目录下主要是完成了上章中所述的mmc总线driver，也就是2.3所述的card driver,

core目录主要是完成了上章中sdio bus和mmc bus注册，card device的添加，host目录就是具体的host driver的添加了。

 

在mmc driver中，需要做的很重要的一部就是实现mmc_host_ops，在probe函数中把其赋值给mmc_host 结构体的ops变量，rda_sgmmc.c的mmc_host_ops实现如下：

static const struct mmc_host_ops rda_mmc_ops= {

       .request        = rda_mmc_request,

       .get_ro         = rda_mmc_get_ro,

       .get_cd         = rda_mmc_get_cd,

       .set_ios        = rda_mmc_set_ios,

        .enable_sdio_irq =rda_mmc_enable_sdio_irq,

};

 

其中，request函数，主要实现命令发送，数据的读写；set_ios主要用来设置数据速度，mmc相位，power mode 和data bus width；get_cd用来检测设备是否存在；get_ro用来判断mmc是否为read-only card；enable_sdio_irq是用来使能或者关闭sdio中断。

 

mmc dev正常读写的时候调用流程是怎么样呢?怎么和上面注册的mmc_host_ops关联起来呢?块设备的读写会被放入request_queue。见下图：

其中，blk_fetch_request等涉及到block文件的读写实现方式，这里不再叙述，有兴趣的话大家可以看看代码。

由此，mmc card dev就和上面注册的mmc_host_ops关联起来了。

5.MMC test driver 使用

在第二章介绍card driver时候已经介绍到了mmc test driver了。如果要使用mmc_test function，可以按照如下步骤:

1.CONFIG_MMC_BLOCK=n,CONFIG_MMC_TEST=y。或者CONFIG_MMC_BLOCK=y, CONFIG_MMC_TEST=y。如果选用后一种配置，需要再系统起来后，在总线driver中手动bind和unbind，见后面；

2.CONFIG_DEBUG_FS=y，CONFIG_DEBUG_KERNEL=y,这两项在我们项目的kernel的defconfig中已经配置，所以不需要进行改动；

3. mount -t debugfs none /sys/kernel/debug，这个我们的project中已经挂载了，不需要进行改动；

完成上面三项后，启动系统，如果在步骤1中CONFIG_MMC_BLOCK=y，那么需要先执行执行如下操作：

etau:/ # ls sys/bus/mmc/devices/                                              

mmc0:aaaa

 

etau:/sys/bus/mmc/drivers # ls

mmc_test/ mmcblk/

 

etau:/sys/bus/mmc/drivers # cd mmcblk/                                         

etau:/sys/bus/mmc/drivers/mmcblk # ls -al

total 0

drwxr-xr-x 2 root root    0 2000-01-01 01:27 .

drwxr-xr-x 4 root root    0 2000-01-01 01:27 ..

--w------- 1 root root 4096 2000-01-01 01:28bind

lrwxrwxrwx 1 root root    0 2000-01-01 01:28 mmc0:aaaa ->../../../../devices/soc0/20a50000.rda-mmc0/mmc_host/mmc0/mmc0:aaaa

--w------- 1 root root 4096 2000-01-01 01:28uevent

--w------- 1 root root 4096 2000-01-01 01:28unbind

 

etau:/sys/bus/mmc/drivers/mmcblk #echo –n mmc0:aaaa> unbind

etau:/sys/bus/mmc/drivers # cdmmc_test/                                      

etau:/sys/bus/mmc/drivers/mmc_test # ls

bind uevent unbind

 

etau:/sys/bus/mmc/drivers/mmc_test #echo –n mmc0:aaaa> bind

 

完成上述操作后，完成了mmc0:aaaa和mmc_test driver的绑定。后续步骤完全一致，如下:

 

etau:/sys/kernel/debug/mmc0/mmc0:aaaa# cat testlist                          

1:     Basic write (no data verification)

2:     Basic read (no data verification)

3:     Basic write (with data verification)

4:     Basic read (with data verification)

5:     Multi-block write

6:     Multi-block read

7:     Power of two block writes

8:     Power of two block reads

9:     Weird sized block writes

10:    Weird sized block reads

11:    Badly aligned write

12:    Badly aligned read

13:    Badly aligned multi-block write

14:    Badly aligned multi-block read

15:    Correct xfer_size at write (start failure)

16:    Correct xfer_size at read (start failure)

17:    Correct xfer_size at write (midway failure)

18:    Correct xfer_size at read (midway failure)

19:    Highmem write

20:    Highmem read

21:    Multi-block highmem write

22:    Multi-block highmem read

23:    Best-case read performance

24:    Best-case write performance

25:    Best-case read performance into scattered pages

26:     Best-case write performance from scatteredpages

27:    Single read performance by transfer size

28:    Single write performance by transfer size

29:    Single trim performance by transfer size

30:    Consecutive read performance by transfer size

31:    Consecutive write performance by transfer size

32:    Consecutive trim performance by transfer size

33:    Random read performance by transfer size

34:    Random write performance by transfer size

35:    Large sequential read into scattered pages

36:    Large sequential write from scattered pages

37:    Write performance with blocking req 4k to 4MB

38:    Write performance with non-blocking req 4k to 4MB

39:    Read performance with blocking req 4k to 4MB

40:    Read performance with non-blocking req 4k to 4MB

41:    Write performance blocking req 1 to 512 sg elems

42:    Write performance non-blocking req 1 to 512 sg elems

43:    Read performance blocking req 1 to 512 sg elems

44:    Read performance non-blocking req 1 to 512 sg elems

45:    Reset test

然后执行etau:/sys/kernel/debug/mmc0/mmc0:aaaa# echo 1 > test可以看到测试结果：

[314034.644348] mmc0: Starting tests of cardmmc0:aaaa...

[314034.645080] mmc0: Test case 1. Basicwrite (no data verification)...

[314034.647583] mmc0: Result: OK

[314034.647827] mmc0: Tests completed.

 

至此，mmc模块就告一段落了。
————————————————
版权声明：本文为优快云博主「kivy_xian」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/kivy_xian/article/details/53333831

linux下MMC_TEST的使用
qq_38158479的博客
04-08 173
linux下MMC_TEST的使用。
mmc_test_mmctest_
10-01
mmc 测试代码
2024年最新Linux下mmc_test测试工具使用_mmc工具，2024年最新面试物联网嵌入式开发卡顿
2401_85011960的博客
05-14 566
当然，mmc core提供了mmc_test.c来作为mmc driver的测试文件。如何使用mmc_test.c测试文件测试mmc驱动呢？
利用mmc_test.c研究mmc模块
tmkeepgood的专栏
09-16 3266
mmc初始化流程研究及mmc_test.c的使用 不清楚mmc_test.c的作者希望大家如何利用该模块，通过向该模块的probe函数传入一个合法的mmc_card指针，便可完成对该模块的使用。
linux下的SD驱动功能测试代码mmc_test.c
01-21
linux下的SD驱动功能测试代码mmc_test.c
Linux内核4.14版本——mmc框架——总线设置
yangguoyu8023的博客
02-12 2998
emmc框架分析
系统移植-（三）kernel简介、kernel部署阶段、mmc命令的使用
蒲公英的诗与远方
04-13 1084
Kernel的配置、编译和移植kernel 简介linux内核的特点linux内核源码的获取linux内核的命名规则Kernel的部署（1）开发阶段系统部署（2）产品发布系统部署（3）开发阶段-部署过程（4）产品发布-部署过程mmc相关命令部署操作步骤update_mmc和mmc命令的区别 kernel 简介 linux内核的特点 linux内核源码开源 linux支持多种架构平台：ARM、x8...
Linux下mmc_test测试工具使用_mmc工具
2401_87378345的博客
09-22 369
是独立的文件，并没有编译到内核中，需要我们到。默认情况下，我们一般都已经加载了。很多朋友也都有疑问，如何在。通过下面命令，查询对应的。
MMC耐久测试压力测试
09-02
MMC耐久测试压力测试
Linux下mmc_test测试工具使用
Donge's Blog
04-03 3367
Linux下mmc_test测试工具使用 文章目录Linux下mmc_test测试工具使用1、将`mmc_test.c`编译到内核2、`mmc_test`绑定2.1、查看驱动编号2.2、解绑mmc原驱动2.3、绑定`mmc_test`驱动2.4、`debugfs`挂载2.5、查看测试列表2.6、测试指定命令 很多朋友也都有疑问，如何在Linux下，测试emmc/sd模块呢？ 当然，mmc core提供了mmc_test.c来作为mmc driver的测试文件。 如何使用mmc_test.c测试文件测试m
Linux内核MMC框架
weixin_43982460的博客
03-03 2932
1.mmc的概念 1.MMC MultiMedia Card，多媒体存储卡， 但后续泛指一个接口协定（一种卡式），能符合这接口的内存器都可称作mmc储存体,工作电压：高电压为2.7～3.6 V，低电压为1.65～1.95 V，可选. 2.MMC总线 mmc总线是和I2C总线、SPI总线类似的一种总线结构。 卡与主控制器间串行传送，工作时钟频率范围为0～200 MHz,mmc总线上最多可识别64 K个mmc设备，在总线上不超过10个卡时，可运行到最高频率。 3.mmc设备 使用mmc接口规范（MCI, Mul
Linux kernel 使能MMC驱动
weixin_41252596的博客
12-16 1016
Linux kernel 使能MMC驱动
Linux内核4.14版本——mmc框架_软件总体架构
u010783226的专栏
09-13 1133
emmc
mmc_test.c 的使用
dp__mcu的专栏
05-27 387
/** * mmc_register_driver - register a media driver * @drv: MMC media driver */ int mmc_register_driver(struct mmc_driver *drv) { drv->drv.bus = &mmc_bus_type; #ifdef CONFIG_MMC_TEST printk("debug defined config_mmc...
linux下mmc读写工具,linux内核mmc读写分析
weixin_33188789的博客
05-11 339
MMC 读写分析EMMC读写操作的调用栈mmc_queue_thread ->mmc_blk_issue_rq ->mmc_blk_issue_rw_rq ->mmc_start_req ->__mmc_start_data_req ->mmc_start_request ->omap_hsmmc_request首先mmc_queue_thread获取相应的mm...
linux mmc设备测试,Linux 开发板常规测试
weixin_39773215的博客
05-05 465
【正点原子】I.MX6U用户快速体验V1.2.pdf1. LED 与蜂鸣器测试LED 测试echo none > /sys/class/leds/sys-led/trigger # 改变 LED 的触发模式echo 1 > /sys/class/leds/sys-led/brightness # 点亮 LEDecho 0 > /sys/class/leds/sys-led/bri...
如果soc是带Linux系统的，上面问题该怎么实现
最新发布
02-26
<think>好的，我现在需要帮助用户解决在运行Linux的SOC上如何实现两套程序（正常应用和产线EOL程序）的切换。用户之前已经询问过不带OS的SOC的情况，现在转向带Linux的情况，需要调整方案。 首先，我需要回想一下之前的回答。在无OS的情况下，主要通过Bootloader、存储分区和标志位来实现切换。现在用户提到的是带Linux的系统，所以需要考虑Linux环境下的不同机制。 用户的需求是在Linux系统中运行两个不同的程序，并能够在需要时切换。可能的场景是在生产线上，EOL程序用于测试，而正常应用是最终用户使用的。用户需要知道如何设计启动流程、存储管理以及触发切换的方法。 接下来，我需要分析带Linux的SOC有哪些不同的地方。Linux通常从存储设备（如eMMC、SD卡、Flash）启动，启动流程包括Bootloader（如U-Boot）、内核和根文件系统。因此，切换程序可能需要修改启动参数、更换根文件系统或内核，或者使用不同的用户空间程序。 可能的实现方式包括： 1. 使用不同的根文件系统分区，通过Bootloader选择启动哪个分区。 2. 在用户空间中通过脚本或服务来启动不同的应用程序，可能结合启动标志或配置文件。 3. 使用系统服务或守护进程来管理两种程序的切换，可能需要重新启动某些服务而不是整个系统。 4. 利用Linux的动态功能，如容器或虚拟化，但用户可能更倾向于简单的方法。 需要考虑到生产环境的要求，比如切换的可靠性、是否需要重启系统、数据共享等问题。此外，安全性也很重要，防止误切换或未授权访问。 用户可能没有说明是否需要无缝切换，或者是否允许重启。在生产线环境中，重启可能是可以接受的，尤其是在测试完成后需要切换到正常模式的时候。因此，基于启动参数的方案可能更可靠，因为重启可以确保环境干净。 另一个方面是存储布局。带Linux的系统通常有更复杂的存储结构，包含Bootloader分区、内核分区、根文件系统分区等。可能需要为EOL和正常应用设置不同的根文件系统，或者在同一根文件系统中通过不同的目录或脚本来管理。 还需要考虑如何触发切换。可能的触发方式包括物理按钮、软件命令、配置文件修改，或者通过某种生产测试信号。在Linux用户空间，可以通过写入文件（例如在/sys或/proc中的虚拟文件系统）或运行特定命令来触发切换。 数据共享方面，可能需要使用持久的存储区域，如单独的Flash分区或文件，以便两个程序都能访问测试结果或配置数据。 安全性方面，需要确保切换机制不会被意外触发，可能需要权限控制或加密验证。 现在需要将这些思路组织成一个清晰的步骤，涵盖存储设计、Bootloader配置、根文件系统管理、触发机制、切换流程以及数据共享和安全性。同时，要对比之前的无OS方案，指出在Linux下的不同之处，例如利用U-Boot的环境变量、多个根文件系统、systemd服务等。 还需要考虑是否需要双系统（两个独立的根文件系统）还是单系统下不同应用模式。双系统切换可能需要切换内核或设备树，但会增加复杂性。而单系统下通过脚本或服务切换可能更简单，但需要确保两个程序不会冲突。 可能的步骤包括： 1. 分区设计：为EOL和正常应用准备不同的根文件系统分区。 2. U-Boot脚本：根据标志决定启动哪个根文件系统。 3. 标志管理：在U-Boot环境变量或特定存储位置保存启动标志。 4. 切换触发：在用户空间通过命令或工具修改标志并重启。 5. 数据共享：使用独立分区或文件存储共享数据。 6. 安全性：设置权限，签名验证镜像等。 需要验证这些步骤的可行性，例如U-Boot是否支持从不同分区加载根文件系统，如何修改环境变量等。同时，要确保用户了解如何修改这些配置，可能需要具体命令或配置示例。 最后，要总结注意事项，如避免分区重叠、确保引导顺序正确、测试重启后的切换流程等，以及可能的扩展方案，比如使用容器或双系统热切换等高级方法。</think>在基于 Linux 的 SoC（系统级芯片）上实现两套程序（正常应用程序和产线 EOL 程序）的切换，需要结合 Linux 的启动流程、存储管理和用户空间设计。以下是具体实现方案： --- ### **1. 核心思路** - **双根文件系统分区**：为正常应用和 EOL 程序分别分配独立的根文件系统（rootfs），实现隔离。 - **Bootloader 控制**：通过 U-Boot 等引导加载程序动态选择启动的根文件系统。 - **触发机制**：在用户空间或 U-Boot 层面定义切换条件（如文件标志、GPIO 信号或命令）。 - **数据共享**：通过独立存储分区或文件实现数据传递（如校准参数、测试结果）。 --- ### **2. 具体实现步骤** #### **步骤1：存储分区设计** 将存储设备（如 eMMC、SD 卡或 Flash）划分为以下分区： - **Bootloader 分区**：存放 U-Boot。 - **内核分区**：存放 Linux 内核和设备树（可共用或分两个版本）。 - **APP rootfs 分区**：正常应用程序的根文件系统。 - **EOL rootfs 分区**：产线测试程序的根文件系统。 - **共享数据分区**：格式化为通用文件系统（如 ext4），供两个程序读写。 - **标志分区**：存储当前启动模式的标志（如文本文件或 U-Boot 环境变量）。 示例分区表： ``` | U-Boot | Kernel | APP_rootfs | EOL_rootfs | Shared_Data | Flags | ``` #### **步骤2：U-Boot 配置** 修改 U-Boot 的启动脚本（如 `bootcmd`），实现动态选择根文件系统： 1. **读取启动标志**：从 Flags 分区或 U-Boot 环境变量中获取当前模式。 2. **动态设置内核参数**：根据标志选择对应的 `root=` 参数（指向 APP 或 EOL 的根文件系统分区）。 3. **支持手动切换**：在 U-Boot 倒计时阶段，通过按键中断进入命令行，手动切换模式。 **U-Boot 脚本示例**： ```bash # 从 Flags 分区读取启动模式（假设标志存储在 mmc 0:6 分区） load mmc 0:6 ${loadaddr} /boot_mode.txt if test "$(env read -b ${loadaddr})" = "EOL"; then setenv root_partition mmc 0:3 # EOL rootfs 分区 else setenv root_partition mmc 0:2 # APP rootfs 分区 fi # 设置内核启动参数 setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p${root_partition} rw # 启动内核 bootm ${kernel_addr} ``` #### **步骤3：用户空间切换逻辑** 在 Linux 用户空间中实现模式切换： - **从 APP 切换到 EOL**： 1. 用户触发命令（如 `eol-tool --enable`）。 2. 工具向 Flags 分区写入 `EOL` 标志（需权限控制）。 3. 执行系统重启：`reboot`。 4. U-Boot 检测到标志后启动 EOL 根文件系统。 - **从 EOL 切换回 APP**： 1. EOL 测试完成后，清除或修改标志为 `APP`。 2. 重启系统，U-Boot 加载正常根文件系统。 **示例脚本**： ```bash # 切换为 EOL 模式 echo "EOL" > /mnt/flags/boot_mode.txt sync reboot ``` #### **步骤4：数据共享设计** - **共享数据分区**：挂载为 `/mnt/shared`，供两个程序读写。 - **权限控制**：通过 Linux 用户组或文件权限限制访问。 - **同步机制**：测试数据写入共享分区后，调用 `sync` 确保持久化。 --- ### **3. 关键实现技术** #### **(1) 动态根文件系统切换** - **内核参数传递**：通过 `root=` 指定根文件系统设备路径（如 `/dev/mmcblk0p2`）。 - **设备树兼容性**：若 EOL 程序需要特殊外设配置，可为 EOL 模式单独编译设备树（`.dtb`）。 #### **(2) 触发机制设计** - **硬件触发**：通过 GPIO 按键驱动或 `sysfs` 接口检测物理信号。 ```bash # 监控 GPIO 引脚状态 echo 24 > /sys/class/gpio/export echo in > /sys/class/gpio/gpio24/direction if [ $(cat /sys/class/gpio/gpio24/value) -eq 1 ]; then switch_to_eol fi ``` - **软件触发**：通过系统服务或 REST API 接收切换指令。 - **生产自动化**：在 EOL 根文件系统中设置开机自动运行测试脚本，完成后自动切回 APP。 #### **(3) 安全性设计** - **写保护**：对 Flags 分区设置只读权限，切换时临时解除。 ```bash # 挂载 Flags 分区为可写 mount -o remount,rw /mnt/flags ``` - **数字签名**：对根文件系统镜像进行签名校验，防止篡改。 - **权限隔离**：使用 `systemd` 服务限制切换工具的访问权限。 --- ### **4. 示例流程图** ``` 上电启动 │ ↓ U-Boot 运行 │ ├─ 读取 Flags 分区 │ ├─ 若标志为 APP → 加载 APP rootfs │ └─ 若标志为 EOL → 加载 EOL rootfs │ └─ 检测按键或串口命令 │ └─ 触发切换 → 修改标志并重启 ``` --- ### **5. 扩展方案（无需重启）** - **容器化**：将 EOL 程序封装为 Docker 容器，在 APP 系统中按需启停。 ```bash # 启动 EOL 容器 docker run --privileged -v /dev:/dev eol-image ``` - **Systemd 服务单元**：通过 `systemctl` 管理两套程序的服务。 - **双用户会话**：在图形界面中为 EOL 测试提供独立会话（需桌面环境支持）。 --- ### **6. 注意事项** - **分区对齐**：确保 eMMC/SD 卡分区与硬件块大小对齐，避免性能下降。 - **日志管理**：为 EOL 程序单独配置日志路径（如 `/var/log/eol.log`）。 - **回退机制**：若 EOL 启动失败，U-Boot 应支持自动回退到 APP 模式。 - **生产优化**：EOL rootfs 可裁剪为最小化系统，缩短启动时间。 --- ### **7. 适用场景对比** | **方案** | **优点** | **缺点** | |------------------------|-----------------------------|-----------------------------| | 双根文件系统分区 | 隔离性强，可靠性高 | 占用更多存储空间 | | 容器化 | 无需重启，资源利用率高 | 需要容器运行时支持 | | Systemd 服务管理 | 切换速度快，开发简单 | 隔离性较差，需避免资源冲突 | --- 通过上述方法，可在运行 Linux 的 SoC 上灵活切换正常应用与产线测试程序。具体实现需根据硬件资源、生产流程和运维需求调整设计。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值