From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 02 Nov 2010 12:16:55 +0100 Subject: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot In-Reply-To: <20101102095645.GB7960@Hardy> References: <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> <4CCFAFE4.3000600@denx.de> <4CCFD27E.3080500@emk-elektronik.de> <20101102093845.591FF4C7@gemini.denx.de> <4CCFDE45.3060306@free.fr> <20101102095645.GB7960@Hardy> Message-ID: <4CCFF327.3070601@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 02/11/2010 10:56, Sughosh Ganu a ?crit : > hi Albert, > > On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote: > >> Now a solution would be that the actual u-boot size be flashed along >> with it, for instance as a literal defined as '.word _end - _start' >> right after the vectors. The SPL could load a first NAND block, read the >> literal, round it to a multiple of NAND blocks by default, and then read >> this quantity. >> >> That would remove the dependency at the cost of extra code in the SPL, >> though, and not all boards might be able to afford it. > > Another issue is that the nand_spl might be compiled and flashed > to the NAND as a separate entity, using a separate flashing > mechanism. If we use the dynamic calculation of the u-boot size, > this would necessitate building and flashing the nand_spl each time > along with u-boot. Not with the solution I describe, as the once-flashed SPL would fetch the actual size from the actual u-boot. > -sughosh Amicalement, -- Albert.