Le 09/10/2010 10:24, Lei Wen a écrit :
For arm926, TEXT_BASE should be the FLASH location (if booting from NOR) or a location in DRAM (for NAND and other methods).
Yeah, got that. The TEXT_BASE of 0xf00000 in my case is the exactly what I want to uboot run during its run time.
Watch out: TEXT_BASE does not define where u-boot will run, only where it will *start running*. With relocation, u-boot will run as high in RAM as can be.
I have had little difficulty in running the .got relocation code in a Marvell oront5x (arm926ejs too), except for some functions called from board_init_f which did not respect the general rule that code run before relocation should only access gd; one place in orion5x wrote to global variables, which always was a no-no and only happened to work because the arm926ejs init sequence did not run in proper order.
Have you tried load the uboot to different place with tftp or something else? When I load the uboot to the TEXT_BASE and run, there is also no issue...
Not sure I understand what you mean here. U-boot is assumed to *start* located at TEXT_BASE, then moved up in RAM, so there should *never* be issues with starting u-boot at its TEXT_BASE.
However, .got relocation has shortcomings of its own; mainly, it requires manual fixups in many places within the code. I have provided patches which replace .got relocation with ELF relocation (look up [ELF-RELOC] tags in the posts), which eliminates the need for any manual fixup; you may want to try this, as it might eventually replace the .got patches.
Glad to hear this. :-) But my problem is before relocating, the new scheme call the init_sequence in board_init_f, while the TEXT_BASE keep the function entry as static value during compile time. Does the ELF relocation could bring us a relative jump when call the init_sequence table?
Short answer is relocation brings a way to fix all the code and data for correct relocation.
Note however, that when board_init_f runs, relocation has not happened yet, but OTOH, board_init_f is running at TEXT_BASE, so no relocation is needed yet. We need relocation fixup only once the code is moved to top of DRAM, and we want to execute board_init_r there.
If you flash u-boot at its TEXT_BASE intended NOR FLASH location, then any issue within board_init_f will probably be caused by the code trying to write to a global other than gd.
Thanks, Lei
You're welcome.
Amicalement,