U-Boot中‘go’命令异常行为及替代方案咨询

我编写了一个面向树莓派3B（ARM64-CortexA53）的极简裸机程序，用于从EL2（异常级别2）切换至EL1，采用U-Boot作为引导加载程序。通过tftpboot命令将代码加载至RAM，使用go命令启动程序执行，且不期望将控制权返回给U-Boot。

当代码使用ERET指令切换至EL1时，跳转位置的RAM中为随机数据；但通过JTAG检查ERET执行前的同一RAM地址时，能看到有效的程序内容。该程序在无U-Boot的环境下可正常运行，但在U-Boot环境中，EL1阶段会执行随机数据。

请问该行为的原因是什么？是否有比go命令更优的替代方案？

一、问题原因 #

• U-Boot的Cache/MMU状态干扰：U-Boot运行时会开启MMU和Cache（L1/L2），而裸机程序切换到EL1时若未正确初始化EL1的MMU和Cache配置，会导致EL1的内存映射与U-Boot的EL2映射不一致。此时CPU在EL1下无法正确寻址加载的程序内容，表现为随机数据；而JTAG是直接物理访问RAM，因此能看到有效内容。
• U-Boot保留内存区域冲突：程序加载的RAM地址可能属于U-Boot自身占用或保留的区域（如栈、全局变量、设备树缓冲区等）。go命令不会释放这些内存，程序执行过程中（尤其是切换EL阶段时），U-Boot的残留数据或后台操作（如看门狗、定时器中断）可能覆盖程序内容，导致ERET跳转后执行无效数据。
• EL1异常向量表配置错误：若程序未正确设置EL1的异常向量表，ERET跳转时可能进入错误的异常处理流程，执行未初始化的内存区域。无U-Boot环境下系统启动上下文更简单，不会出现此类冲突。

二、替代方案 #

• 使用bootm或bootz命令：将程序打包为U-Boot兼容的镜像格式（如uImage、zImage），使用bootm或bootz启动。这两个命令会完成U-Boot的收尾工作：关闭不必要的中断、释放自身占用的内存、设置干净的启动上下文，为裸机程序提供更可靠的执行环境。
• 显式清理U-Boot遗留状态：若坚持使用go命令，需在程序开头添加以下操作：
  • 关闭EL2的所有中断（清除DAIF寄存器的中断掩码位）
  • 禁用EL2的MMU和Cache，或重新配置EL1的MMU，确保虚拟地址到物理地址的映射与程序加载的物理地址一致
  • 覆盖U-Boot的异常向量表，避免EL1阶段触发U-Boot的异常处理
  • 重新初始化EL1的栈指针，避免与U-Boot的栈冲突
• 指定独立内存区域加载程序：通过U-Boot环境变量loadaddr指定远离U-Boot自身占用的内存地址（比如树莓派3B可选择0x1000000），用tftpboot 0x1000000 your_program.bin加载程序，再执行go 0x1000000启动，确保程序区域不会被U-Boot覆盖。

内容的提问来源于stack exchange，提问作者Little Tree