From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 16 Sep 2010 12:49:54 +0200 Subject: [U-Boot] [PATCH 12/26] ARM: add relocation support In-Reply-To: <20100916101810.GH25692@leila.ping.de> References: <4C91A69A.8050102@denx.de> <4C62E8E7.2000407@denx.de> <4C91356B.5060701@free.fr> <20100916062347.GA25290@morgana.i.gnudd.com> <20100916070642.DA3CA15242D@gemini.denx.de> <20100916082313.1DBAD15242D@gemini.denx.de> <4C91E93B.4080502@gmail.com> <20100916101810.GH25692@leila.ping.de> Message-ID: <4C91F652.6050109@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 16/09/2010 12:18, Wolfgang Wegner a ?crit : > On Thu, Sep 16, 2010 at 07:54:03PM +1000, Graeme Russ wrote: > [...] >> I have a 'cold-boot' parameter which is set by the reset vector code. I can >> use this to selectively skip 'once-only' initialisation > [...] >> I don't doubt that you are entirely correct. But there are many ways to >> skin a cat. My problem was to reduce the build->burn->boot development time >> where the burn phase was the longest. The low level boot and device >> initialisation all works and hasn't changed in quite a while, so I can rely >> on what is on my (nearly a year) old image. > > I see this feature not only nice to speed up development, sometimes > it also comes in really handy for production, too - if you have to > struggle with debugging tools that are either plain too stupid to > program some flash devices or are much slower than U-Boot, you > can simply run a specially built version from RAM and/or provide it > with an environment in RAM to do all the actual flashing for the board > production. > >> A common framework (within the bounds of cross-architecture limitations) >> would be nice > > For some targets, there may be fragments present in the code > when searching for CONFIG_MONITOR_IS_IN_RAM, which statically > disables all the low-level initialization to allow U-Boot being > loaded from a first-stage loader or debugger. But beware, it is > not always functional out-of-the-box. For ARM926, you can disable low level init stuff and run from RAM by defining CONFIG_SKIP_LOWLEVEL_INIT. This works and is actively used in kirkwood where low level init is done by a previous loader. (independently you can disable relocation from FLASH to RAM with CONFIG_SKIP_RELOCATE_UBOOT.) Maybe we could start by standardizing a single (set of) config option(s) for skipping inits and have all boards use that? Amicalement, -- Albert.