From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sat, 09 Oct 2010 10:10:55 +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> Message-ID: <4CB0238F.8090702@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 09:53, Lei Wen a ?crit : > Hi Albert, > > On Sat, Oct 9, 2010 at 3:43 PM, Albert ARIBAUD wrote: >> Le 09/10/2010 07:50, Lei Wen a ?crit : >>> Hi, >>> >>> I recently try to port our board code to new uboot, which has been >>> changed to use new relocation scheme. >>> But I found a very strange thing, that is if the uboot is loaded to >>> the TEXT_BASE address, it could run without >>> problem. But if it is loaded to a different place, it fail to boot up... >>> >>> I check the code, and found that in the board_init_f, it calls the >>> init_sequence which is stored as a data sector >>> in the u-boot.bin file. While the new scheme use the fPIC, the code >>> could locate the GOT table correctly, >>> and it seem to forgot what the GOT table stores is context that is >>> meaningful in TEXT_BASE, not the loaded base. >>> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is >>> 0x500000, I found the GOT table also filled >>> with 0xf0****, not the 0x50****. This leads the cpu loading wrong >>> function address in the init_sequence table, and >>> cause pc become invalid... >>> >>> Am I missing something to switch to the new relocation scheme? >>> >>> Thanks, >>> Lei >> >> Can you indicate which hardware (architecture, cpu, SoC, etc) you're >> running this code on? >> > I am running the code on Marvell aspen soc, which is arm926ejs compatible core. For arm926, TEXT_BASE should be the FLASH location (if booting from NOR) or a location in DRAM (for NAND and other methods). 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. 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. > Best regards, > Lei Amicalement, -- Albert.