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?