From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Mon, 17 Sep 2012 12:23:53 -0500
Subject: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
In-Reply-To: <20120917171831.GB16252@bill-the-cat> (from trini@ti.com on Mon
	Sep 17 12:18:31 2012)
References: <1347643742-19966-1-git-send-email-jose.goncalves@inov.pt>
	<201209161206.58874.marex@denx.de> <5055A71B.9090405@inov.pt>
	<201209161736.47963.marex@denx.de>
	<20120917171831.GB16252@bill-the-cat>
Message-ID: <1347902633.19543.11@snotra>
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

On 09/17/2012 12:18:31 PM, Tom Rini wrote:
> On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> > > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > > Dear Jos? Miguel Gon?alves,
> > > >
> > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > > >>> Dear Jos? Miguel Gon?alves,
> > > >>>
> > > >>>> Jumping to board_init_r is not performed due to a bug on  
> address
> > > >>>> computation.
> > > >>>
> > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't  
> detect any
> > > >>> misbehavior on my arm926 boards.
> > > >>
> > > >> Maybe because you are not using it to build an SPL?
> > > >
> > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> > >
> > > >> Please check the same chunk of code in other start.S for  
> arm1176 and
> > > >> armv7. They have the same code that I put for arm926ejs.
> > > >
> > > > Please wait and please first explain what is the issue.
> > >
> > > The issue is what I've explained in the patch comments.
> >
> > "Jumping to board_init_r is not performed due to a bug on address  
> computation."
> >
> > Ok, I don't know how to replicate the bug from this comment or what  
> effects it
> > causes or ... well, anything. So please, try to be more elaborate  
> in your patch
> > description next time. Anyway ..
> >
> > > Without this
> > > change the code never reaches board_init_r in the SPL and I think  
> I have
> > > all the configurations correctly set.
> >
> > I wonder why you'd ever want to reach board_init_r in the SPL. SPL  
> is there only
> > to load the real U-Boot from whatever media, so you usually use  
> either NAND SPL
> 
> Here's a good point for me to jump in, I think.  There's two things to
> understand:
> - In the current in-tree SPL implementations the code flow is
>   board_init_f calls relocate_code() to clear the BSS _and_ get our  
> jump
>   to board_init_r.  It does not actually relocate the running U-Boot,
>   just clears the BSS.  board_init_r is what calls the things to load
>   and boot the next stage (U-Boot or Linux).
> 
> - In my series this has been changed slightly to be board_init_f calls
>   memset and then board_init_r directly.  So this patch should not be
>   needed once rebased on that series.

So you've removed the ability to relocate at all?  What about hardware  
where you boot from an I/O buffer, that you need to get out of in order  
to load more pages?

-Scott