In message fa686aa40707030952v27a9ac98of1c5c1d33f3b9ae4@mail.gmail.com you wrote:
I actually think we should go a step farther. I think we should split u-boot into two linked images; a setup wrapper and u-boot proper (in the same way that the linux kernel is wrapped by a zImage wrapper). The sole purpose of the setup wrapper is to configure RAM and copy the u-boot proper image to location at the end of RAM. The u-boot proper image starts with the assembler routines to setup the C environment and fixup the relocation symbols before jumping into main.
I started with such a design in PPCBoot a long, long time ago. The problem is that memory setup is tricky, and you want to be able to use C to implement it, and you want to have debug output on the serial console as well. Which means you will have to include a *lot* of library functions in the "setup wrapper", which in some cases nearly doubles the flash memory footprint for U-Boot.
The goal should be to get into the u-boot wrapper C environment as soon as possible. The wrapper shouldn't do anything other than initialize RAM, copy code, and provide a little bit of debug output. As much as possible should be deferred to u-boot proper.
Yes, but "provide a little bit of debug output" means printf() and friends, plus console drivers, which in turn means reading the environment (for the console baudrate) and probably the device tree (for the hardware configuration of the console port), etc.
I see a few approaches to handle this:
- eliminate console output from the wrapper. (by far the easiest,
but provides no clues when RAM configuration fails).
No, please don't. Don't!
- cut down wrapper functionality in the wrapper (this is just early
boot after all). Eliminate printf() support in the wrapper and make
Remember that U-Boot is not only a tool needed by the end users, it's also a tool used by ourselfs in the board bring up. Don't make our own lifes even more miserable when you have to deal with the next green board.
due with puts(). Reduce the wrapper console driver to output only.
Puts() is not sufficient. I definitely want to be able to print register contents and the like.
Regardless of the approach, the choice of which to use can be made per-board, which is a suitable tradeoff between size and functionality. My gut feel is that for most boards, the boot wrapper will be very small, but I need to do some experiments to know for sure.
Assume something like a MPC8xx with console on SMC1 or SMC2, depending on that the device tree says...
Best regards,
Wolfgang Denk