From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Wed, 28 Nov 2012 23:34:34 +0100
Subject: [U-Boot] [PATCH v4 1/2] arm: move C runtime setup code in crt0.S
In-Reply-To: <CAPnjgZ3rMyq02q8KfWFrjv_9ZM2HoiUrf=Sd3oZ6AJ3FzuddKQ@mail.gmail.com>
References: <1352566813-30386-1-git-send-email-albert.u.boot@aribaud.net>
	<1354020206-24762-1-git-send-email-albert.u.boot@aribaud.net>
	<1354020206-24762-2-git-send-email-albert.u.boot@aribaud.net>
	<CAPnjgZ3rMyq02q8KfWFrjv_9ZM2HoiUrf=Sd3oZ6AJ3FzuddKQ@mail.gmail.com>
Message-ID: <20121128233434.48725479@lilith>
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 Simon,

On Wed, 28 Nov 2012 13:18:57 -0800, Simon Glass <sjg@chromium.org>
wrote:

> Hi Albert,
> 
> On Tue, Nov 27, 2012 at 4:43 AM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
> > Move all the C runtime setup code from every start.S
> > in arch/arm into arch/arm/lib/crt0.S. This covers
> > the code sequence from setting up the initial stack
> > to calling into board_init_r().
> >
> > Also, rewrite the C runtime setup and make functions
> > board_init_*() and relocate_code() behave according to
> > normal C semantics (no jumping across the C stack any
> > more, etc).
> >
> > Some SPL targets had to be touched because they use
> > start.S explicitly or for some reason; the relevant
> > maintainers and custodians are cc:ed.
> >
> > Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
> 
> I tested this on Seaboard (Tegra 20).
> 
> Tested-by: Simon Glass <sjg@chromium.org>
> 
> I tried to test it on a snow (exynos5250) but couldn't really sync up
> with our tree, so gave up. I am not completely sure about how the
> CONFIG_SPL_BUILD stuff fits together in start.S and I got a build
> error I wasn't sure how to correct (arch/arm/cpu/armv7/start.S:179:
> undefined reference to `relocate_done')

Thansk Simon.

In file arch/arm/cpu/armv7/start.S, line 179 uses relocate_done and
line 228 provides it, and there is no preprocessor conditional
in-between, so I fail to see how you could get this error.

Is your tree (and branch) available so that I can try and see the issue
for myself? Either it'll uncover a problem in my patch series, or it'll
help you merge it (or both).

> Regards,
> Simon

Amicalement,
-- 
Albert.