From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 01 Nov 2010 20:53:09 +0100 Subject: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot In-Reply-To: References: <20101031203243.478E9EA47F@gemini.denx.de> <1288547025-16877-1-git-send-email-albert.aribaud@free.fr> <20101031181244.419EDEA47F@gemini.denx.de> <4CCDB78D.506@ahsoftware.de> <20101031190136.64829EA47F@gemini.denx.de> <4CCDBE71.1010805@free.fr> <20101031192243.7AF531522C0@gemini.denx.de> <4CCDC625.3010209@free.fr> <20101031195941.5AB961522C0@gemini.denx.de> <4CCDD02D.2050304@free.fr> <1288560046-6458-1-git-send-email-albert.aribaud@free.fr> <4CCDED8D.0@ahsoftware.de> <4CCDF5FC.4060704@free.fr> <20101101091515.C8BDD1522C0@gemini.denx.de> <4CCEF2E4.5080003@free.fr> <20101101192318.06C231522C0@gemini.denx.de> <4CCF1558.1040108@free.fr> Message-ID: <4CCF1AA5.809@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 01/11/2010 20:44, Graeme Russ a ?crit : > On Tuesday, November 2, 2010, Albert ARIBAUD wrote: >> Le 01/11/2010 20:23, Wolfgang Denk a ?crit : >>> Dear Albert ARIBAUD, >>> >>> In message<4CCEF2E4.5080003@free.fr> you wrote: >>>> >>>> Also, I understand why the second RFC change I did was harmful to tx25. >>>> Contrary to u-boot itself, u-boot-spl is not compiled to be position >>>> independent; it actually loads at a given address then copies itself, >>>> without relocating, to its home location. >>> >>> It copies _itself_? Not the U-Boot payload? >>> >>> Heiko, is this intentional? Do we really first load the whole image, >>> then copy the U-Boot payload to some other address, then relocate it >>> to yet another one? >> >> I haven't been clear. >> >> The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and >> jumps to it. >> >> u-boot-spl copies itself at its intended location if not already there, >> and jumps to tiself at that new location. >> >> u-boot-spl loads u-boot at a fixed location and jumps to it. >> >> u-boot relocates (copies and fixes up) itself at top of ram if not >> already there, and jumps to itself at that new location. >> > > Wow, what a terrible waste! > > Why does u-boot-spl need to relocate? As I said, u-boot-spl does not relocate, it only copies itself to its link-time location and jumps there, and it does this only if loaded somewhere else to boot (if I may say so). *Usually* it will be loaded at the right place and thus won't copy itself and jump to itself. It still takes up some space, though. The copy and jump could actually be #ifdef's on CONFIG_NAND_SPL if everyone thinks it is safe -- please comment quickly as I'm preparing a patch set and that could go in it if agreed to. > Can't u-boot-spl load AND relocate u-boot, or does u-boot-spl have > tight space constraints? It has; it comes from a (usually small) NAND page. > Regards > > Graeme Amicalement, -- Albert.