[U-Boot-Users] Relocation of symbols?

Wolfgang Denk wd at denx.de
Tue Jun 28 02:21:27 CEST 2005


In message <528646bc050627152162d1dba at mail.gmail.com> you wrote:
>
> The problem with relocation is that it adds a layer of complexity to
> the debug process after jumping into RAM.  Things such as the

It's nothing compared to what you get with a two stage  process.  You
either  end  up  with  lots  of  code duplication (and duplication of
problems and a huge memory footprint) or with a system that is a PITA
to port to new hardware.

> 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.

Remember that this effects only staticaly intialized pointers. 

The simple thing to do is to avoid these.

There are other restrictions like having no writable data segment nor
zeroed bss space in the starup phase. We  can  live  with  this  just
fine.

> 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

Sorry, I don't understand what you mean.

> relocation problem.  When relocation hangs, it can be difficult to
> isolate the problem down to code running before or after relocation. 

No, this is a trivial case. When relocation hangs,  then  your  SDRAM
initialization is broken. Period.

> 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

You don't understand. The problems are NOT int the  "running  in  RAM
part".  This  is  simple  stuff.  It usually just works, once you got
there. We spend 95% of teh porting and debugging time  in  the  other
part.

> 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.  :-)

Been there before. I know exactly why I don't  want  to  change  this
part  of  the  design. Feel free to try it out on your own. Port your
code to 3 or 4 boards. I'm sure we'll see you back here soon.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                 -- Wernher von Braun




More information about the U-Boot mailing list