reboard: Introduce generic relocation feature

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

Quoted 2 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? ?we can do that
easily: add it to include/config_defaults.h. ?then boards that opt into it will #undef it in their own configs.

-mike

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? we can do that easily: add it to include/config_defaults.h. then boards that opt into it will #undef it in their own configs.

Thanks for looking at this.

I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied.

My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach.

Quoted 18 lines · On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? ?we can do that easily: add it to include/config_defaults.h. ?then boards that opt into it will #undef it in their own configs.

Thanks for looking at this.

I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied.

Quoted 2 lines

My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach.

how about we have the reloc code live in lib/reloc/ and be controlled by CONFIG_LEGACY_ARCH_RELOC ?
-mike

Quoted 22 lines · Mike Frysinger

Quoted 20 lines · On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? we can do that easily: add it to include/config_defaults.h. then boards that opt into it will #undef it in their own configs.

Thanks for looking at this.

I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied.

My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach.

Quoted 2 lines

how about we have the reloc code live in lib/reloc/ and be controlled by CONFIG_LEGACY_ARCH_RELOC ?

My only concern is that if something like SPL needs to keep all the early code at the start of the image. I personally don't like the current method for doing that (would prefer a distinctive .text.early section name) and I don't believe that any SPL implementation actually relocates itself.

Quoted 26 lines · On Tuesday 29 November 2011 17:09:19 Simon Glass wrote:

Quoted 24 lines · Mike Frysinger

Quoted 18 lines · On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? ?we can do that easily: add it to include/config_defaults.h. ?then boards that opt into it will #undef it in their own configs.

Thanks for looking at this.

I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied.

Quoted 2 lines

My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach.

how about we have the reloc code live in lib/reloc/ and be controlled by CONFIG_LEGACY_ARCH_RELOC ?

Quoted 5 lines

My only concern is that if something like SPL needs to keep all the early code at the start of the image. I personally don't like the current method for doing that (would prefer a distinctive .text.early section name) and I don't believe that any SPL implementation actually relocates itself.

not sure why this matters ?
-mike

Hi Mike,

Quoted 33 lines · Mike Frysinger

Quoted 31 lines · On Tuesday 29 November 2011 17:09:19 Simon Glass wrote:

Quoted 19 lines · Mike Frysinger

Quoted 18 lines · On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? we can do that easily: add it to include/config_defaults.h. then boards that opt into it will #undef it in their own configs.

Thanks for looking at this.

I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied.

Quoted 5 lines

Quoted 2 lines

My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach.

how about we have the reloc code live in lib/reloc/ and be controlled by CONFIG_LEGACY_ARCH_RELOC ?

My only concern is that if something like SPL needs to keep all the early code at the start of the image. I personally don't like the current method for doing that (would prefer a distinctive .text.early section name) and I don't believe that any SPL implementation actually relocates itself.

Quoted 3 lines

not sure why this matters ?
-mike

Because if they require linking with reloc.o then we will get link failures some boards. There is some ugly stuff in SPL which pulls in particular files from around U-Boot. Any time I split something out of start.S I may break something.

Regards,
Simon

Le 30/11/2011 00:40, Simon Glass a ?crit :

Quoted 49 lines

Hi Mike,

Quoted 46 lines · On Tue, Nov 29, 2011 at 3:19 PM, Mike Frysinger<[email protected]> ?wrote:

Quoted 42 lines · On Tuesday 29 November 2011 17:09:19 Simon Glass wrote:

Quoted 26 lines · Mike Frysinger

Quoted 24 lines · On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:

Quoted 11 lines · Mike Frysinger

Quoted 3 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? ?we can
do that easily: add it to include/config_defaults.h. ?then boards that opt into it will #undef it in their own configs.

Thanks for looking at this.

I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied.

Quoted 7 lines

Quoted 2 lines

My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach.

how about we have the reloc code live in lib/reloc/ and be controlled by
CONFIG_LEGACY_ARCH_RELOC ?

My only concern is that if something like SPL needs to keep all the early code at the start of the image. I personally don't like the current method for doing that (would prefer a distinctive .text.early section name) and I don't believe that any SPL implementation actually relocates itself.

Quoted 8 lines

Quoted 3 lines

not sure why this matters ?
-mike

Because if they require linking with reloc.o then we will get link failures some boards. There is some ugly stuff in SPL which pulls in particular files from around U-Boot. Any time I split something out of start.S I may break something.

IIRC, SPL never relocates itself -- the goal of SPL is to get some code in memory that will just enable RAM, move the rest of U-Boot in, and jump to it.

What SPL pulls in is drivers/ functions for console output and access to the RAM and main U-Boot image.

Besides, sometimes making boards all fail until they are fixed is a good way to manage a change. :)

Quoted 3 lines

Regards,
Simon

Amicalement,
--
Albert.

+omap, samsung, imx maintainers

Hi Mike,

Quoted 19 lines · Mike Frysinger

Quoted 18 lines · On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:54 Simon Glass wrote:

We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first.

the define says "BOARD", so shouldn't it be in board configs ? we can do that easily: add it to include/config_defaults.h. then boards that opt into it will #undef it in their own configs.

Thanks for looking at this.

I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied.

Quoted 7 lines

Quoted 2 lines

My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach.

how about we have the reloc code live in lib/reloc/ and be controlled by CONFIG_LEGACY_ARCH_RELOC ?
-mike

Yes I can do that.

My only concern is that if something like SPL needs to keep all the early code at the start of the image. I personally don't like the current method for doing that (would prefer a distinctive .text.early section name) and I don't believe that any SPL implementation actually relocates itself.

 include/asm-generic/link_symbols.h |   38

Quoted 1 line · On Monday 21 November 2011 18:57:55 Simon Glass wrote:

?include/asm-generic/link_symbols.h | ? 38

this should be asm-generic/sections.h. ?might actually want to import the Linux one and then add a section for u-boot specific symbols. -mike

 board/Makefile   |   45
 board/reloc.c    |  101

Quoted 2 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

?board/Makefile ? | ? 45
?board/reloc.c ? ?| ?101

not to bikeshed, but i don't think we want files in board/. ?how about board/common/ or board/generic/ instead ?

board/Makefile line 30

Quoted 7 lines

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS ? ? ? ?+= reloc.o
+endif

i don't think relocation should be tied "legacy board". ?not all arches do relocation at all, which means they might never opt in to this aspect.

include/common.h int dcache_status (void); · line 472

Quoted 6 lines

include/common.h +1 -1

 
-void relocate_code (ulong, gd_t *, ulong) __attribute__ ((noreturn));
+#include <reloc.h>

i'd think very few funcs would need this. ?so maybe we should make the few places include reloc.h explicitly.
-mike

Hi Mike,

Quoted 1 line · Mike Frysinger

On Monday 21 November 2011 18:57:56 Simon Glass wrote:

Quoted 5 lines

Quoted 2 lines

 board/Makefile   |   45
 board/reloc.c    |  101

not to bikeshed, but i don't think we want files in board/. how about board/common/ or board/generic/ instead ?

Yes I wasn't sure, let's go with lib/reloc.c unless we hit SPL problems (do we really need lib/reloc/reloc.c?)

Quoted 11 lines · Mike Frysinger

board/Makefile line 30

Quoted 6 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS        += reloc.o
+endif

i don't think relocation should be tied "legacy board". not all arches do relocation at all, which means they might never opt in to this aspect.

If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this.

Quoted 13 lines · On Tuesday 29 November 2011 17:15:18 Simon Glass wrote:

Quoted 11 lines · Mike Frysinger

board/Makefile line 30

Quoted 6 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS ? ? ? ?+= reloc.o
+endif

i don't think relocation should be tied "legacy board". ?not all arches do relocation at all, which means they might never opt in to this aspect.

Quoted 3 lines

If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this.

Blackfin does no relocation, so i'd be annoyed to have to carry a define like "LEGACY_BOARD" forever ;)
-mike

Hi Mike,

Quoted 18 lines · Mike Frysinger

Quoted 16 lines · On Tuesday 29 November 2011 17:15:18 Simon Glass wrote:

Quoted 11 lines · Mike Frysinger

board/Makefile line 30

Quoted 6 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS ? ? ? ?+= reloc.o
+endif

i don't think relocation should be tied "legacy board". ?not all arches do relocation at all, which means they might never opt in to this aspect.

If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this.

Quoted 4 lines

Blackfin does no relocation, so i'd be annoyed to have to carry a define like "LEGACY_BOARD" forever ;)
-mike

Would you be happier with CONFIG_ARCH_NO_RELOCATION?

Quoted 19 lines · Simon Glass

Quoted 18 lines · Mike Frysinger

Quoted 16 lines · On Tuesday 29 November 2011 17:15:18 Simon Glass wrote:

Quoted 11 lines · Mike Frysinger

board/Makefile line 30

Quoted 6 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS        += reloc.o
+endif

i don't think relocation should be tied "legacy board". not all arches do relocation at all, which means they might never opt in to this aspect.

If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this.

Quoted 4 lines

Quoted 2 lines

Blackfin does no relocation, so i'd be annoyed to have to carry a define like "LEGACY_BOARD" forever ;)

Would you be happier with CONFIG_ARCH_NO_RELOCATION?

CONFIG_SYS_NO_RELOC

Quoted 23 lines · Simon Glass

Quoted 22 lines · Mike Frysinger

Quoted 20 lines · On Tuesday 29 November 2011 17:15:18 Simon Glass wrote:

Quoted 13 lines · Mike Frysinger

Quoted 11 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

board/Makefile

Quoted 6 lines

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS        += reloc.o
+endif

i don't think relocation should be tied "legacy board". not all arches do relocation at all, which means they might never opt in to this aspect.

Quoted 3 lines

If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this.

Blackfin does no relocation, so i'd be annoyed to have to carry a define like "LEGACY_BOARD" forever ;)

Quoted 3 lines

Quoted 1 line

Would you be happier with CONFIG_ARCH_NO_RELOCATION?

CONFIG_SYS_NO_RELOC

either is fine by me
-mike

Le 30/11/2011 03:58, Mike Frysinger a ?crit :

Quoted 26 lines · On Tuesday 29 November 2011 18:49:58 Graeme Russ wrote:

Quoted 25 lines · Simon Glass

Quoted 23 lines · Mike Frysinger

Quoted 14 lines · On Tuesday 29 November 2011 17:15:18 Simon Glass wrote:

Quoted 13 lines · Mike Frysinger

Quoted 11 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

board/Makefile

Quoted 6 lines

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS        += reloc.o
+endif

i don't think relocation should be tied "legacy board". not all arches do relocation at all, which means they might never opt in to this aspect.

Quoted 6 lines

Quoted 3 lines

If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this.

Blackfin does no relocation, so i'd be annoyed to have to carry a define like "LEGACY_BOARD" forever ;)

Would you be happier with CONFIG_ARCH_NO_RELOCATION?

Quoted 3 lines

Quoted 1 line

CONFIG_SYS_NO_RELOC

either is fine by me

CONFIG_SYS_SKIP_RELOC clearly states there is some usual step we're skipping, plus we could homogeneize with other config settings that "SKIP" some step.

Quoted 29 lines · On Wednesday 07 December 2011 02:38:40 Albert ARIBAUD wrote:

Le 30/11/2011 03:58, Mike Frysinger a ?crit :

Quoted 28 lines · On Tuesday 29 November 2011 18:49:58 Graeme Russ wrote:

Quoted 26 lines · Simon Glass

Quoted 15 lines · Mike Frysinger

Quoted 14 lines · On Tuesday 29 November 2011 17:15:18 Simon Glass wrote:

Quoted 13 lines · Mike Frysinger

Quoted 11 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

board/Makefile

Quoted 6 lines

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS ? ? ? ?+= reloc.o
+endif

i don't think relocation should be tied "legacy board". ?not all arches do relocation at all, which means they might never opt in to this aspect.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

If they don't do reloc then when we move them over we should add a CONFIG for this I think. But would prefer to wait until we have an arch moving over that requires no relocation, before addressing this.

Blackfin does no relocation, so i'd be annoyed to have to carry a define like "LEGACY_BOARD" forever ;)

Would you be happier with CONFIG_ARCH_NO_RELOCATION?

CONFIG_SYS_NO_RELOC

Quoted 5 lines

Quoted 1 line

either is fine by me

CONFIG_SYS_SKIP_RELOC clearly states there is some usual step we're skipping, plus we could homogeneize with other config settings that "SKIP" some step.

fine by me as well
-mike

Quoted 2 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

?board/Makefile ? | ? 45
?board/reloc.c ? ?| ?101

not to bikeshed, but i don't think we want files in board/. ?how about board/common/ or board/generic/ instead ?

board/Makefile line 30

Quoted 6 lines

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS ? ? ? ?+= reloc.o
+endif

i don't think relocation should be tied "legacy board". ?not all arches do relocation at all, which means they might never opt in to this aspect.

Quoted 3 lines

include/common.h +0 -0

include/common.h int dcache_status (void); · line 472

Quoted 2 lines

include/common.h +1 -1

-void relocate_code (ulong, gd_t *, ulong) __attribute__ ((noreturn));
+#include <reloc.h>

i'd think very few funcs would need this. ?so maybe we should make the few places include reloc.h explicitly.
-mike

Hi Mike,

Quoted 20 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

?board/Makefile ? | ? 45
?board/reloc.c ? ?| ?101

not to bikeshed, but i don't think we want files in board/. ?how about board/common/ or board/generic/ instead ?

board/Makefile line 30

Quoted 6 lines

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS ? ? ? ?+= reloc.o
+endif

i don't think relocation should be tied "legacy board". ?not all arches do relocation at all, which means they might never opt in to this aspect.

Quoted 3 lines

include/common.h +0 -0

Quoted 6 lines

include/common.h int dcache_status (void); · line 472

Quoted 2 lines

include/common.h +1 -1

-void relocate_code (ulong, gd_t *, ulong) __attribute__ ((noreturn));
+#include <reloc.h>

i'd think very few funcs would need this. ?so maybe we should make the few places include reloc.h explicitly.
-mike

I found that 27 files call relocate_code(). Now we can discuss whether the number should be that high, but for now I would prefer to move this out of common.h in a later patch. What do you think?

Hi Simon,

Quoted 30 lines · Simon Glass

Hi Mike,

Quoted 20 lines · Mike Frysinger

Quoted 2 lines · On Monday 21 November 2011 18:57:56 Simon Glass wrote:

?board/Makefile ? | ? 45
?board/reloc.c ? ?| ?101

not to bikeshed, but i don't think we want files in board/. ?how about board/common/ or board/generic/ instead ?

board/Makefile line 30

Quoted 6 lines

board/Makefile new file +3 -0

 
+ifndef CONFIG_SYS_LEGACY_BOARD
+COBJS ? ? ? ?+= reloc.o
+endif

i don't think relocation should be tied "legacy board". ?not all arches do relocation at all, which means they might never opt in to this aspect.

Quoted 3 lines

include/common.h +0 -0

Quoted 6 lines

include/common.h int dcache_status (void); · line 472

Quoted 2 lines

include/common.h +1 -1

-void relocate_code (ulong, gd_t *, ulong) __attribute__ ((noreturn));
+#include <reloc.h>

i'd think very few funcs would need this. ?so maybe we should make the few places include reloc.h explicitly.
-mike

Quoted 3 lines

I found that 27 files call relocate_code(). Now we can discuss whether the number should be that high, but for now I would prefer to move this out of common.h in a later patch. What do you think?

27 out of how many source code files? Thousands?

Quite honestly, include/common.h has become a bit of a dumping ground for one-off function definitions that should have been put in a stand-alone header.

common.h is included nearly everywhere - is all this really needed everywhere:

/* Multicore arch functions */
#ifdef CONFIG_MP
int cpu_status(int nr);
int cpu_reset(int nr);
int cpu_disable(int nr);
int cpu_release(int nr, int argc, char * const argv[]); #endif

...

int ? ? dpram_init (void);
uint ? ?dpram_base(void);
uint ? ?dpram_base_align(uint align);
uint ? ?dpram_alloc(uint size);
uint ? ?dpram_alloc_align(uint size,uint align);

...

#if defined(CONFIG_8260)
int ? ? prt_8260_rsr ?(void);
#elif defined(CONFIG_MPC83xx)
int ? ? prt_83xx_rsr ?(void);
#endif

...

/* $(CPU)/cpu_init.c */
#if defined(CONFIG_8xx) || defined(CONFIG_8260)
void ? ?cpu_init_f ? ?(volatile immap_t *immr);
#endif

#if defined(CONFIG_4xx) || defined(CONFIG_MPC85xx) ||
defined(CONFIG_MCF52x2) ||defined(CONFIG_MPC86xx)

void ? ?cpu_init_f ? ?(void);
#endif

...

#if defined(CONFIG_IMX)
ulong get_systemPLLCLK(void);
ulong get_FCLK(void);
ulong get_HCLK(void);
ulong get_BCLK(void);
ulong get_PERCLK1(void);
ulong get_PERCLK2(void);
ulong get_PERCLK3(void);
#endif

The list goes on - please, lets stop the rot

Regards,

Graeme

+.globl proc_call_board_init_r
+proc_call_board_init_r:

Add a library to hold ARM assembler code which is generic across all ARM CPUs.

Signed-off-by Simon Glass<[email protected]>

---
  arch/arm/lib/Makefile |    1 +
  arch/arm/lib/proc.S   |   35 +++++++++++++++++++++++++++++++++++
  2 files changed, 36 insertions(+), 0 deletions(-)

create mode 100644 arch/arm/lib/proc.S

arch/arm/lib/Makefile +1 -0

index ca2802a..27749dc 100644
@@ -50,6 +50,7 @@ endif
 
  ifndef CONFIG_SYS_LEGACY_BOARD
  COBJS-y += arch_reloc.o
+SOBJS-y += proc.o
  endif
 
  SRCS	:= $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \

arch/arm/lib/proc.S new file +25 -0

new file mode 100644
index 0000000..99a2944
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+
+/**
+ * Jump to board_init_r with a new stack pointer
+ *

Hi Simon,

Le 22/11/2011 00:57, Simon Glass a ?crit :

Quoted 58 lines

Add a library to hold ARM assembler code which is generic across all ARM CPUs.

Signed-off-by Simon Glass<[email protected]>

---
?arch/arm/lib/Makefile | ? ?1 +
?arch/arm/lib/proc.S ? | ? 35 +++++++++++++++++++++++++++++++++++ ?2 files changed, 36 insertions(+), 0 deletions(-) ?create mode 100644 arch/arm/lib/proc.S

arch/arm/lib/Makefile +0 -0

index ca2802a..27749dc 100644
@@ -50,6 +50,7 @@ endif
 

?ifndef CONFIG_SYS_LEGACY_BOARD
?COBJS-y += arch_reloc.o
+SOBJS-y += proc.o
?endif

?SRCS ?:= $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \

arch/arm/lib/proc.S new file +30 -0

new file mode 100644
index 0000000..99a2944
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+
+/**
+ * Jump to board_init_r with a new stack pointer
+ *
+ * @param gd ? Pointer to global data
+ * @param dest_addr ? ?Destination address from global data
+ * @param func Address of board_init_r function (relocated)
+ * @param sp ? New stack pointer
+ */

arch/arm/lib/proc.S line 35

Quoted 5 lines

arch/arm/lib/proc.S new file +5 -0

+.globl proc_call_board_init_r
+proc_call_board_init_r:
+ ? ? ? mov ? ? sp, r3
+ ? ? ? /* jump to it ... */
+ ? ? ? mov ? ? pc, r2

What do we gain from this patch exactly?

Amicalement,
--
Albert.

board/reloc.c static int reloc_elf(void) · line 90

Quoted 5 lines · On Monday 21 November 2011 18:57:59 Simon Glass wrote:

board/reloc.c +1 -1

 
-void relocate_code(ulong dest_addr_sp, gd_t *new_gd, ulong dest_addr)
+void new_relocate_code(ulong dest_addr_sp, gd_t *new_gd, ulong dest_addr)

shouldn't this be squashed into the patch that added this func ?

nand_spl/board/freescale/mx31pdk/Makefile

Quoted 9 lines

nand_spl/board/freescale/mx31pdk/Makefile +5 -0

 
+$(obj)%.o: ? $(SRCTREE)/board/%.c
+ ? ? $(CC) $(CFLAGS) -c -o $@ $<
+
+$(obj)%.o: ? $(SRCTREE)/arch/arm/lib/%.S
+ ? ? $(CC) $(AFLAGS) -c -o $@ $<

ugh. ?is this the SOP for SPL or something ? ?this is awful :(.

-mike

board/reloc.c static int reloc_elf(void) · line 90

Quoted 5 lines · On Monday 21 November 2011 18:58:00 Simon Glass wrote:

board/reloc.c +1 -1

 
-void new_relocate_code(ulong dest_addr_sp, gd_t *new_gd, ulong dest_addr)
+void relocate_code(ulong dest_addr_sp, gd_t *new_gd, ulong dest_addr)

this is too fragile. ?we can't have every arch transition the way you did with arm (otherwise arches that have transitioned will break in between). ?declare this func weak and don't rename it. ?then there should be no migration issue. -mike

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. ?This is tricky mainly due to SPL. I believe that we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

Comments please...

Quoted 34 lines · Simon Glass

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. ?This is tricky mainly due to SPL. I believe that we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

Quoted 1 line

Comments please...

Seems like a good idea. ?Got some size's before and after? ?Maybe some boot times too (as you mention 2000-odd function calls during relocation) ?

--
Tom

Hi Tom,

Quoted 16 lines · Tom Rini

Quoted 15 lines · Simon Glass

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

Quoted 15 lines

Quoted 15 lines

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. This is tricky mainly due to SPL. I believe that we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

Quoted 4 lines

Quoted 4 lines

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

Comments please...

Quoted 7 lines

Seems like a good idea. Got some size's before and after? Maybe some boot times too (as you mention 2000-odd function calls during relocation) ?

--
Tom

Yes I have this info - will package it up tomorrow along with a new series to deal with review comments.

Hi Simon

Sorry for the late review on this - I've only just now had a good chance to look at it...

Quoted 19 lines

Hi Tom,

Quoted 16 lines · Tom Rini

Quoted 15 lines · Simon Glass

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

Ugh, that overhead is a killer - The relocation can be done entirely in a tight loop with a switch statement in your reloc_elf() function. But I think reloc_elf() should be weak - x86 relocation can be done in a few lines of assembler which is smaller and faster than a C implementation will ever be

Quoted 16 lines

Quoted 16 lines

Quoted 16 lines

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. ?This is tricky mainly due to SPL. I believe that we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

Comments please...

The whole sequence of the series seems a little bit 'random' to me - I think patches 2 and 3 can be squahed and the dead code removal in patch 7 should be done in the same patch(es) that create the dead code.

It looks like reloc_make_copy(), reloc_clear_bss() and reloc_elf() have been poached from x86 - The copy and clear loops are quite inefficient. I have patches at home which change these to use memcpy and memset

Quoted 11 lines

Quoted 8 lines

Seems like a good idea. ?Got some size's before and after? ?Maybe some boot times too (as you mention 2000-odd function calls during relocation) ?

--
Tom

Yes I have this info - will package it up tomorrow along with a new series to deal with review comments.

As far as I understand it, the long-term plan is to unify the board init sequence across all architectures. I can see three approaches:

?1) Tweak each arch until they are all the same and then 'throw the switch' ?2) Pick one or two arches and 'throw the switch' on them and migrate the ? ?others later
?3) Pull out common bits and pieced and deal with the left-overs later

It looks like you've opted for number 3. The problem I see in this approach is that you are relying on the other arches to follow your lead which is, at best, a 50/50 bet.

Now I look at board_init_f() and board_init_r() in ARM and x86 and think 'why on earth isn't most of than in the init loops?'. The boot sequence for ARM and x86 should be reducible to (all arches are generally pretty close to this, so it should not introduce too much pain when they decide to switch)

?- Low level init (reset vector etc)
?- Setup temporary stack and gd storage (typically in CPU cache) ?+ init_f loop <-- SDRAM initialised
?- Move gd to RAM
?- Setup new stack in SDRAM
?- Turn on caching (cannot be done while gd and stack in cache!!!) ?+ Calculate relocation address
?+ Copy to RAM
?+ Do relocation fixups
?+ Clear BSS
?- Jump to RAM
?+ init_r loop
?+ main_loop()

+ = common code
- = arch, SoC, or board specific

Note: Typically the boot sequence currently has 'Turn on caching' after jump to RAM - I have patches in the works which change this for x86

So my vote would be #2 - Unify the ARM and x86 and bring any code that can be inside the init loops in and then switch both over to a generic init implementation. Other arches can be switched later

Regards,

Graeme

Hi Graeme,

Quoted 5 lines · Graeme Russ

Hi Simon

Sorry for the late review on this - I've only just now had a good chance to look at it...

Thanks for the comments.

Quoted 21 lines · Simon Glass

Quoted 19 lines

Hi Tom,

Quoted 16 lines · Tom Rini

Quoted 15 lines · Simon Glass

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

Quoted 5 lines

Ugh, that overhead is a killer - The relocation can be done entirely in a tight loop with a switch statement in your reloc_elf() function. But I think reloc_elf() should be weak - x86 relocation can be done in a few lines of assembler which is smaller and faster than a C implementation will ever be

I will benchmark it tomorrow. If we move the for loop into the architecture-specific code then it goes away. Just seemed to me that the less duplicated code we have the better. We could use an inline function but I'm not keen on that.

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. This is tricky mainly due to SPL. I believe that we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

Quoted 9 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

Comments please...

The whole sequence of the series seems a little bit 'random' to me - I think patches 2 and 3 can be squahed and the dead code removal in patch 7 should be done in the same patch(es) that create the dead code.

Yes I can clean this up.

Quoted 3 lines

It looks like reloc_make_copy(), reloc_clear_bss() and reloc_elf() have been poached from x86 - The copy and clear loops are quite inefficient. I have patches at home which change these to use memcpy and memset

Yes they have - in fact I have a series here which unifies board.c completely for ARM and x86. But I need to take this in baby steps as I said.

Quoted 20 lines

Quoted 11 lines

Quoted 8 lines

Seems like a good idea. Got some size's before and after? Maybe some boot times too (as you mention 2000-odd function calls during relocation) ?

--
Tom

Yes I have this info - will package it up tomorrow along with a new series to deal with review comments.

As far as I understand it, the long-term plan is to unify the board init sequence across all architectures. I can see three approaches:

1) Tweak each arch until they are all the same and then 'throw the switch'
2) Pick one or two arches and 'throw the switch' on them and migrate the others later
3) Pull out common bits and pieced and deal with the left-overs later

Quoted 3 lines

It looks like you've opted for number 3. The problem I see in this approach is that you are relying on the other arches to follow your lead which is, at best, a 50/50 bet.

Sort of. Actually I have gone for option 2. But rather than send a series which switches over ARM and then x86 (about 40 patches) I have decided to do it in steps. Relocation is the first step.

Quoted 5 lines

Now I look at board_init_f() and board_init_r() in ARM and x86 and think 'why on earth isn't most of than in the init loops?'. The boot sequence for ARM and x86 should be reducible to (all arches are generally pretty close to this, so it should not introduce too much pain when they decide to switch)

Yes my generic board.c consists of a couple of init loops. I can email the patch if you like but it is not ready for the mailing list.

Quoted 17 lines

- Low level init (reset vector etc)
- Setup temporary stack and gd storage (typically in CPU cache)
+ init_f loop <-- SDRAM initialised
- Move gd to RAM
- Setup new stack in SDRAM
- Turn on caching (cannot be done while gd and stack in cache!!!)
+ Calculate relocation address
+ Copy to RAM
+ Do relocation fixups
+ Clear BSS
- Jump to RAM
+ init_r loop
+ main_loop()

+ = common code
- = arch, SoC, or board specific

Quoted 6 lines

Note: Typically the boot sequence currently has 'Turn on caching' after jump to RAM - I have patches in the works which change this for x86

So my vote would be #2 - Unify the ARM and x86 and bring any code that can be inside the init loops in and then switch both over to a generic init implementation. Other arches can be switched later

Agreed, but I can't send a series that big, so I am doing it in stages.

Quoted 31 lines · Simon Glass

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. ?This is tricky mainly due to SPL. I believe that we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

Quoted 4 lines

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

Comments please...

Seems like a good idea. ?Got some size's before and after? ?Maybe some boot times too (as you mention 2000-odd function calls during relocation) ?

--
Tom

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. This is tricky mainly due to SPL.

I believe that
we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

Comments please...

Hi Simon,

Le 22/11/2011 00:57, Simon Glass a ?crit :

Quoted 9 lines

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example.

On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level.

Agreed.

Quoted 5 lines

This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this.

NAK -- a generic relocation function should be not be in board/, it should be in lib/

Quoted 6 lines

For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later.

As commented in detail, I am not sure creating a function for three asm instructions is worthwhile. The overhead for calling the code might be bigger than the body of the function. Did you compare with inline functions with asm statements and/or intrinsics?

Quoted 7 lines

It may be useful for other architectures to have a similar file.

This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. ?This is tricky mainly due to SPL.

Can you develop what the issue is with SPL exactly?

Quoted 8 lines

I believe that
we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can.

Quoted 2 lines

(I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.)

This would not cause an error, but Wolfgang would have to "OK' the post, which is a good thing if many people are involved. :)

Quoted 2 lines

Comments please...

Generic comment is that the patch is not about generic *board*. It is about generic *relocation*, which is not a thing of boards IMO: it is not related to peripheral or HW configuration, and is not actually memory-mapped related.

Other than that, as stated in the detailed answers, we need to keep the relocation code as efficient as possible. As happy as I am to see the ELF relocation code rewritten in C for easy understanding and maintenance, I would not want it done at the expense of speed or overall architecture soundness. So:

- the C relocation code (both the generic function and the ELF specific code) are neither board-related nor ARM-specific, so it has no reason to reside in board/ or arch/arm. My first reflex was lib/, but indeed common/ might be a better place.

- the relocation function should be as efficient as possible. Compared numbers between 'before' and 'after' should also be provided -- I do not necessarily expect the same or better performance, but we need to assess what the performance issue is.

- I would prefer each patch to be as self-contained as possible -- 'preparatory' patches I don't like much. For instance, to relace ASM relocation with C relocation, I would want a single patch introducing the C code and removing the ASM code or moving it out of the way.

- I am not sure why the code should be "early" or, more precisely, should be specifically located in the linker file: any code in there is accessible at any time, and the only special case is for _start because we want it to be first in placement, not in time. Can you clarify this 'early' issue?

- indeed I would prefer a weak symbol for the relocation function. This would allow a given config to easily override the generic C code if needed.

Amicalement,
--
Albert.