From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sughosh Ganu Date: Tue, 2 Nov 2010 17:02:55 +0530 Subject: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot In-Reply-To: <4CCFF327.3070601@free.fr> References: <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> <4CCFF327.3070601@free.fr> Message-ID: <20101102113255.GA9123@Hardy> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue Nov 02, 2010 at 12:16:55PM +0100, Albert ARIBAUD wrote: > 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. Yes that is correct. I was referring to the other solution of fixing the size through the script. -sughosh