[U-Boot] [PATCH 12/26] ARM: add relocation support

Albert ARIBAUD
2010-09-16T10:49:54Z

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.