From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sughosh Ganu <urwithsughosh@gmail.com>
Date: Tue, 2 Nov 2010 15:26:45 +0530
Subject: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
In-Reply-To: <4CCFDE45.3060306@free.fr>
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>
Message-ID: <20101102095645.GB7960@Hardy>
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

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.

-sughosh