From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sat, 09 Oct 2010 10:57:09 +0200 Subject: [U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE In-Reply-To: References: <4CB01D2A.1000708@free.fr> <4CB0238F.8090702@free.fr> Message-ID: <4CB02E65.70205@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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, -- Albert.