[U-Boot] [PATCH v8 31/31] arm: Remove duplicated start.S code

[Benoît Thébaudeau]

Hi Albert,

On Friday, March 1, 2013 4:46:07 PM, Albert ARIBAUD wrote:
> Hi Benoît,
> 
> On Fri,  1 Mar 2013 13:10:40 +0100, Benoît Thébaudeau
> <benoit.thebaudeau at advansee.com> wrote:
> 
> > Factorize start.S code as much as possible.
> > 
> > Functions that may need to be customized for some start.S are defined weak
> > for
> > that purpose.
> > 
> > relocate_code_prepare() and relocate_code_finish() are introduced as hooks
> > to be
> > executed at the beginning and at the end of relocate_code() if needed by
> > some
> > start.S, e.g. for special cache or MMU operations.
> 
> NAK.
> 
> 1. I don't like this idea of planting hooks inside relocate-code().
> This function is about relocating code, not about MMU stuff. If there
> are any MMU steps to be performed between calls to board_init_f(),
> relocate_code() or board_init_r(), I want them laid out as calls of
> their own right in crt0.S.

I also don't like it. The finish hook was used by SMDK6400 before it was
removed, and the prepare hook is still used by pxa.

So is it OK for you if I just drop relocate_code_finish() and move and
rename the call to relocate_code_prepare() to crt0.S?

> 2. If we're going to factorize out relocate_code() from the various
> start.S files, I want it moved not in crt0.S but in its own file.

It is not in crt0.S, but in arch/arm/include/asm/start_marco.S, which is
almost its own file apart from another macro.

> This
> way, i) people can easily create binaries which use crt0.S but do not
> relocate, ii) people who want to make relocate_code() a C function
> will have it easier, and iii) crt0.S keeps being the ugly ASM glue
> needed for flash inits, relocation and RAM inits to have a C proper
> run-time environment.

Which is already the case with this implementation?

> Incidentally, CC:ing Simon:
> 
> > Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau at advansee.com>
> > ---
> > Changes in v8:
> >  - New patch.
> > 
> > Changes in v7: None
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> 
> Is this produced by patman?

Yes.

> If so, is there a way to avoid it?

Not that I know of.

> We
> *know* it's a new patch in v8, so any history pre-v8 here is
> meaningless.

Sure.

Best regards,
Benoît