In message 528646bc05062709261380120e@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