将u-Boot加载到内存中,而不是将其刷新 [英] loading u-Boot in memory instead of flashing it

查看:72
本文介绍了将u-Boot加载到内存中,而不是将其刷新的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在基于ARM的自定义板上,每当对此进行更改时,我便将u-boot闪存到NAND. (放入一些调试语句/修改).有什么方法可以直接将uboot映像加载到RAM内存中,而不是每次都刷新它吗?

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?

对于linux内核映像,我确实将其加载到内存中,并使用bootm启动该映像.同样,对于u-boot,我正在尝试.请提供您的建议.

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.

推荐答案

飞思卡尔的某人已经为其P1022DS评估系统(以及其他一些评估器)做到了这一点.他们在$ {UBOOTROOT}/doc/README.ramboot-ppc8500文件中提供了有关此过程的有用文档(在U-Boot V2010.12中).该文档非常简洁,未解决许多问题,但是当我需要调试新主板的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.

实际上,拥有不起作用的闪存是您可能要在RAM中调试U-Boot的原因之一. (自述文件中列出了一些原因,与该主题上的其他一些建议相比,这对我来说听起来都很合理)

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)

在我们的情况下,发现早期的原型目标板硬件在与闪存的地址总线连接中包含错误,导致我们无法使用该闪存.在重新设计和重新制造硬件时,我们希望继续测试/调试不依赖闪存的U-Boot配置部分,例如I2C,以太网,FPGA配置,PCIe等.有很多事情与U-Boot映像的来源无关).

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).

通过JTAG接口(使用Codewarrior和USB TAP)将U-Boot加载到RAM中后运行U-Boot,即使我们没有功能性的闪存,也可以继续执行U-Boot提起任务.一旦收到具有正确功能的闪存的目标板的较新版本,我们将返回调试之前无法测试的U-Boot部分.在那之后,U-Boot可以完全发挥作用,我们不必等待董事会旋转就可以取得任何进展.

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.

这篇关于将u-Boot加载到内存中,而不是将其刷新的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆