On Sat, Oct 9, 2010 at 4:57 PM, Albert ARIBAUD <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
