2-EMMC启动及各分区文件生成过程

EMMC的使用比nand flash还是复杂一些,有其特有的分区和电器性能

1、启动过程介绍

跟普通nand或spi flash不同,uboot前面还有好几级

在vendor某些厂商的设计中,ATF并不是BOOTROM加载后的第一个启动镜像,可能是这样的:
BOOTROM—>PL—>ATF—>optee—>uboot…, 在PL阶段就已经将ATF/optee/uboot镜像的load到内存了.

image

ATF(ARM Trusted firmware)完成启动流程:https://blog.youkuaiyun.com/u014426028/article/details/117949006?spm=1001.2014.3001.5501

ATF(ARM Trusted firmware):https://blog.youkuaiyun.com/shuaifengyun/category_6919265.html

MTK系统启动流程:https://www.likecs.com/show-203730440.html

Bpi-r64 quick start (boot from eMMC):https://forum.banana-pi.org/t/bpi-r64-quick-start-boot-from-emmc/9809

2、BL1(ROM)启动检测

从启动流程可以看到BL1属于固化在芯片内部ROM里面的一小段代码,我们修改不到。

其作用比较简单,主要有
a.初始化ISRAM和EMMC
b.当系统全擦后 ,也会配置USB,用来仿真USB端口下载镜像。
c.从EMMC中加载preloader到ISRAM中执行。

比如MT7622支持EMMC、SD卡、SPI Nor/Nand Flash

在《MT7622A_Datasheet.pdf》里面的strapping Options章节,有定义启动顺序

Bit[1]:NREB和Bit[0]:NWEB两个引脚

  • 00:SPI-NOR -> eMMC -> SDXC
  • 01:SPI-NAND -> eMMC -> SDXC
  • 10:SLC-NAND -> eMMC -> SDXC
  • 11:SDXC -> eMMC -> SLC-NAND

BL1启动后,根据引脚的设备,会依次从上面的选项启动,哪个初始化成功就用哪个启动。

3、BL2(preloader)生成过程

BL2的代码属于ATF的一部分arm-trusted-firmware-mediatek-2021-05-08-d2c75b21,ATF的package编译后会生产bl2.bin

Built /
<think> 我收到了用户的查询,是关于在uboot环境下通过挂载内存文件系统来访问eMMC某个分区文件的可行性。用户还提供了几个引用来源,我需要仔细分析这些引用内容。 我查看引用[1],它解释了linux系统挂载emmc分区的基本原理:uboot启动时读取kernel到DDR,kernel启动后挂载分区才能访问文件。这说明在uboot阶段分区尚未挂载,访问需要特定方式。 引用[2]提到通过修改uboot环境变量如root=/dev/mmcblk0p3来指定根文件系统分区,但这是在kernel启动后的行为,不是uboot本身的功能。 引用[3]显示bootargs参数由uboot设置并传递给内核,重点在配置启动参数而非uboot直接操作文件系统。 引用[4]说明uboot环境变量可保存到EMMC,涉及存储配置但不支持文件系统访问。 总体来看,所有引用都指向同一个结论:uboot的核心功能是初始化硬件和加载内核,并不包含完整的文件系统驱动。其文件访问能力仅限于特定格式(如FAT/EXT4)的简单读写,无法实现完整的挂载操作。 用户询问的"挂载内存文件系统访问eMMC分区"在uboot环境不可行,因为: - 内存文件系统(如tmpfs/ramfs)需要内核支持 - uboot缺乏文件系统挂载机制 - 访问文件依赖特定命令而非通用挂载 替代方案是使用uboot自带的文件操作命令直接读写分区,例如fatload/ext4ls等,但这属于低级访问而非挂载。 我应该明确告知用户限制条件,同时提供可行的替代方法建议。生成的相关问题要围绕uboot文件操作和启动流程优化。 </think> 基于引用内容和UBoot特性分析,在**UBoot环境下直接挂载内存文件系统访问eMMC分区文件是不可行的**,原因如下: --- ### **核心限制分析** 1. **UBoot的文件系统支持有限** UBoot主要提供**基础文件系统驱动**(如FAT/EXT4),但仅支持**简单读写操作**(如`fatload`、`ext4ls`),**不具备完整的挂载功能**。挂载操作需要内核级文件系统驱动和内存管理支持[^1][^3]。 2. **内存文件系统(如tmpfs/ramfs)依赖内核** 内存文件系统需要内核动态管理内存页和文件系统元数据,而UBoot作为**引导加载程序,无此能力**。其"内存文件系统"仅指加载文件到DDR运行(如`fatload mmc 0:1 ${addr} file`),并非真实挂载[^1]。 3. **分区访问机制差异** UBoot通过**原始块设备访问**eMMC分区(如`mmc dev 0`切换设备,`mmc part`查看分区),文件操作需明确分区格式(如`ext4ls mmc 0:2 /`)。挂载动作需传递`root=`参数给内核,由内核完成[^1][^3]。 --- ### **替代解决方案** 若需在UBoot阶段访问eMMC文件,可采用以下方法: ```bash # 示例:读取EXT4分区文件 ext4ls mmc 0:2 / # 列出分区根目录 ext4load mmc 0:2 ${loadaddr} /path/to/file # 加载文件到内存 # 示例:读写FAT分区 fatls mmc 0:1 fatwrite mmc 0:1 ${addr} filename ${filesize} ``` --- ### **挂载流程的正确阶段** 1. **UBoot阶段** - 初始化eMMC硬件 - 加载内核和设备树到DDR - **设置`bootargs`**(如`root=/dev/mmcblk0p2 rootfstype=ext4`)[^3] 2. **内核启动后** - 解析`bootargs`定位根文件系统 - **加载文件系统驱动** - **完成分区挂载**,用户空间可访问文件[^1][^2] --- ### 相关问题 1. UBoot如何通过环境变量配置eMMC启动参数? 2. 内核挂载根文件系统失败有哪些常见原因? 3. UBoot支持哪些文件系统操作命令? 4. 如何调试UBoot与eMMC的通信故障? > 关键点:文件系统挂载是内核功能,UBoot仅提供**基础存储访问**和**启动参数传递**[^1][^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Creator_Ly

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值