[U-Boot] [RFC] New init sequence processing without init_sequence array

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCJg5BPP_Z0VUMEfQgjpRYO=WDQBvvBFho6VbNovbRjFzQ at mail.gmail.com> you wrote:
> 
> So we end up with:
> 
> #DEFINE INIT_GLOBAL_START	10000
> #DEFINE INIT_X86_CPU_F		INIT_GLOBAL_START + 1
> #DEFINE INIT_ARM_CPU_F		INIT_GLOBAL_START + 1
> ...
> #DEFINE INIT_X86_<foo>		INIT_X86_<bar> + 1
> ...
> #DEFINE INIT_X86_TIMER		INIT_X86_<foo> + 1
> #DEFINE INIT_ARM_TIMER		INIT_ARM_CPU_F + 1
> ...
> #DEFINE INIT_ENET_TIMER		INIT_X86_TIMER + 1
> 
> So this gives you a single central location to quickly see the init
> sequence of any arch, SoC, or board.

But frankly: do you consider this list above _readable_?

So how do I figure out which steps are actually being executed?
I could, for example, assume that INIT_X86_TIMER and INIT_ARM_TIMER
are run at the same time (in random order) on one board - OK, here it
is obvious from the names that this is probably not the case, but we
will have other, less obvious situations.

> >>       #define CUSTOM_INIT_STEP        STANDARD_INIT_STEP + 1
> >
> > Hm... I don't really consider this an improvement.
> 
> Why not? See above - I think centralising EVERY init sequence in init.h
> rather than splatering board specific #ifdef's in arch/board.c is an
> improvement - YMMV

You keep the definitions in one place, but in a mor or less
unreadable form.

> That was released in May 2005 and in U-Boot parlance 'ancient' ;) - But I
> am well aware that lack of SORT_BY_NAME() is a total killer for what I am
> proposing. I need to know if anyone is using a linker that does not support
> SORT_BY_NAME(). If there are (and if those users have no option to use a
> linker that doeS) then the whole initcall idea is dead in the water anyway

We do have customers who are still using ELDK 2.1.0 from April 2003
(gcc version 2.95.4, binutils version version 2.11.93.0.2).  Agreed,
these are not using recent versions of U-Boot either.

> >> And the bad...
> >>  - Init sequence not clearly obvious in a single location
> 
> Well actually, I think I can resolve this

How?  Above suggestion is not a solution, but actually shows the
problem.

> Take timer initialisation for example - This is at a different step in
> every arch. I think this is easily resolved with a good #define namespace
> and putting it all in init.h

And this becomes easy to read and understand, then? :-(

> >>  - The names of the function can be (conditionally by DEBUG) added and
> >>    printed out as the init sequence is being run - Very nice for debugging
> >>    the init sequence
> >
> > You are actually wrong here - guess why the current init loop does not
> > contain such a debug()?  There are some init functions that need to be
> > run before you can output anything (for exaple, you must initialize
> > the console driver, including setting the baud rate or similar
> > parameters from the environment).
> 
> The current method cannot print the init function name unless the init
> function itself does so. I have included an additional component to the

It would be trivial to enable printing the names from the loop; we
can't do it because we don't have the needed prerequisites yet in most
cases.

> INIT_FUNC macro which adds the string name of the function and builds a
> second table of pointers to these strings. The init loop then simply steps
> through the function name pointers while stepping throught the function
> pointers. If we simply add a CONSOLE_INITIALISED flag into gd->flags then
> the output of the function names can be suppressed until console output
> is available.

You know that debugging becomes easy as soon as we have printf().
But how does this help you for the init steps _before_ you have a
working console?

> > If it works, yes.  My concern is what to do if it doesn't, how to
> > debug such situations, and how to review such code.
> 
> Debug is no different to now - The code is stepping through a table of
> function pointers. The new method can add the printing of the function

The difference is that I have a source file for reference.

With the init.h as above I have no such reference.

> about to be called (after console init) which makes life a little easier.
> As for patches, the inclusion of INIT_FUNC() in the patch is a red-flag to
> look more closely - Any new step will also include an addition to init.h

So init.h will quickly become an incomprehensible mess.

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 face of war has never changed.  Surely it is more logical to heal
than to kill.
	-- Surak of Vulcan, "The Savage Curtain", stardate 5906.5