[U-Boot-Users] Relocation of symbols?

Wolfgang Denk wd at denx.de
Mon Jun 27 22:00:22 CEST 2005


In message <528646bc05062709261380120e at mail.gmail.com> you wrote:
> 
> What is the design decision behind u-boot building as a single
> relocatable binary (with all the complexities associated with

Making it as easy to port to new hardware and to debug  as  possible.
Which  includes  for example initializing a serial (or other) console
port as soon as possible in the  initialization  sequence.  Which  in
turn requires access to a lot of functions in the "general" code like
stdio  and  string  functions, access to the environment (to read the
baudrate definition), which in turn may require access to  I2C  (like
to access an EEPROM) etc.

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

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

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.

> I can see that a two stage scheme would sidestep the relocation issues
> mentioned above and should make probing with a debugger simpler.  What
> are the advantages of the single binary approach?  Image size perhaps?

No, the major concern is to make U-Boot easy to debug  and  to  port.
All the things that happen after relocation are "simple" issues ;-)

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
The human race is faced with a cruel choice: work  or  daytime  tele-
vision.




More information about the U-Boot mailing list