Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-08 Thread Graeme Russ
Hi Simon, On 08/01/12 09:39, Simon Glass wrote: Hi Gururaja, On Thu, Jan 5, 2012 at 11:25 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: On Fri, Jan 06, 2012 at 12:05:40, Wolfgang Denk wrote: Dear Hebbar, Gururaja, [snip] _after_ the list has been created - If this breaks

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-07 Thread Simon Glass
Hi Gururaja, On Thu, Jan 5, 2012 at 11:25 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: On Fri, Jan 06, 2012 at 12:05:40, Wolfgang Denk wrote: Dear Hebbar, Gururaja, [snip] _after_ the list has been created - If this breaks dependencies that's your problem ;). It is up to you as

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-05 Thread Graeme Russ
Hi Wolfgang, On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk w...@denx.de wrote: Dear Graeme, In message 4f02da64.60...@gmail.com you wrote: [snip] INIT_FUNC(cpu_init_f, f, fred, blah, foo); Generates the string: f:cpu_init_f:fred:blah:foo and we can parse each of the elf archives to

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-05 Thread Simon Glass
Hi Graham, On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Wolfgang, On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk w...@denx.de wrote: Dear Graeme, In message 4f02da64.60...@gmail.com you wrote: [snip] INIT_FUNC(cpu_init_f, f, fred, blah, foo); Generates

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-05 Thread Graeme Russ
Hi Simon, On Fri, Jan 6, 2012 at 3:30 PM, Simon Glass s...@chromium.org wrote: Hi Graham, On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Wolfgang, On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk w...@denx.de wrote: Dear Graeme, In message

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-05 Thread Hebbar, Gururaja
Hi, On Fri, Jan 06, 2012 at 10:29:48, Graeme Russ wrote: Hi Simon, On Fri, Jan 6, 2012 at 3:30 PM, Simon Glass s...@chromium.org wrote: Hi Graham, On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Wolfgang, On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-05 Thread Wolfgang Denk
Dear Graeme Russ, In message calbutclvdsigmpwt04+-aqpdvj_zx9zzkbxh+ifcsxdxabd...@mail.gmail.com you wrote: Can we get rid of the 'f' parameter? If we invent a prerequisite called 'relocated' or something like that, to act as a barrier, then maybe the order can be defined just like any

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-05 Thread Wolfgang Denk
Dear Hebbar, Gururaja, In message 1bafe6f6c881bf42822005164f1491c305c...@dbde01.ent.ti.com you wrote: Well I kind of like see that a particular init function is explicitly a pre- or post- relocation function. But yes, having barrier pre-requisites would achieve the same effect. This

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-03 Thread Graeme Russ
Hi Wolfgang, On 03/01/12 01:49, Wolfgang Denk wrote: Dear Graeme Russ, In message 4f019abb.9010...@gmail.com you wrote: Which got me to thinking, what if we had an initcall macro which included the dependency information. Imagine this rough example: ... INITCALL(display_banner, banner,

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-03 Thread Wolfgang Denk
Dear Graeme, In message 4f02da64.60...@gmail.com you wrote: INITCALL(display_banner, banner, dram,board_early) Which says that the display_banner() function, when completed fulfils the 'banner' dependency, and requires both the 'dram' and 'board_early' dependencies to be fulfilled in

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-03 Thread Simon Glass
Hi Graham, On Tue, Jan 3, 2012 at 2:37 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Wolfgang, On 03/01/12 01:49, Wolfgang Denk wrote: Dear Graeme Russ, In message 4f019abb.9010...@gmail.com you wrote: Which got me to thinking, what if we had an initcall macro which included the

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-03 Thread Graeme Russ
Hi Wolfgang, On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk w...@denx.de wrote: Dear Graeme, In message 4f02da64.60...@gmail.com you wrote: [snip] One thing comes to mind: it would be nice if we can find a way that the INIT_FUNC definitions behave similar to weak functions - if an

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-03 Thread Wolfgang Denk
Dear Simon Glass, In message capnjgz3aoyvypa93ecbmyqhcaazcbphfcyhxyya1ax+9_ue...@mail.gmail.com you wrote: I have been thinking if there is a way we can avoid the post-processing perhaps by specifying two function parameters to the macro (the init function to call and its prerequisite) and

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-03 Thread Simon Glass
Hi Wolfgang, On Tue, Jan 3, 2012 at 2:36 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message capnjgz3aoyvypa93ecbmyqhcaazcbphfcyhxyya1ax+9_ue...@mail.gmail.com you wrote: I have been thinking if there is a way we can avoid the post-processing perhaps by specifying two

[U-Boot] initcall revisited - A new idea to discuss

2012-01-02 Thread Graeme Russ
Hi All, I've been thinking about the renaissance of the arch-independent initialisation sequence that has been generating a somewhat 'warm' discussion lately and had a thought based on a comment passed on by Wolfgang from Detlev: basicly what we are trying to solve is a dependency issue: each

Re: [U-Boot] initcall revisited - A new idea to discuss

2012-01-02 Thread Wolfgang Denk
Dear Graeme Russ, In message 4f019abb.9010...@gmail.com you wrote: Which got me to thinking, what if we had an initcall macro which included the dependency information. Imagine this rough example: ... INITCALL(display_banner, banner, dram,board_early) Which says that the display_banner()