From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 05 Oct 2010 11:00:57 +0200 Subject: [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations In-Reply-To: <4CAAE4BF.3030306@free.fr> References: <1286260287-1571-1-git-send-email-albert.aribaud@free.fr> <20101005064516.AEA4C153A7E@gemini.denx.de> <4CAACE47.5090105@emk-elektronik.de> <4CAAD255.1080501@emk-elektronik.de> <4CAAD944.2040309@emk-elektronik.de> <4CAAE2C5.4040304@denx.de> <4CAAE4BF.3030306@free.fr> Message-ID: <4CAAE949.1010200@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Albert, Albert ARIBAUD wrote: > Le 05/10/2010 10:33, Heiko Schocher a ?crit : >> Hello Reinhard, >> >> Reinhard Meyer wrote: >>> I _think_ the linker file needs a .align there: >>> >>> (.data ends with a non-aligned address!) >> >> actually trying on the tx25 board, and I see a hang after >> the dram output too: >> >> DRAM: 32 MiB >> >> I inserted a breakpoint in start.S at clear_bss, never reached... >> >> Maybe the fixloop >> >> start.S: >> [...] >> fixnext: >> str r1, [r0] >> add r2, r2, #8 /* each rel.dyn entry is 8 bytes */ >> cmp r2, r3 >> ble fixloop >> #endif >> #endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */ >> >> clear_bss: >> >> never reaches a end ... but just debugging it ... >> >> register dump in fixloop: >> >> TX25>ti;r >> Core number : 0 >> Core state : debug mode (ARM) >> Debug entry cause : Single Step >> Current PC : 0x812000d8 >> Current CPSR : 0x800000d3 (Supervisor) >> GPR00: 81fbe020 81fbe1a0 81224364 812285cc >> GPR04: 81ebdf88 81ebdf8c 81fe6ac8 81fbe000 >> GPR08: 00000017 00dbe000 812285cc 00000000 >> GPR12: 00000000 81ebdf88 812006f4 812000d8 >> PC : 812000d8 CPSR: 800000d3 >> TX25> >> >> r2 and r3 are a multiple of 8, so this must end, but never >> see it ending ... > > Ihe loop exit test is a ble, not a bne, so even if r2 or r3 were not > properly aligned, this should still exit eventually. But in my case this looks good. > A reason why it would not, though, is if the loop trashes the code in > RAM. That can happen if e.g. TEXT_BASE is wrong (my bad). In two hour's > time I will build (not test) for tx25 and then do a quick check on the > content of .rel.dyn and .dynsym in the resulting u-boot. TX25>ti;r Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x812000e4 Current CPSR : 0x200000d3 (Supervisor) GPR00: 81fbe020 00000017 8122435c 812285cc GPR04: 81ebdf88 81ebdf8c 81fe6ac8 81fbe000 GPR08: 80000f80 00dbe000 812285cc 00000000 GPR12: 00000000 81ebdf88 812006f4 812000e4 PC : 812000e4 CPSR: 200000d3 Looking at the last entry @812285cc. TX25>md 0x812285cc 812285cc : 00000000 00000000 00000000 00000000 ................ 812285dc : 00000000 81200000 00000000 00010003 ...... ......... 812285ec : 0000004f 8122435c 00000000 fff10010 O...\C"......... 812285fc : 00000092 812286bc 00000000 fff10010 ......"......... 8122860c : 00000028 812242d0 00000000 00060010 (....B"......... now looking what did fixloop with this: fixloop: ldr r0, [r2] /* r0 <- location to fix up, IN FLASH! */ add r0, r9 /* r0 <- location to fix up in RAM */ so after this r0 would be 0x00dbe000 so, later in code: fixrel: /* relative fix: increase location by offset */ ldr r1, [r0] add r1, r1, r9 fixnext: str r1, [r0] this stores @00dbe000 will fail ... no idea why I have here @812285cc just 00000000 Hah... with this patch it works: diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 5a7ae7e..cf3a59f 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -266,7 +266,7 @@ fixnext: str r1, [r0] add r2, r2, #8 /* each rel.dyn entry is 8 bytes */ cmp r2, r3 - ble fixloop + bne fixloop #endif #endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */ @@ -297,8 +297,9 @@ clbss_l:str r2, [r0] /* clear loop... */ ldr r0, _nand_boot_ofs adr r1, _start add pc, r0, r1 -_nand_boot_ofs - : .word nand_boot - _start + +_nand_boot_ofs: + .word nand_boot - _start #else ldr r0, _board_init_r_ofs adr r1, _start Ok, we could not ignore the last entry ... Hmm.. any idea why I have such a buggy last entry in __rel_dyn_start ? (I have to admit, that I didn;t tried to start from nand with nand_spl code, I just load u-boot with the bdi in ram (such as the nand_spl code this did ... now I have to try to boot from nand) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany