From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 06 Jan 2010 15:02:53 -0600 Subject: [U-Boot] [PATCH 2/4] Use LINK_OFF to access global data In-Reply-To: References: <1262185712-11890-1-git-send-email-Joakim.Tjernlund@transmode.se> <1262185712-11890-2-git-send-email-Joakim.Tjernlund@transmode.se> <1262185712-11890-3-git-send-email-Joakim.Tjernlund@transmode.se> <20100102181329.8840FE34A25@gemini.denx.de> <20100103195153.558C4EF5FF5@gemini.denx.de> <4B40F8DB.1090509@free.fr> <20100105202032.GB26296@loki.buserror.net> Message-ID: <4B44FA7D.300@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Joakim Tjernlund wrote: > > u-boot-bounces at lists.denx.de wrote on 05/01/2010 21:20:32: > >> From: Scott Wood >> To: Albert ARIBAUD >> Cc: u-boot at lists.denx.de >> Date: 05/01/2010 21:22 >> Subject: Re: [U-Boot] [PATCH 2/4] Use LINK_OFF to access global data >> Sent by: u-boot-bounces at lists.denx.de >> >> On Sun, Jan 03, 2010 at 09:06:51PM +0100, Albert ARIBAUD wrote: >>> Hmm... PIC is interesting only if you want the same binary to run from >>> two places, like NOR then RAM, which is the case when U-boot is the code >>> which gets run in NOR at power-up and ends up running in RAM later. >>> >>> For NAND-based boards, the NAND bootloader will load U-boot to RAM, and >>> U-boot will never run from anywhere else but its intended RAM location. >> Note that the first-stage NAND loader still needs to be able to relocate >> itself to RAM in order to free up the NAND buffer for loading more data. > > Hmm, does that mean that the LINK_OFF patches are useful to you or not? I was just responding to a suggestion that a split similar to the NAND loader might eliminate the need for relocation/PIC support. I am a bit nervous about this stuff, though -- why is it needed? We just got rid of the need for manual relocations, and now we're adding them back (pre-reloc instead of post-reloc). :-( -Scott