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

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ1Zim6=u3rLcnAKE-0Bw3sO_hRY+U67jkpkNoNi8g7ctw at mail.gmail.com> you wrote:
> 
> Also it does depend on expectations. I would hope that moving an
> architecture over would be a fairly small task:
> 
> - getting generic relocation working

I don;t see why this would be a direct prerequisite here.  We want to
have that, no boubt about that.  But it appears to be an unrelated
change to me.

> - adding functions for anything that is missing from board init code

"anything that is missing from board init code" ?

> - removing things which don't work on the architecture?

That would probably reander systems broken that need these things?

> - worrying about differences in ordering between functions

This is indeed the biggest issue.

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...]

> > pull out common init code like init_baudrate() and hang() and change the
> > function signatures of the functions that require wrappers and move some
> > #ifdef's into more appropriate locations - One example in board.c:
> 
> Well it seems like a lot of work to refactor each arch/xxx/board.c
> file into functions with a function pointer list, then later remove
> this code function by function.

Would that really be a clever approach?

> My feeling is that with a generic board, it should hopefully be a
> fairly small amount of work for someone familiar with an architecture
> to find the bugs and patch the generic code to suit their
> architecture. It is something that needs to be done once, not every
> time there is a new patch removing (almost) common code.

It is definitely not that easy.  You fix one thing here, and break
another board there.  Ideally you would have to re-test any change on
_all_ boards.

> From previous discussions, if something is optional then the switch
> will never happen. The code you are talking about is sometimes
> identical, sometimes slightly different. In some cases the order is
> different. I see many ways of introducing breakages. I do agree that

And I bet most of them _will_ introduce breakages.

> doing one architecture at a time is best - with the proviso that we
> need to pick archs that have the most features (so ARM and PowerPC I
> suppose) to make sure we are not deluding ourselves as to the
> simplicity of the task.

I would suggest to attempt to merge ARM into PPC.

> So perhaps a generic board init that is the default can be switched
> off on board-by-board basic would be the right approach. Then we can
> flick the switch while providing for those affected to still get work
> done until bugs are reported and found?

Heh!  Board specific init tables!

> > Note that not all arches need and/or use ELF relocation - Attacking this
> > first does not move towards unity of board.c
> 
> 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?

> Per Wolfgang's request to go with PPC as an early-adopter, this is

No.  It's the other way round.  PPC is what should be adopted to.

> Can anyone recommend a PowerPC board with a quick U-Boot program-run
> cycle that I can easily get that will let me try out things there?

Define "get easily".

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
People have one thing in common: they are all different.