On Sat, Oct 9, 2010 at 4:57 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:
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.
Ok, I know what the difference between our opinion now... You means the uboot should always loaded to TEXT_BASE(for nand case, as you said). So when we run to board_init_f, we don't need any relocation.
I am just feel put the code arrange like this would lose a good feature as original, tftp the uboot to a different place and use the go command to debug it.
Another question here, why the original implementation now call as CONFIG_SYS_ARM_WITHOUT_RELOC? I think CONFIG_SYS_ARM_WITH_RELOC is correct, for it do the relocation at the very begining. :-p
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.
Best regards, Lei