[U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine

Albert ARIBAUD
2013-05-14T18:51:58Z

Hi Beno?t,

On Tue, 14 May 2013 19:17:46 +0200 (CEST), Beno?t Th?baudeau
<benoit.thebaudeau@advansee.com> wrote:

> Hi Albert,
>
> On Tuesday, May 14, 2013 6:32:08 PM, Albert ARIBAUD wrote:
> > Hi Beno?t,
> >
> > On Tue, 14 May 2013 18:01:50 +0200 (CEST), Beno?t Th?baudeau
> > <benoit.thebaudeau@advansee.com> wrote:
> >
> > > Hi Albert,
> >
> > > > .globl c_runtime_cpu_setup
> > > > c_runtime_cpu_setup:
> > > >
> > > > - bx lr
> > > > + /*
> > > > + * Unlock (actually, disable) the cache now that board_init_f
> > > > + * is done. We could do this earlier but we would need to add
> > > > + * a new C runtime hook, whereas c_runtime_cpu_setup already
> > > > + * exists.
> > > > + * As this routine is just a call to cpu_init_crit, let us
> > > > + * tail-optimize and do a simple branch here.
> > > > + */
> > > > + b cpu_init_crit
> > >
> > > Shouldn't the "#ifdef CONFIG_CPU_PXA25X" from the original code be kept
> > > here?
> >
> > Yes, it should indeed. Thanks for spotting this!
>
> Have you seen the end of my notes for relocate.S? After all, keeping for later
> your patches moving to compiler-generated symbols seems to complicate things and
> to be more error-prone.

(that's unrelated to the PXA25X stuff above, right?)

I don't think deferring the compiler-generated symbols patches
complicates things, as anyway, they would only apply after this
patch (so as to apply only on a single instance of relocate_code) so
there's no way they could simplify things occurring before them.

OTOH, they do simplify the code of relocate_code. That's why I put them
in a separate series dealing with optimizing relocate_code. I'll post
this second series right away, and let people decide whether both
series should be merged in a single one.

> Best regards,
> Beno?t

Amicalement,
--
Albert.