public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Wegner <wolfgang@leila.ping.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 12/26] ARM: add relocation support
Date: Thu, 16 Sep 2010 12:18:10 +0200	[thread overview]
Message-ID: <20100916101810.GH25692@leila.ping.de> (raw)
In-Reply-To: <4C91E93B.4080502@gmail.com>

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.

Regards,
Wolfgang

  reply	other threads:[~2010-09-16 10:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-11 18:16 [U-Boot] [PATCH 12/26] ARM: add relocation support Heiko Schocher
2010-09-15 21:06 ` Albert ARIBAUD
2010-09-16  5:09   ` Heiko Schocher
2010-09-16  6:23     ` Alessandro Rubini
2010-09-16  7:06       ` Wolfgang Denk
2010-09-16  7:18         ` Graeme Russ
2010-09-16  8:23           ` Wolfgang Denk
2010-09-16  9:54             ` Graeme Russ
2010-09-16 10:18               ` Wolfgang Wegner [this message]
2010-09-16 10:49                 ` Albert ARIBAUD
2010-09-16 11:06                 ` Wolfgang Denk
2010-09-16 11:24                   ` Wolfgang Wegner
2010-09-16 10:50     ` Albert ARIBAUD
2010-09-16 11:29       ` Wolfgang Denk
2010-09-16 20:20         ` Albert ARIBAUD
2010-09-16 21:26           ` Wolfgang Denk
2010-09-17  6:16             ` Albert ARIBAUD
2010-09-17 11:05               ` Wolfgang Denk
2010-09-17 12:58                 ` Albert ARIBAUD
2010-09-17 14:52                   ` Wolfgang Denk
2010-09-17 16:39                     ` Albert ARIBAUD
2010-09-17 19:04                       ` Wolfgang Denk
2010-09-17 22:19                         ` Albert ARIBAUD
2010-09-17 22:42                           ` Wolfgang Denk
2010-09-17 23:25                             ` Albert ARIBAUD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100916101810.GH25692@leila.ping.de \
    --to=wolfgang@leila.ping.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox