[U-Boot] [RFC] initcall mechanism introduction

[U-Boot] [RFC] initcall mechanism introduction

[Jean-Christophe PLAGNIOL-VILLARD]

Hi all,

	Linux Kernel has for a long time a well-optimized mechanism for for
	calling initiallisation code. Import the the same functionnality to
	U-Boot.

	Evenif it will increase a few U-Boot (999 bytes) as show in PATCH 3/3
	if we convert the NET_MULTI it will decrease of 2212 bytes at the end

Best Regards,
J.

[U-Boot] [PATCH 2/3] arm: add initcalls_init

[Jean-Christophe PLAGNIOL-VILLARD]

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
 lib_arm/board.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib_arm/board.c b/lib_arm/board.c
index e081fbc..f40e227 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -42,6 +42,7 @@
 #include <command.h>
 #include <malloc.h>
 #include <devices.h>
+#include <init.h>
 #include <timestamp.h>
 #include <version.h>
 #include <net.h>
@@ -284,6 +285,7 @@ init_fnc_t *init_sequence[] = {
 #if defined(CONFIG_DISPLAY_BOARDINFO)
 	checkboard,		/* display board info */
 #endif
+	initcalls_init,
 #if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
 	init_func_i2c,
 #endif
-- 
1.6.3.1

[U-Boot] [PATCH 3/3] net: switch device init to initcall

[Jean-Christophe PLAGNIOL-VILLARD]

apply to at91sam9263ek

this will result to reduce the size of 2212 bytes

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
 board/atmel/at91sam9263ek/at91sam9263ek.c |   12 ++++++------
 include/netdev.h                          |   12 ------------
 net/eth.c                                 |   16 ----------------
 3 files changed, 6 insertions(+), 34 deletions(-)

diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c b/board/atmel/at91sam9263ek/at91sam9263ek.c
index 57d5c95..54b0f59 100644
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -23,6 +23,7 @@
  */
 
 #include <common.h>
+#include <init.h>
 #include <asm/sizes.h>
 #include <asm/arch/at91sam9263.h>
 #include <asm/arch/at91sam9263_matrix.h>
@@ -272,11 +273,10 @@ void reset_phy(void)
 }
 #endif
 
-int board_eth_init(bd_t *bis)
-{
-	int rc = 0;
 #ifdef CONFIG_MACB
-	rc = macb_eth_initialize(0, (void *)AT91SAM9263_BASE_EMAC, 0x00);
-#endif
-	return rc;
+static int at91sam9263ek_eth_init(bd_t *bis)
+{
+	return macb_eth_initialize(0, (void *)AT91SAM9263_BASE_EMAC, 0x00);
 }
+__initcall(at91sam9263ek_eth_init);
+#endif
diff --git a/include/netdev.h b/include/netdev.h
index 63cf730..9860c99 100644
--- a/include/netdev.h
+++ b/include/netdev.h
@@ -28,18 +28,6 @@
 #ifndef _NETDEV_H_
 #define _NETDEV_H_
 
-/*
- * Board and CPU-specific initialization functions
- * board_eth_init() has highest priority.  cpu_eth_init() only
- * gets called if board_eth_init() isn't instantiated or fails.
- * Return values:
- *      0: success
- *     -1: failure
- */
-
-int board_eth_init(bd_t *bis);
-int cpu_eth_init(bd_t *bis);
-
 /* Driver initialization prototypes */
 int au1x00_enet_initialize(bd_t*);
 int bfin_EMAC_initialize(bd_t *bis);
diff --git a/net/eth.c b/net/eth.c
index 8940ebf..2904180 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -56,18 +56,6 @@ int eth_setenv_enetaddr(char *name, const uchar *enetaddr)
 #endif
 
 #if defined(CONFIG_CMD_NET) && defined(CONFIG_NET_MULTI)
-
-/*
- * CPU and board-specific Ethernet initializations.  Aliased function
- * signals caller to move on
- */
-static int __def_eth_init(bd_t *bis)
-{
-	return -1;
-}
-int cpu_eth_init(bd_t *bis) __attribute__((weak, alias("__def_eth_init")));
-int board_eth_init(bd_t *bis) __attribute__((weak, alias("__def_eth_init")));
-
 extern int mv6436x_eth_initialize(bd_t *);
 extern int mv6446x_eth_initialize(bd_t *);
 
@@ -191,10 +179,6 @@ int eth_initialize(bd_t *bis)
 #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
 	miiphy_init();
 #endif
-	/* Try board-specific initialization first.  If it fails or isn't
-	 * present, try the cpu-specific initialization */
-	if (board_eth_init(bis) < 0)
-		cpu_eth_init(bis);
 
 #if defined(CONFIG_DB64360) || defined(CONFIG_CPCI750)
 	mv6436x_eth_initialize(bis);
-- 
1.6.3.1

[U-Boot] [PATCH 3/3] net: switch device init to initcall

[Ben Warren]

Jean-Christophe,

On Sat, May 23, 2009 at 8:08 AM, Jean-Christophe PLAGNIOL-VILLARD <
plagnioj@jcrosoft.com> wrote:

> apply to at91sam9263ek
>
> this will result to reduce the size of 2212 bytes
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
>  board/atmel/at91sam9263ek/at91sam9263ek.c |   12 ++++++------
>  include/netdev.h                          |   12 ------------
>  net/eth.c                                 |   16 ----------------
>  3 files changed, 6 insertions(+), 34 deletions(-)
>
<snip>

> -       /* Try board-specific initialization first.  If it fails or isn't
> -        * present, try the cpu-specific initialization */
> -       if (board_eth_init(bis) < 0)
> -               cpu_eth_init(bis);
>
Good idea, but your implementation is flawed.  It's critically important
that the prioritization of board ethernet initialization over CPU ethernet
initialization be preserved.  Your idea doesn't handle that (at least that I
can see).

regards,
Ben

[U-Boot] [PATCH 3/3] net: switch device init to initcall

[Jean-Christophe PLAGNIOL-VILLARD]

On 08:41 Sat 23 May     , Ben Warren wrote:
>    Jean-Christophe,
> 
>    On Sat, May 23, 2009 at 8:08 AM, Jean-Christophe PLAGNIOL-VILLARD
>    <plagnioj@jcrosoft.com> wrote:
> 
>      apply to at91sam9263ek
> 
>      this will result to reduce the size of 2212 bytes
> 
>      Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>      ---
>       board/atmel/at91sam9263ek/at91sam9263ek.c |   12 ++++++------
>       include/netdev.h                          |   12 ------------
>       net/eth.c                                 |   16 ----------------
>       3 files changed, 6 insertions(+), 34 deletions(-)
> 
>    <snip>
> 
>      -       /* Try board-specific initialization first.  If it fails or
>      isn't
>      -        * present, try the cpu-specific initialization */
>      -       if (board_eth_init(bis) < 0)
>      -               cpu_eth_init(bis);
> 
>    Good idea, but your implementation is flawed.  It's critically important
>    that the prioritization of board ethernet initialization over CPU ethernet
>    initialization be preserved.  Your idea doesn't handle that (at least that
>    I can see).
with this only patch yes, but I'm preparing a full implementation that will
If I understand correctly the board_eth_init is unsed to overwrite the default
cpu_eth_init by passing different parameter

with a device/driver model this will be handle correctly

Best Regards,
J.

[U-Boot] [PATCH 3/3] net: switch device init to initcall

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090523163600.GD26561@game.jcrosoft.org> you wrote:
>
> >    Good idea, but your implementation is flawed.  It's critically important
> >    that the prioritization of board ethernet initialization over CPU ethernet
> >    initialization be preserved.  Your idea doesn't handle that (at least that
> >    I can see).
> with this only patch yes, but I'm preparing a full implementation that will
> If I understand correctly the board_eth_init is unsed to overwrite the default
> cpu_eth_init by passing different parameter

I would appreciate if you would - before spending time and effort  on
actual  implementation  -  try  and  discuss  your  ideas  for such a
far-reaching change. So far, I cannot even see which sort of  benefit
you expect - keep in mind that U-Boot does not use virtual memory, so
initcall memory freed will remain dead and unusable. Would you please
explain where you expect advantages from such an implementation?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.

[U-Boot] [PATCH 3/3] net: switch device init to initcall

[Ben Warren]

On Sat, May 23, 2009 at 9:36 AM, Jean-Christophe PLAGNIOL-VILLARD <
plagnioj@jcrosoft.com> wrote:

> On 08:41 Sat 23 May     , Ben Warren wrote:
> >    Jean-Christophe,
> >
> >    On Sat, May 23, 2009 at 8:08 AM, Jean-Christophe PLAGNIOL-VILLARD
> >    <plagnioj@jcrosoft.com> wrote:
> >
> >      apply to at91sam9263ek
> >
> >      this will result to reduce the size of 2212 bytes
> >
> >      Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <
> plagnioj at jcrosoft.com>
> >      ---
> >       board/atmel/at91sam9263ek/at91sam9263ek.c |   12 ++++++------
> >       include/netdev.h                          |   12 ------------
> >       net/eth.c                                 |   16 ----------------
> >       3 files changed, 6 insertions(+), 34 deletions(-)
> >
> >    <snip>
> >
> >      -       /* Try board-specific initialization first.  If it fails or
> >      isn't
> >      -        * present, try the cpu-specific initialization */
> >      -       if (board_eth_init(bis) < 0)
> >      -               cpu_eth_init(bis);
> >
> >    Good idea, but your implementation is flawed.  It's critically
> important
> >    that the prioritization of board ethernet initialization over CPU
> ethernet
> >    initialization be preserved.  Your idea doesn't handle that (at least
> that
> >    I can see).
> with this only patch yes, but I'm preparing a full implementation that will
> If I understand correctly the board_eth_init is unsed to overwrite the
> default
> cpu_eth_init by passing different parameter
>
> with a device/driver model this will be handle correctly
>
I'm not really sure why you used this one as an example, then, since it
doesn't provide any obvious benefit.  As far as I can tell, the only benefit
of using the Linux-style grouping of initialization calls is to control flow
during boot-up, and U-boot already handles this pretty well IMHO.  I think
in U-boot it will only make the code harder to read and understand.  I'd be
interested in seeing a different example, though.

regards,
Ben

[U-Boot] [RFC] initcall mechanism introduction

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090523150558.GB26561@game.jcrosoft.org> you wrote:
> 
> 	Linux Kernel has for a long time a well-optimized mechanism for for
> 	calling initiallisation code. Import the the same functionnality to
> 	U-Boot.
> 
> 	Evenif it will increase a few U-Boot (999 bytes) as show in PATCH 3/3
> 	if we convert the NET_MULTI it will decrease of 2212 bytes at the end

What would be the purpose of this in a boot loader?

For Linux iot makes sense to free each and every  byte  which  is  no
longer  needed  because  applications running can really benefir from
it. But in U-Boot? Please check the memory map of the running system.
The memory regained will not even be usable by anybody...

What sort of benefit do you expect?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A weak mind is like a microscope, which magnifies trifling things,
but cannot receive great ones.      -- Philip Earl of Chesterfield

[U-Boot] [RFC] initcall mechanism introduction

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:19 Sat 23 May     , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090523150558.GB26561@game.jcrosoft.org> you wrote:
> > 
> > 	Linux Kernel has for a long time a well-optimized mechanism for for
> > 	calling initiallisation code. Import the the same functionnality to
> > 	U-Boot.
> > 
> > 	Evenif it will increase a few U-Boot (999 bytes) as show in PATCH 3/3
> > 	if we convert the NET_MULTI it will decrease of 2212 bytes at the end
> 
> What would be the purpose of this in a boot loader?
> 
> For Linux iot makes sense to free each and every  byte  which  is  no
> longer  needed  because  applications running can really benefir from
> it. But in U-Boot? Please check the memory map of the running system.
> The memory regained will not even be usable by anybody...
it you read the patch 1 you will see that I've no which to free it
> 
> What sort of benefit do you expect?
simplify the code, reduce the number of ifdef
reduce the size of U-Boot etc...

I do have some test and I've gain between 2KiB and more than 10KiB
by using this

so yes I think it's great winn

Best Regards,
J.

[U-Boot] [RFC] initcall mechanism introduction

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090524120041.GG26561@game.jcrosoft.org> you wrote:
>
> > What sort of benefit do you expect?
> simplify the code, reduce the number of ifdef
> reduce the size of U-Boot etc...

How would that reduce the size of the code?

> I do have some test and I've gain between 2KiB and more than 10KiB
> by using this

And, does it still work on all boards?

> so yes I think it's great winn

I think you don't understand the complexity yet. One problem we  have
to  solve  is  to make sure we have a very specific sequence in which
the init routines are run. The original idea of the code was that you
can #define the init_sequence[] table in an architecture and/or board
config file; it's just that nobody implemented that yet.

If you changed the code in this direction, then this might actually
make sense.

The Linux way of doing initcalls is useless for U-Boot, as it addres-
ses a completely different problem  and  is  based  on  a  completely
different memory management model.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never put off until tomorrow what you can put off indefinitely.

[U-Boot] [RFC] initcall mechanism introduction

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:57 Sun 24 May     , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090524120041.GG26561@game.jcrosoft.org> you wrote:
> >
> > > What sort of benefit do you expect?
> > simplify the code, reduce the number of ifdef
> > reduce the size of U-Boot etc...
> 
> How would that reduce the size of the code?
just as example remove the weak function will reduce the code
as show in the patch 3 just re-implement it through it will reduce the
size by 2KiB.
> 
> > I do have some test and I've gain between 2KiB and more than 10KiB
> > by using this
> 
> And, does it still work on all boards?
for my current test more api you use more you win
as I've not test on all boards I can not certify it
> 
> > so yes I think it's great winn
> 
> I think you don't understand the complexity yet. One problem we  have
> to  solve  is  to make sure we have a very specific sequence in which
> the init routines are run. The original idea of the code was that you
> can #define the init_sequence[] table in an architecture and/or board
> config file; it's just that nobody implemented that yet.
> 
> If you changed the code in this direction, then this might actually
> make sense.
no with initcalls you will be able to do it
as it will be a matter of at which state you want to init your code
so each arch will be able to specify it and you will be able to also add
specific init level on need
we are not forced to have the same lds for all arch and/or board too
actually I've create only one init.h but we can add a arch specificity

Best Regards,
J.

[U-Boot] [RFC] initcall mechanism introduction

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090524150444.GI26561@game.jcrosoft.org> you wrote:
> 
> > If you changed the code in this direction, then this might actually
> > make sense.
> no with initcalls you will be able to do it

May be, but in my opinion at the cost of higher complexity.

I don't see any urgency to move in this direction.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Put your Nose to the Grindstone!
                 -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

[U-Boot] [RFC] initcall mechanism introduction

[Scott Wood]

On Sun, May 24, 2009 at 04:57:25PM +0200, Wolfgang Denk wrote:
> I think you don't understand the complexity yet. One problem we  have
> to  solve  is  to make sure we have a very specific sequence in which
> the init routines are run. The original idea of the code was that you
> can #define the init_sequence[] table in an architecture and/or board
> config file; it's just that nobody implemented that yet.

IMHO, it is much better for the information on what needs to be run on
init to reside in the file that needs to be called, rather than copied to
a bunch of different arch files.

In what practical case would one arch want to run component X before
component Y, but another want to run component Y before component X?  If
component X is always supposed to come before component Y, that can be
done with different levels of initcalls, or just by arranging the
makefiles appropriately (with a comment warning people not to change it).

> If you changed the code in this direction, then this might actually
> make sense.
> 
> The Linux way of doing initcalls is useless for U-Boot, as it addres-
> ses a completely different problem  and  is  based  on  a  completely
> different memory management model.

Initcalls are not the same thing as init code/data (other than the
coincidence that in Linux, they would typically reside in such sections). 

This has nothing to do with memory management.

-Scott

[U-Boot] [RFC] initcall mechanism introduction

[Wolfgang Denk]

Dear Scott,

in message <20090526210046.GA4669@b07421-ec1.am.freescale.net> you wrote:
> 
> IMHO, it is much better for the information on what needs to be run on
> init to reside in the file that needs to be called, rather than copied to
> a bunch of different arch files.

Then you might end up with another maze of #ifdef's...

> In what practical case would one arch want to run component X before
> component Y, but another want to run component Y before component X?  If

Boards are different... see for example "lib_ppc/board.c" - on some
boards (BAB7xx and CPC45) we must initialize PCI early, while on some
others we cannot initialize it that early.

> component X is always supposed to come before component Y, that can be
> done with different levels of initcalls, or just by arranging the
> makefiles appropriately (with a comment warning people not to change it).

The problem is that there is no such fix order. It is board dependent.

> > The Linux way of doing initcalls is useless for U-Boot, as it addres-
> > ses a completely different problem  and  is  based  on  a  completely
> > different memory management model.
> 
> Initcalls are not the same thing as init code/data (other than the
> coincidence that in Linux, they would typically reside in such sections). 
> 
> This has nothing to do with memory management.

But saving memory was one of j24's arguments?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offence.
          -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

[U-Boot] [RFC] initcall mechanism introduction

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:54 Tue 26 May     , Wolfgang Denk wrote:
> Dear Scott,
> 
> in message <20090526210046.GA4669@b07421-ec1.am.freescale.net> you wrote:
> > 
> > IMHO, it is much better for the information on what needs to be run on
> > init to reside in the file that needs to be called, rather than copied to
> > a bunch of different arch files.
> 
> Then you might end up with another maze of #ifdef's...
> 
> > In what practical case would one arch want to run component X before
> > component Y, but another want to run component Y before component X?  If
> 
> Boards are different... see for example "lib_ppc/board.c" - on some
> boards (BAB7xx and CPC45) we must initialize PCI early, while on some
> others we cannot initialize it that early.
so it's not really a problem as you can create for thoze two specific boards an
early init easly

and just for the understanding why does they need it?
> 
> > component X is always supposed to come before component Y, that can be
> > done with different levels of initcalls, or just by arranging the
> > makefiles appropriately (with a comment warning people not to change it).
> 
> The problem is that there is no such fix order. It is board dependent.
not really the initcall can be easly update via early init or if really need
by updating the linker script. Which I think will the last think to do.
> 
> > > The Linux way of doing initcalls is useless for U-Boot, as it addres-
> > > ses a completely different problem  and  is  based  on  a  completely
> > > different memory management model.
> > 
> > Initcalls are not the same thing as init code/data (other than the
> > coincidence that in Linux, they would typically reside in such sections). 
> > 
> > This has nothing to do with memory management.
> 
> But saving memory was one of j24's arguments?
It's true but the binary size (u-boot.bin) not the memory management

Best Regards,
J.

[U-Boot] [RFC] initcall mechanism introduction

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090526220736.GB30039@game.jcrosoft.org> you wrote:
>
> > Boards are different... see for example "lib_ppc/board.c" - on some
> > boards (BAB7xx and CPC45) we must initialize PCI early, while on some
> > others we cannot initialize it that early.
> so it's not really a problem as you can create for thoze two specific boards an
> early init easly

This was just one example - one which I had ready in memory. There are
probably more of these.

> and just for the understanding why does they need it?

Please see the comments in the code.

> > But saving memory was one of j24's arguments?
> It's true but the binary size (u-boot.bin) not the memory management

So where exactly do you think you can save memory?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Why should we subsidize intellectual curiosity?" - Ronald Reagan

[U-Boot] [RFC] initcall mechanism introduction

[Scott Wood]

Wolfgang Denk wrote:
> Dear Scott,
> 
> in message <20090526210046.GA4669@b07421-ec1.am.freescale.net> you wrote:
>> IMHO, it is much better for the information on what needs to be run on
>> init to reside in the file that needs to be called, rather than copied to
>> a bunch of different arch files.
> 
> Then you might end up with another maze of #ifdef's...

Only when you have a situation like the BAB7xx/CPC45 (in which case you 
could ifdef the priority -- or just ifndef the initcall for those boards 
and handle that special case manually).  You wouldn't have ifdefs for 
just the presence of the thing that needs to be initialized, and it 
would be only in one place rather than X arch files.

>> component X is always supposed to come before component Y, that can be
>> done with different levels of initcalls, or just by arranging the
>> makefiles appropriately (with a comment warning people not to change it).
> 
> The problem is that there is no such fix order. It is board dependent.

There will be exceptions, but for many things there's just no reason for 
the board to care (such as the time at which we run relocation fixups or 
other data structure initialization for things in common/).  One 
shouldn't have to change a bunch of arch files in order to add some new 
common code that needs init.

>> This has nothing to do with memory management.
> 
> But saving memory was one of j24's arguments?

I assume he meant that the image size was smaller, due to replacing 
explicit function calls with a table-driven approach.

-Scott

[U-Boot] [RFC] initcall mechanism introduction

[Wolfgang Denk]

Dear Scott Wood,

In message <4A1C6B48.9050106@freescale.com> you wrote:
>
> I assume he meant that the image size was smaller, due to replacing 
> explicit function calls with a table-driven approach.

We already have such a functionpoointer table - problem is that we
don't use it everywhere, usually because the init function calls are
intermixed with other code.

init_fnc_t *init_sequence[] was the idea that was supposed to solve
this very problem, but look at the code...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Bus error -- please leave by the rear door.

[U-Boot] [RFC] initcall mechanism introduction

[Haavard Skinnemoen]

Wolfgang Denk wrote:
> > component X is always supposed to come before component Y, that can be
> > done with different levels of initcalls, or just by arranging the
> > makefiles appropriately (with a comment warning people not to change it).  
> 
> The problem is that there is no such fix order. It is board dependent.

In other words, what we have right now is the worst of both worlds:
  - There are shitloads of #ifdefs in the arch code to cope with
    different board requirements.
  - There are huge differences between each architecture's init
    sequence which makes it hard to write generic code elsewhere, and
    hard to maintain each architecture since the init sequence needs to
    be changed when new boards add new features, and there's no
    "standard" way of doing it so the chances of getting it right to
    begin with are very slim.

Also, the chances of getting this mess cleaned up is very slim since
you need to touch all architectures in order to change something.

IMO, introducing a common init sequence for all architectures would be
an important step on the way to make this code somewhat maintainable,
no matter how messy the initial result ends up being. Or perhaps a
better first step would be to clean up the ppc code since it's what new
architectures tend to copy, and it's just such an insane mess right now.

Haavard

[U-Boot] [RFC] initcall mechanism introduction

[Stefan Roese]

On Wednesday 27 May 2009 09:52:35 Haavard Skinnemoen wrote:
> Wolfgang Denk wrote:
> > > component X is always supposed to come before component Y, that can be
> > > done with different levels of initcalls, or just by arranging the
> > > makefiles appropriately (with a comment warning people not to change
> > > it).
> >
> > The problem is that there is no such fix order. It is board dependent.
>
> In other words, what we have right now is the worst of both worlds:
>   - There are shitloads of #ifdefs in the arch code to cope with
>     different board requirements.

ACK. Most of this code was added a long time ago. We wouldn't accept this 
board specific "hacks" (especially in lib_ppc/board.c) in the common code 
right now any more.

>   - There are huge differences between each architecture's init
>     sequence which makes it hard to write generic code elsewhere, and
>     hard to maintain each architecture since the init sequence needs to
>     be changed when new boards add new features, and there's no
>     "standard" way of doing it so the chances of getting it right to
>     begin with are very slim.
>
> Also, the chances of getting this mess cleaned up is very slim since
> you need to touch all architectures in order to change something.

Yes, I noticed this while moving the malloc initialisation to an earlier 
stage. It would be really a great improvement if we could consolidate those 
lib_arch/board.c implementations somehow.

> IMO, introducing a common init sequence for all architectures would be
> an important step on the way to make this code somewhat maintainable,
> no matter how messy the initial result ends up being. Or perhaps a
> better first step would be to clean up the ppc code since it's what new
> architectures tend to copy, and it's just such an insane mess right now.

ACK. Even though I don't have a clue right now how this could be accomplished 
in practise without breaking some of the (old) board ports.

Nevertheless I think that Jean-Christophe's inicall approach is a good idea 
which could/should be used here.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [RFC] initcall mechanism introduction

[Mike Frysinger]

On Wednesday 27 May 2009 04:12:21 Stefan Roese wrote:
> ACK. Even though I don't have a clue right now how this could be
> accomplished in practise without breaking some of the (old) board ports.

i thought current practice was that if no one cared to update board ports and 
verify they still worked, then they were in effect dead and should be dropped.

i'd also support initcall integration, but in order to have correct 
initialization order for core aspects, we're still going to need a hardcoded 
list somewhere -- this is how the kernel works too after all.  hopefully this 
would allow us to unify the board init process into common code though.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090527/fff37cf3/attachment.pgp