[U-Boot] [PATCH] ppc: transform init_sequence into a function.

[Graeme Russ]

On Tue, Dec 7, 2010 at 8:33 AM, Scott Wood <scottwood at freescale.com> wrote:
> On Mon, 6 Dec 2010 21:42:28 +0100
> Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
>
>> Wolfgang Denk <wd at denx.de> wrote on 2010/12/06 21:09:47:
>> >
>> > Dear Joakim Tjernlund,
>> >
>> > In message <1291658370-26367-1-git-send-email-Joakim.Tjernlund at transmode.se> you wrote:
>> > > init_sequence is an array with function pointers which
>> > > are really hard to follow when you need to debug this area.
>> > > Turn it into plain function calls instead which makes
>> > > the code a bit uglier but I find the simpler debugging
>> > > much more valuable.
>> >
>> > This is indeed much uglier.  What exactly is your problem with
>> > debugging the existing code?
>>
>> Whenever I screw up so that one of the init funcs crashes, often without
>> any trace on the RS232 port you don't know which one. Single stepping
>> though the loop is cumbersome and not easy as BDI tends to
>> flush the cache when it stops so you loose your stack.
>> The other way is to look up one those funs and set a BP there and hope
>> for the best. Then repeat with the next function and so on.
>> Compare that with just setting a BP in the new init_sequence(), it is
>> fast and easy to move around.
>>
>> I don't think you have been chasing bugs in this area for a long time,
>> if you had, you would appreciate how easy it is with functions
>> compared with a bunch of function ptrs.
>> I don't think this is much uglier, just a bit, but far more
>> useful and I have a hard time buying into "beautiful trumps usefulness".
>
> I think it's easier with the function pointers -- if you want to debug
> a hang in that phase of the boot, just have the loop print the address
> of each function before it calls it.

I agree, but you can't print the address before you have console output. I
notice that console_init_f() can be up to 13th in the list of initialisation
functions - How often is that the case? There seems to be a lot of SDRAM
initialisation prior to getting console output which, to me, seems a little
strange - surely console output can be achieved earlier (even if it is using
a hard-coded baud rate)

I've now got x86 Cache-As-RAM working and console output is in about
position four in the init sequence - from there I debug using printf()

I don't think it will be long before board_init_f() gets unified into common
code and I would hate to see this uglyness spread to all arches.

Regards,

Graeme