[U-Boot] [PATCH 12/26] ARM: add relocation support
Wolfgang Wegner
wolfgang at leila.ping.de
Thu Sep 16 13:24:07 CEST 2010
Dear Wolfgang Denk,
On Thu, Sep 16, 2010 at 01:06:01PM +0200, Wolfgang Denk wrote:
> Dear Wolfgang Wegner,
>
> In message <20100916101810.GH25692 at leila.ping.de> you wrote:
[...]
> > 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.
>
> Note the "specially built version". My understanding is that this
> "special building" cannot be avoided in general.
I do not know if it can be avoided in general, but if it is architecture-
dependent, maybe those architectures supporting such a boot procedure
to allow doing this with a single image could be made to support it
out-of-the-box. Then the other architectures could still benefit from
more awareness of something like "CONFIG_MONITOR_IS_IN_RAM" or
"CONFIG_SKIP_LOWLEVEL_INIT".
> > 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.
>
> True. And the image configured that way is not the same binary image
> that you normally load into flash.
Currently it is not, and I do not know if it is possible at all for
every architecture and worth the effort to make a single image for
both cases, but as there seem to be already some architectures out
there with (maybe somewhat limited) support, it looks like an
interesting thought to me.
Best regards,
Wolfgang
More information about the U-Boot
mailing list