Embedded u-boot：重新定位

这是一个与u-boot相关的基本问题

为什么u-boot代码会重新定位自身

---

好的，如果u-boot是从NOR闪存或引导ROM空间执行的，这是有意义的，但是如果它已经从SDRAM运行了，为什么它必须再次重新定位自身呢

这个问题经常出现。有时候也是

我同意在开发期间将构建加载到SDRAM是很方便的。这对我很有用，我一直都是这样。我在flash中有一些特殊的引导代码，它不能启用MMU/缓存。对于我的u-boot版本，我在flash和ram版本之间切换CONFIG_SYS_TEXT_BASE。我经常以这种方式运行开发构建

实际上，处理MMU/cache的重新初始化将是一件非常重要的事情。U-Boot从简单性中获益，因为它省去了类似的东西

Denx的技术负责人已经表达了他的观点。IIRC他的其他帖子比那篇措辞更强硬。我得到的印象是他不喜欢重复自己的话

---

更新：为什么要搬迁。从RAM访问内存的速度比从ROM快，这一点在目标并没有指令缓存的情况下尤为重要。从RAM执行允许闪存重新编程；此外（更次要的是），它允许软件断点与“陷阱”指令；此外，它更像是目标的正常操作模式，因此，如果从RAM的突发读取不确定，则在早期引导时会看到故障。

U-boot必须在内存中保留3个存储区域：1）U-boot本身、2）uImage（压缩内核）和3）未压缩内核。这3个区域必须小心地放置在u形引导中，以防止冲突

---

但是，将u-boot引入DRAM内存的前一阶段引导加载程序（BL2或BL1）不知道u-boot在这3个区域上的计划。因此，它只能将u-boot加载到DRAM内存中较低的地址并跳转到该地址。然后，在u-boot执行一些基本初始化并检测到当前PC不在计划位置后，u-boot调用重新定位功能，将u-boot移动到计划位置并跳转到计划位置。

NOR闪存的代码必须初始化SDRAM，然后将代码从NOR闪存复制到SDRAM，进程将复制自身，因为您可以启用MMU，我们将启动虚拟地址映射。

这不应该关闭。为什么关闭？这不是一个相关的问题吗？需要再投一次票才能重新打开。这个链接实际上并不是问题的答案，而是你显然认为问题背后的动机。在这个问题上，您的MMU重新初始化评论很有意思——我从u-boot加载u-boot的平台没有真正的MMU。