From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.aribaud@free.fr>
Date: Tue, 05 Oct 2010 10:50:09 +0200
Subject: [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
In-Reply-To: <4CAAE3FE.6060906@emk-elektronik.de>
References: <1286260287-1571-1-git-send-email-albert.aribaud@free.fr>
	<20101005064516.AEA4C153A7E@gemini.denx.de>
	<4CAACE47.5090105@emk-elektronik.de>
	<20101005082759.055471539A0@gemini.denx.de>
	<4CAAE3FE.6060906@emk-elektronik.de>
Message-ID: <4CAAE6C1.2070009@free.fr>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Le 05/10/2010 10:38, Reinhard Meyer a ?crit :
> Dear Wolfgang Denk,
>> Be careful!  Both my and Heikos patches go _on_top_ of Albert's patch!
>
> Just figured that out already:)
>
> But for arm926 I don't need your patch, and Heikos' was adding
> relocation fixup to env, which is not needed anymore, right?
>
> It crashes during relocation, I am adding debug right now:
>
> U-Boot 2010.09-00114-g4ab53c3-dirty (Oct 05 2010 - 11:46:07)
>
> U-Boot code: 21F00000 ->  21F3EBA0  BSS: ->  21F80100
> CPU: AT91SAM9XE
> Crystal frequency:   18.432 MHz
> CPU clock        :  198.656 MHz
> Master clock     :   99.328 MHz
> I2C:   ready
> monitor len: 00080100
> ramsize: 04000000
> Top of RAM usable for U-Boot at: 24000000
> Reserving 512k for U-Boot at: 23f7f000
> Reserving 143k for malloc() at: 23f5b100
> Reserving 24 Bytes for Board Info at: 23f5b0e8
> Reserving 136 Bytes for Global Data at: 23f5b060
> New Stack Pointer is: 23f5b058
> RAM Configuration:
> Bank #0: 20000000 64 MiB
> relocation Offset is: 0207f000
> calling relocate_code(addr_sp=23f5b058, id=23f5b060, addr=23f7f000)
>
> So far I cannot see any oddity in those numbers...
>
> Do all other system boot from NOR? Mine boots from RAM, thats means
> its loaded there by the initial boot into working SDRAM.
> With Heikos' relocation that works since I fixed the last problem
> yesterday. So its the change to Alberts' patch that breaks it.

I'll try and build a RAM-based version for my board. Meanwhile, make 
sure the IPL does not load u-boot in a location too near its final 
destination, as this could result in u-boot overwriting itself at some 
point -- I am not implying this is the case here; just don't tempt Fate.

> Best Regards
> Reinhard

Amicalement,
-- 
Albert.