[U-Boot] A bit about board.c, board.c

[Simon Glass]

Hi Wolfgang,

On Sun, Oct 23, 2011 at 1:14 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ3ZdkF-dnLnC8=L55ZDWznWW6wqu0eJ7puTAT=3rcMcPQ at mail.gmail.com> you wrote:
>>
>> My suggestion was:
>>
>> CONFIG_ARCH_GENERIC_BOARD - you get lib/board.c
>> not CONFIG_ARCH_GENERIC_BOARD - you get arch/xxx/lib/board.c
>
> If we do something like this, then the other way round.  There should
> never be any #defines needed for the standard case - i. e. for using
> lib/board.c,

OK, makes sense.

>
> Also, "ARCH_GENERIC_BOARD" is not a good name as it does not really
> tell the reader that you are referencing to a specific source file
> here - most people will think you are referring to some hardware
> properties.

OK, in my testing I have put this into config.mk in arch/xxx/config.mk:

# Move to unified board system later
CONFIG_SYS_LEGACY_BOARD := y

We can remove it arch by arch as things move over.

So far I have some tentative patches which move ARM and x86 over to a
general board setup. The main issues are relocation and SPL.

For relocation I feel that a C implementation makes more sense. Please
scream if you disagree, but I can see no good reason so far for
anything but the very last bit (where the stack pointer is adjusted)
being in assembler. x86 actually does this.

With ARM there are a few functions in its board.c which don't appear
in other archs. Bearing in mind that I want to create a digestible
patch series I am thinking of leaving the function arrays from
arch/xxx/lib/board.c in these architecture-specific files for now, and
just moving the common functions over to the common file. This means
that init_baudrate() will be in the generic board file, for example,
but board_init (which may in fact be mis-named) stays in
arch/arm/lib/board.c. Both will be referenced from the function array
in arch/arm/lib/board.c.

The obvious step after that is to move the function arrays into the
generic code, but I think it is reasonable to do that afterwards since
at present it is full of #ifdefs and will only get worse when archs
merge.

As a later step we can examine some of the odder and more esoteric
functions and see if they can be moved to board files, drivers, etc.
But it is too big a step I think to do this now. This is particularly
true of PowerPC which has a huge amount of stuff in there... Doing
this later also reduces the potential for breakages.

Also as a later step we have Graeme's initcalls. To me this offer
great benefits but they are not absolutely required for this clean up.
Let' s see how things look.

The generic board files therefore become (unless there are objections
to source files in the board/ directory):

board/board_f.c
board/board_r.c
board/reloc.c

with a small architecture-specific relocation function in:

arch/xxx/lib/arch-reloc.c

With this also it would be nice to standardise the link symbols a
little more. Mostly they are the same but there are variations. I plan
to add something like include/asm-generic/link_symbols.h to declare
these for C code in one place. One annoying thing is that people use
.lds files to add additional code (other than start.S) at the start of
the image. It would be nice to have a Makefile variable which collects
these files as the build proceeds instead of putting then in the .lds
file (one less reason to even need a board-specific .lds file).

My plan at present is to send several small patch series over the next
month or two in this sequence:

- ARM .lds clean-up (sent, although I have a few more cleans-ups for
it and it is missing SPL)
- Very simple general relocation framework (with link symbol stuff)
- Generic board support (but with no archs using it)
- Move ARM over and clean up dead code
- Move x86 over
- Move PPC over

The benefits of this effort will be:

- one copy of most of the various functions in arch/xxx/lib/board.c
instead of 10
- reduced assembler and code duplicate in start.S (I am thinking of ARM here)
- naturally bring less-developed archs closer to the functionality of
more-developed

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
> "My name is Linus Torvalds, you messed with my kernel, prepare to die"
>                                                  - Linus Torvalds in
>      <Pine.LNX.3.91.960426110644.24860I-100000 at linux.cs.Helsinki.FI>
>