将 u-Boot 加载到内存中而不是刷新它
在我基于 ARM 的定制板中，每当我对其进行更改时，我都会将 u-boot 闪存到 NAND。 （放置一些调试语句/修改）。有没有什么方法可以直接将uboot映像加载到RAM内存中，而不是每次都刷新它？
对于 Linux 内核映像，我将其加载到内存中并使用 bootm 来启动该映像。同样，对于 u-boot 我正在尝试。请提供您的建议。
In my ARM based custom board, I flash u-boot to NAND whenever I do changes on that. (putting some debug statements/modification). Is there any way to directly load the uboot image in RAM memory instead of flashing it every time?
For linux kernel image I do load it in memory and use bootm to boot that image. Similarly for u-boot I am trying out. Kindly provide your suggestions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
飞思卡尔有人在他们的 P1022DS 评估系统（以及其他一些系统）中做到了这一点。他们在文件 ${UBOOTROOT}/doc/README.ramboot-ppc8500（在 U-Boot V2010.12 中）中提供了有关该过程的一些有用的文档。该文档相当简洁，留下了许多未解答的问题，但当我需要为新板调试 U-Boot、在该板的闪存正常运行之前，我发现这是一个合理的起点。
事实上，拥有不起作用的闪存是您可能想要在 RAM 中调试 U-Boot 的原因之一。 （自述文件中列出了一些原因，与此主题上的其他一些建议相比，它们对我来说听起来都很合理）
在我们的情况下，发现早期原型目标板硬件在与闪存的地址总线连接阻止我们使用该闪存。在重新设计和重新制造硬件的同时，我们希望继续测试/调试 U-Boot 配置中不依赖于闪存的那些部分，例如 I2C、以太网、FPGA 配置、PCIe 等（有有很多东西与 U-Boot 映像的来源无关）。
通过 JTAG 接口（使用 Codewarrior 和 USB TAP）将 U-Boot 加载到 RAM 后运行 U-Boot，使我们能够继续执行 U-Boot 启动任务，即使我们没有可用的闪存。一旦我们收到具有正确运行闪存的新版本目标板，我们就返回调试 U-Boot 中我们之前无法测试的那些部分。此后，U-Boot 功能齐全，我们无需等待主板旋转即可取得任何进展。
Someone at Freescale has done this, for their P1022DS evaluation system (and some others as well). They have provided a somewhat useful document about the process in the file ${UBOOTROOT}/doc/README.ramboot-ppc8500 (in U-Boot V2010.12). This document is pretty terse and leaves many questions unanswered, but I found it a reasonable place to start when I needed to debug U-Boot for a new board, before the flash memory for that board was operating correctly.
In fact, having non-functional flash memory is one reason you might want to debug U-Boot in RAM. (There are a few reasons listed in the README, and they all sound pretty reasonable to me, in contrast to some of the other advice available on this subject)
In our situation, it was found that early prototype target board hardware included an error in the address bus connection to the flash memory that prevented us from using that flash memory. While the hardware was being redesigned and re-fabricated, we wanted to continue testing/debugging those parts of our U-Boot configuration that did not depend on flash memory, for example, I2C, Ethernet, FPGA configuration, PCIe, etc. (there are plenty of things that are independent of where the U-Boot image comes from).
Running U-Boot after loading it into RAM via a JTAG interface (using Codewarrior and the USB TAP) allowed us to continue our U-Boot bring-up tasks, even though we had no functional flash memory. Once we received a newer version of the target board with correctly functioning flash memory, we returned to debugging those parts of U-Boot that we hadn't been able to test earlier. After that, U-Boot was fully functional, and we did not have to wait for a board spin to make any progress.
调试引导加载程序有点困难，但使用正确的工具应该相对轻松。
我处理 PowerPC 架构和 BDI-3000，我可以直接加载和调试到 RAM（当然，在初始化 DDR 控制器之后）。
一种选择是您是否有片上 SRAM 或可配置为片上 SRAM 的 L2 高速缓存。 BDI 可以首先复制到 SRAM 区域，u-boot 执行此操作（例如初始化 DDR 控制器），然后将其自身重新定位到 DDR RAM。绝对比重写一直减慢 Flash 更快。
Debugging a bootloader is a bit difficult, but with the right tools it should be relatively painless.
I deal with the PowerPC achitecture and with a BDI-3000 I can load and debug directly to RAM (of course, after initializing the DDR controller).
One option is if you have on-chip SRAM or L2 Cache that can be configured as on-chip SRAM. The BDI can copy to the SRAM area first, u-boot does it's thing (initialize DDR controller for example), then relocates itself to DDR RAM afterwards. Definitely faster that re-writing to slow Flash all the time.
至少在 2004 年，这是不可能的。
It wasn't possible in 2004, at least.
如果您要运行的 U-Boot 映像具有允许从任意地址运行它的启动代码，那么这应该是可能的。我不知道你的董事会是否属于这种情况。
如果启动代码首先将代码段从当前（相对于 PC）地址复制到最终执行地址（通常在此之前检查这些区域是否不重叠），那么您可以将 .bin 文件加载到RAM 中的任何地址，并使用
go调用它。我看到的第二个障碍是一开始的无条件 RAM 设置代码，许多主板都有这种代码。
It should be possible, if the U-Boot image you want to run has startup code that allows running it from arbitrary addresses. Whether or not that is the case for your board I can't tell.
If the startup code begins by copying the code section from the current (PC-relative) address to the final execution address (usually this is preceded by a check that these areas don't overlap), then you can load the .bin file to any address in RAM, and invoke it using
go.The second obstacle I could see would be unconditional RAM setup code at the beginning, which a number of boards have.
这是 u-boot 文档常见问题解答中的内容：
来源：http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM< /a>
This is what can be read on the u-boot documentation FAQ:
source:http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
这里的问题是，您尝试做的事情违背了引导加载程序的理念。大多数处理器要求代码从Flash开始。该代码称为引导加载程序。 这就是U-boot。
然而，如果你想修改U-boot，使其不是真正的引导加载程序，那么你可以做任何你想做的事。这只是软件。但由于上述原因，不要指望任何主线支持。
The problem here is that what you are trying to do goes against the philosophy of what a bootloader is. Most processors require that code starts from Flash. That code is called a bootloader. That is what U-boot is.
However, if you want to modify U-boot so that it is not a true bootloader, then you can do whatever you want. It's just software. But don't expect any mainline support for the above reasons.
只需记住（注意）您在修改后的 U-Boot 中配置的硬件即可。 U
引导旨在初始化关键模块，其中一些模块无法动态重新配置，或者它们可能无法像在启动时初始化/配置一样执行。
Just take in mind (be care of) the hardware that you are configuring in your modified U-Boot. U
Boot is intended to initialize critical modules, some of them are not able to be re-configured on the fly or they may not performe as if they were initialized/configured at startup.
如果您的目标板支持网络启动，您可以通过网络将 uboot 映像从主机加载到 RAM。
If your Target board support network booting, you can load uboot image from host machine to RAM through network.
您可以使用 USB 启动。 TI 和 Freescale 提供了他们的 USB 启动实用程序。我不知道其他供应商的情况。
You can use usb boot. TI and Freescale provides their usb boot utilities. I don't know about other vendors.
是的，如果您的目标支持 USB/TFTP 或当前 U-boot 可以检测到的任何其他介质，则 U-Boot 的大部分编译结构可能会提供一个 u-boot.bin 文件，该文件是一个扁平的二进制文件目标环境之后我们就可以将u-boot.bin文件加载到静态内存地址区域了。该地址是 U-Boot 代码的入口点，U-boot 可以通过
go 0x执行扁平化的二进制文件。静态内存地址区域可以从u-boot.map文件中推导出来，这个入口点基本上是编译程序的.text区域的地址，通常我们可以在.map文件中使用字符串“Address of section .text set to 0x”进行搜索”。下面是从 USB 执行此操作的示例。这应该可以从 USB 运行 U-Boot，而不会干扰当前代码。
Yes, It is possible most of the compilation structure at the end U-Boot provides a u-boot.bin file which is a flattened binary, if your target supports USB/TFTP or any other medium which current U-boot can detect on you target environment then we can load the u-boot.bin file to the static memory address area. This address is the entry point of U-Boot Code and U-boot can execute the flattened binaries by
go 0x<memory_address>. The static memory address area can be deduced form u-boot.map file, This entry point is basically address to the .text area of compiled program usually can we searched in the .map file with string "Address of section .text set to 0x." Below is the example of doing it from USB.This should run you U-Boot from usb with out disturbing current code.