[U-Boot-Users] Relocation of symbols?

[Grant Likely <glikely@gmail.com>]

On 6/27/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc05062709261380120e@mail.gmail.com> you wrote:
> > relocation)?  As opposed to a a two stage process with a small chunk
> > of bootstrap code encapsulating the main u-boot image.  The bootstrap
> 
> Such a "small chunk" would have to include the most critical hadrware
> initialization, especially that of the  SDRAM.  If  you  follow  this
> mailing  list  for a while you will know that this alone makes 99% of
> all the "help me" postings on this list, even  though  it  is  really
> easy  to  debug:  you have printf() and all the like. Now assume this
> was in a "small chunk" which has to work without all these features -
> and which is failing silently as a black box.
I do understand this; I wasn't very clear what I meant, see below.

> 
> > code being linked seperatly from the main image so each image runs in
> > the address space it is linked to.  (like a Linux zImage; bootstrap
> > code only responsible for initializing RAM, copying the main image and
> > jumping to it).
> 
> The "only" in this sentence in inappropriate. This is one of the most
> critical areas, and you really want to have all comfort for debugging
> that you can get.
Let me clarify: I'm using "only" to refer to responsibilities, not to
code size or debug facilities.  I agree that bootstrapping is the most
critical function and debug support is non-negotiable.  I meant that
the bootstrap is responsible to get the board ready for the second
stage; It would not have any exotic functionality for were to get the
second stage or handling boot options.  All that would stay in the
second stage.

> 
> Try searching this list  and  count  how  many  people  report  about
> problems  where the system hangs or acts weird just after relocation.
> Assume this happened in some minimal assember code  without  console,
> without printf etc. You really don't want to have that.
And I do understand this; I was not suggesting an absolute minimalist
environment.  Other than final footprint size (which is not a small
issue either), there is nothing preventing common code from being
linked into both images.  Are there any estimates/measurements on how
much code is executed both before and after relocation?

The problem with relocation is that it adds a layer of complexity to
the debug process after jumping into RAM.  Things such as the
manipulating the command tables so the pointers match up again.  Every
time a new static or global is added, you need to worry about such
things.

For example; when built for flash you cannot load the image into RAM
and run it (i.e. from dBug) to see if the code after relocation is
working correctly.  This makes it more difficult to track down a
relocation problem.  When relocation hangs, it can be difficult to
isolate the problem down to code running before or after relocation. 
However, if it was a two stage image, you could run the RAM stage from
dBug.  If it doesn't work then you know you need to fix the RAM image
problem before fixing the ROM code.  If it does work then you know the
problem is with the ROM portion.  As a bonus, you know that code
running out of RAM is identical regardless of whether you've booted
from FLASH or not.

Ultimatly, I'm asking/debating whether or not a two-image scheme would
make it simpler to debug.  Granted there are other issues, such as
duplicate copies of functions; but that's why I'm asking, to get other
perspectives and become a better designer.  :-)

Comments?