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

[Graeme Russ]

Hi Simon

On Thu, Aug 25, 2011 at 9:41 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Graeme,

[big snip]

>
> Ick. The more I read of this thread the more I like your original
> implementation. It really doesn't seem that hard to see the order of
> initcalls either from System.map or objdump | grep or similar. Write a
> nice long Python script if you like! Your implementation allows
> tracing of initcalls as they are made which is a big win.

I'de like to keep any pre/post processing as simple as possible - limited
to grep, awk, and sed would be best

> Early init cannot necessarily printf() but I don't see why initcalls
> must solve a problem which exists currently anyway (I have been
> thinking about buffering pre-console pre-reloc output and printing it
> later - it's not that hard, just a bit ugly).

Allocate a buffer in pre-reloc RAM (Cache-As-RAM), have a pointer in gd
which points to where we are currently up to and redirect putc() if the
console has not been initialised. Immediately after console init, flush
the buffer via the now unredirected putc() and viola! I don't see this as
being too ugly. I might even have a go myself :)

> Yes moving to a dependency-based init sounds lovely, but this is
> U-Boot not Upstart. We do need to keep things reasonably simple - at

Yes, my initial thoughts are that building dependencies at build time
will be messy and at run time is a waste of CPU time

> least with your scheme we can tell at link time what the order will

Yes, but I understand Wolfgang's concern that prior to doing the build, it
is not obvious what the init sequence order will be. I personally think
that the current #ifdef'ing of the init array is not 'completely obvious'
either, but I conceded it is 'more obvious' than any proposed
implementation for the initcall sequence so far.

> be. The other thing is that init ordering is often not critical bar a
> few early routines, and most of these will be fixed by the order
> selected in the arch/xxx/lib/board.c code. Board maintainers would
> likely only have a few ranges within which to add their init, and
> strongly discouraged from inserting an init function into the middle
> of an existing stable sequence in that file.

I personally don't see not having an obvious init sequence pre-build as a
huge issue for me. The init sequence is not fiddled with often, and by
using the INIT_FUNC macro, there is a big red flag in any patch that
touches the init sequence.

I did start the think along the lines of four init.h files

 - /include/init.h for the sequence shared by all architectures
 - /include/<arch>/init.h - Arch specific, step numbering based on
   #defines in /include/init.h
 - /include/<arch>/<soc>/init.h - SoC specific, step numbering based on
   #defines in /include/init.h and /include/<arch>/init.h
 - /board/<board>/init.h - Board specific, step numbering based on
   #defines in /include/init.h, /include/<arch>/init.h and
   /include/<arch>/<soc>/init.h

But that would leave the definition of the init sequence splattered all
over the place. Maybe there is scope for a pre-compile stage like
asm-offsets, but again, you will not know the init order until you
actually do the build...

Creating a namespace for init step #defines, defining the entire init
sequence for every arch, SoC, and board in /include/init.h and using
grep to filter out the noise gets the init sequence in one spot, BUT,
just because INIT_ARCH_FOO is in init.h does not mean it will be included
in the build. The init array 'solves' this with #ifdefs around array
elements. I don't think this gives any greater clarity - It's not obvious
pre-compile if FOO is defined (although most decent IDE's are smart enough
to know that FOO is not defined and grey out the code, but this is far
from foolproof (I know eclipse has trouble when the #ifdef logic gets too
complicated, and most of the #defines do not even exist until you do a
make conig. Also, defining the whole sequence in /include/init.h breaks
my idea of a custom board init step not touching code outside the board
(an edit to /include/init.h is required - but that provides another red
flag for review)

> I do tend to agree that merging the board.c code is a bigger win, but
> this might be a nice vehicle for doing it, since one could imagine an
> incremental approach with a CONFIG_NEW_INIT option which can be turned
> on/off for each board. As problems with each architecture (then each
> board) are ironed out, the option will turned on in the board config
> file.

I must say, that my audit of the init code those far has been an eye
opener. As a collective, we have all let things drift to the point where
it starts to get all too hard to bring everthing back into line and we
just let the status quo continue. Relocation, timers, init and cache
handling are prime examples. I honestly think we should take a 'one mess
per merge window approach' - Decide on a drop-dead date for a global
change and just do it. Any arches, SoCs, or boards that don't make the
deadline get purged. It worked for ARM relocation ;)

> PS: Regarding the late night work, kids, wives, etc. I am reminded of
> that 'quote' from Dr Johnson about his work with his 'U-Boot':
>
> ...that has taken eighteen hours of every day for the last ten years.
> My mother died; I hardly noticed. My father cut off his head and fried it
> in garlic in the hope of attracting my attention; I scarcely looked up from
> my work.

Don't worry - I'm doing far less U-Boot coding now than I was a year ago
and probably more than I'll be doing in another year. At least when I do
stop, I can at least be happy that I made the contributions that I did.

I would at least like to see timers and init resolved before I hang up my
hat ;)

Regards,

Graeme