海思Hi3519AV100 EMMC启动模式深度解析：uboot配置修改与内存参数调试实战

最新推荐文章于 2026-03-09 00:34:40 发布

原创

最新推荐文章于 2026-03-09 00:34:40 发布 · 971 阅读

标签

#海思 #Hi3519AV100 #linux系统移植 #uboot

海思Hi3519AV100 EMMC启动模式深度解析：uboot配置修改与内存参数调试实战

如果你已经成功地在海思Hi3519AV100平台上跑通了SPI Nor Flash启动，那么转向EMMC启动模式时，可能会觉得不过是换个存储介质，配置一下分区表而已。但真正上手后，尤其是当板子烧录完一片寂静，串口只有零星打印甚至毫无反应时，那种挫败感会瞬间将你拉回现实。EMMC启动，特别是涉及到uboot的内存参数配置，远不止是修改一个BOOT_MEDIA=emmc那么简单。它更像是一场与芯片底层启动流程和内存映射的精密对话，任何一个参数的错位，都可能导致整个系统在加载的临界点上“失声”。

这篇文章，就是为你——那些已经熟悉海思SDK基础编译流程，却在EMMC启动的深水区遇到棘手问题的中高级开发者准备的。我们不重复那些“第一步解压SDK，第二步执行sdk.unpack”的基础操作，而是直接切入核心：为什么uboot在EMMC模式下需要对内存参数进行特殊配置？ 我们将以PHYS_SDRAM_1_SIZE这个关键宏为线索，深入剖析海思SDK中osdrv_mem_cfg.sh脚本的运作机制，并结合真实的调试案例，展示如何定位和解决因内存参数错误导致的系统无法启动问题。你会发现，解决这类问题的过程，本身就是对海思平台启动架构一次绝佳的理解机会。

1. 理解EMMC启动模式下uboot内存配置的特殊性

在SPI Nor Flash启动时，uboot的加载和运行相对“线性”。芯片的BootROM从固定的SPI地址读取uboot镜像到内部SRAM或直接映射的DDR内存中执行。然而，切换到EMMC启动模式后，情况变得复杂。EMMC是一种块设备，其访问协议和时序与SPI Flash截然不同，uboot在初始阶段需要先初始化EMMC控制器，然后才能从中读取更大的uboot镜像或内核。

这个初始化过程，严重依赖于正确的DDR配置。因为EMMC控制器驱动、数据缓冲区以及uboot自身重定位后的运行空间，都需要在DDR内存中。如果uboot编译时预设的DDR大小（PHYS_SDRAM_1_SIZE）与实际板载的DDR容量不符，就可能引发一系列诡异的问题：

uboot无法完成重定位：uboot在初始阶段（可能在SRAM中运行）会将自己拷贝到DDR的高端地址运行以获取更大空间。如果DDR大小设置错误，这个拷贝的目标地址可能无效，导致程序跑飞。
EMMC读写失败：驱动EMMC进行读写操作需要DMA缓冲区，这些缓冲区地址如果超出了真实DDR范围，会导致数据传输失败，表现为uboot无法从EMMC加载后续镜像。
内存越界与数据损坏：错误的内存边界会导致栈或堆操作破坏其他关键数据，引发不可预知的崩溃，这类问题最难调试。

那么，PHYS_SDRAM_1_SIZE这个值是如何传递给uboot源码的呢？答案就藏在海思SDK的osdrv目录下的一个关键脚本——osdrv_mem_cfg.sh中。这个脚本是连接顶层.config配置与底层uboot、内核内存参数的核心桥梁。许多开发者只知其存在，却不知其详细运作逻辑，一旦出现问题便无从下手。