[U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ1eutEboyvEtYcxcZcv=1Z_3tKq_45wBrgNdPsnxRth3A at mail.gmail.com> you wrote:
> 
> >> - getting generic relocation working
> >
> > I don;t see why this would be a direct prerequisite here. =A0We want to
> > have that, no boubt about that. =A0But it appears to be an unrelated
> > change to me.
> 
> I don't think it's essential, but it is desirable, which I why it is
> on the list.

I recommend to put this on a different list.  Please keep changes
orthogonal and restict this discussion and patch series to things
dealing with the normalization of the board init code.

This is complicated enough, and it does not good to include
additional, unrelated tasks.

> >> - adding functions for anything that is missing from board init code
> >
> > "anything that is missing from board init code" ?
> 
> By that I mean that if the architecture has its own little things
> which aren't supported by generic board init, then these would need to
> be worked into the generic board init somehow, perhaps initially with
> a new function in the initcall list.

Such an approach will most probable result in a mess of code that is
even more dificult to maintain than the current split we have now.

> >> - removing things which don't work on the architecture?
> >
> > That would probably reander systems broken that need these things?
> 
> Sorry for being so vague. What I mean is that if an arch does not
> support a feature, then we don't want to call the init functions for
> it on that architecture. Sometimes this is handled automatically -
> e.g. if an arch does not support CONFIG_POST then the generic board
> init code will skip this anyway. But there may be other cases where
> features available in the generic board init cannot be supported in
> all archs.

This is the same problem as above, right?  Each architecture, and
actually each board may or may not require certain initializations,
and actually may require them to happen in a certain order (which may
be different from other boards).

> > Keep in mind that my original ida of providing a function call table
> > was to allow to define this table in a board specific way (i. e. in
> > the board config file).
> >
> > [Not that this idea found many friends...]
> 
> With this series I have moved over to purely having a function call
> table, with no actual init code in board_init_f() and board_init_r().

This was the original plan.

> Having done this, I have found that the list of functions is very
> long, So we probably don't want boards to duplicate this list and
> #ifdefs may be the lesser of two evils. If we can move to Graham'

I don't really see this as an practical approach.  Did you look at the
PPC code?  init_sequence[]  has a total of 29 entries, "decorated"
with 21 conditionals.  If we merge in ARM and x86, we will have a mess
nobody is able to understand.

> For now I have tried to simply move the code into separate functions,
> since this makes it easier to compare against the original code in the
> arch/xxx/lib/board.c files, to make sure nothing is left out and the
> ordering is OK.

Agreed.

> I'm not convinced it is the best idea. A trivial change of just
> removing duplicated code from all the archs and inserting it into
> generic board should be safe enough. But is that really a common case?
> I have found lots of subtle differences that need to be worked out,
> and there is the ordering to worry about. Every time there is a patch
> we need to re-test all boards. It might be easier to just create a
> generic board implementation one, and then test it once on each board,
> rather than testing on each board with every patch. Of course every
> time you patch generic board you might introduce a breakage in an
> existing (previously working) board, but that is the normal situation
> with development so I don't see a problem there.
> 
> Perhaps the biggest problem is the difficulty of testing, and if we
> can avoid months of little patches (each one potentially breaking lots
> of boards at run-time) then I would prefer that.

I am not sure that the whole approach makes sense.  The resulkting
mess of #ifdef's is not there because people didn't care, but because
of very specific requirements of specific hardware, that - at least
given the tools of the respective point of time - could not be solved
more efficiently.

I see two options here:

- We can take the existing code and try to unify it, and make all
  boards (including a large number of EOLed and unmaintained ones) to
  that new code base.

  This will be a lot of work, and the resulting code will probably
  messy again.

- We could as well try to come up with a new, cleaned up implementa-
  tion that maybe doesn't fit all, but only 80 or 90% of the existing
  boards.  We could then (1) convert existing code step by step to the
  new implementation and (2) accept new submissions only when using
  the new code.

  There may be a number of boards where conversion is non trivial, or
  where nobody is willing or able to perform the changes and / or the
  testing.  My gut feeling tis that this would be a relatively small
  number of boards, and mostly old and unmaintained ones.  We might
  give them some grace period and then remove them.


> Well I suppose that's what I'm saying. Doing this once, accepting that
> some boards will thereby be broken, and then accepting patches to fix
> them feels easier than trying to keep everything working through a
> long series of little changes.

You appear to assume that onlly a small percentage of boards would be
broken.  My expectations are different.  Intentionally causing
breakage may be useful here and there, but I don;t think it;s the
right thing here.

> >> It is a feature used by about half, and it does include the complexity
> >> of jumping from pre-reloc to post-reloc init. I think it was a
> >> reasonable first target.
> >
> > What exactly is the problem here?
> 
> The problem is the code duplication inherent in relocation - each
> architecture has its own way of doing it, but really it can mostly be
> written generically in C. ARM is even worse with each CPU implementing
> essentially the same code!

I suggect we leave relocation out of this discussion here.  It is an
area that  needs to be cleaned up, definitely.  But it is another,
unrelated topic.

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
"No problem is so formidable that you can't walk away from it."
- C. Schulz