From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ulf Samuelsson <ulf@atmel.com>
Date: Fri, 7 Mar 2008 01:03:43 +0100
Subject: [U-Boot-Users] arm920t RAM relocation broken?
References: <47D05C81.50200@videon-central.com>
Message-ID: <059001c87fee$fe1a7570$030514ac@atmel.com>
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

----- Original Message ----- 
From: "Cory T. Tusar" <ctusar@videon-central.com>
To: <u-boot-users@lists.sourceforge.net>
Cc: <peter.pearse@arm.com>
Sent: Thursday, March 06, 2008 10:05 PM
Subject: [U-Boot-Users] arm920t RAM relocation broken?


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Commit d4fc6012 added an #ifdef CONFIG_AT91RM9200 construct around the
> RAM relocation bits in cpu/arm920t/start.S.  More directly, it added an
> entire secondary relocation snippet surrounded by an 
> #ifdef CONFIG_BOOTBINFUNC construct.
> 
> It appears that this second implementation was later removed in commit
> 80767a6c, but the #ifdef CONFIG_AT91RM9200 logic was not removed also.
> 
> Is RAM relocation only intended to function on at91rm9200 boards, or
> shall I submit a patch fixing the above?
> 
> - -Cory
> 


Does this mean that the AT91RM9200 always relocates?
Then the code is simply wrong.

If you run from a serial flash, then the code is already relocated
and is executing from SDRAM at this point, so the code will crash.


Best Regards
Ulf Samuelsson