u-boot：搬迁 [英] u-boot : Relocation

问题描述

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

This one is a basic question related to u-boot.

为什么u-boot代码重新定位？

Why does the u-boot code relocate itself ?

好的，如果u-boot是从NOR闪存或引导ROM空间执行的，但是如果从SDRAM运行，为什么它必须再次重新定位？

Ok, it makes sense if u-boot is executing from NOR-flash or boot ROM space but if it runs from SDRAM already why does it have to relocate itself once again ?

推荐答案

这个问题经常出现。有时也好答案。

This question comes up frequently. Good answers sometimes too.

我同意在开发过程中将构建加载到SDRAM中非常方便。这对我有用，我一直都这样做。我在闪存中有一些不启用MMU /缓存的启动代码。对于我的u-boot构建，我在flash和ram构建之间切换CONFIG_SYS_TEXT_BASE。我经常运行我的开发版本。

I agree it is handy to load the build to SDRAM during development. That works for me, I do it all the time. I have some special boot code in flash which does not enable MMU/cache. For my u-boot builds I switch CONFIG_SYS_TEXT_BASE between flash and ram builds. I run my development builds that way routinely.

实际上，处理MMU /缓存的重新初始化是一件非常重要的事情。而U-Boot从简单性中获益于IMO，因为没有这样的东西。

As a practical matter, handling re-initialization of MMU/cache would be a nontrivial matter. And U-Boot benefits IMO from simplicity, as result of leaving out things like that.

Denx的技术负责人表达了他的意见。 IIRC他的其他职位比那个更强烈的措辞。我得到的印象是他不喜欢重复自己。

The tech lead at Denx has expressed his opinion. IIRC his other posts are more strongly worded than that one. I get the impression that he does not like to repeat himself.

更新：为什么重新定位。 RAM的内存访问速度比ROM快，特别是如果目标没有指令缓存，这一点尤为重要。从RAM执行允许闪存重新编程; （更小）允许使用陷阱指令进行软件断点;也更像是目标的正常操作模式，从RAM的突发读取是否在早期启动时会出现故障。

update: why relocate. Memory access is faster from RAM than from ROM, this will matter particularly if target has no instruction cache. Executing from RAM allows flash reprogramming; also (more minor) it allows software breakpoints with "trap" instructions; also it is more like the target's normal mode of operation, so if e.g. burst reads from RAM are iffy the failure will be seen at early boot.

这篇关于u-boot：搬迁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！