From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sun, 13 Jan 2013 10:25:24 +0100 Subject: [U-Boot] Running vanilla u-boot v2012.10 on Guruplug In-Reply-To: <2223756.IMG4ajZrZq@moria> References: <1457183.WG9k8kxG45@moria> <20130112155151.424AF201212@gemini.denx.de> <2223756.IMG4ajZrZq@moria> Message-ID: <20130113102524.48fb2cff@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Dirk, On Sat, 12 Jan 2013 20:41:36 +0100, Dirk Heinrichs wrote: > Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk: > > > Did you read the FAQ? Especially > > http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted > > InRAM ? > > Now I did :) Thanx a lot. > > Interesting that [1] states it's possible, though... > > Bye... > > Dirk My experience with starting U-Boot from RAM is that it's usually impossible when U-Boot is meant to start directly from FLASH, mostly (but not only) because the code at some point will rely on being able to keep on running even through access to DRAM is not possible. Now, starting U-Boot *may* be possible when U-Boot is loaded in DRAM before starting it, but is a very tricky and undependable process. For instance, on the Wireless Space target I am maintaining, and which is supposed to be preloaded from FLASH into DRAM by a ROM monitor, if I start the OpenOCD server, then in the console, do a break and / or a reset halt, I won't be able to load_image u-boot; whereas if I do the same actions as -c options when launching OpenOCD. And I have checked countless times that the DRAM init sequence in the config file is bit-for-bit identical to that used by the KWB which wraps the U-Boot image, and which boots fine on its own. Amicalement, -- Albert.