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

[Simon Glass]

Hi Wolfgang,

On Sat, Dec 31, 2011 at 5:54 PM, Wolfgang Denk <wd at denx.de> wrote:
> 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.

I don't think it's essential, but it is desirable, which I why it is
on the list.

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

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

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

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().

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'
initcall idea (basically using the linker to create the list of
initcalls for pre- and post-reloc) then it becomes possible to boards
to insert things in the init sequence without #ifdefs in
commong/board.f/r.c.

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.

>
>> > 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?

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.

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

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.

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

Yes I hear you. I have had a crack at that with pre-reloc init. It's
not exactly a thing of beauty but it isn't too bad. What I really like
about having everything in one file (#ifdefs and all) is that you can
quickly see where there are unnecessary arch differences, and refactor
them.

>
>> 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!

See above - I vote for Graham's initcall stuff - I believe the main
concern was figuring out the init order and perhaps a little objdump |
grep | awk System.map script would do the job here.

>
>> > 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?

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!

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

Yes I can see that PPC is a superset, or at least contains the most
features. I will continue to look at this.

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

Well, perhaps buy for around $500 or so and get it shipped to
California to arrive this week/early next?

Regards,
Simon

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