in message <3F9BA845.8050505@...> you wrote:
> > Looks clean to me. Probably even better would be to call
> > "init_clocks" (or a function with a similar name) in start.S for
> > _all_ boards, including the "at91rm9200dk".
> Should the function init_clocks() be in start.S or in board specific files?
I understood your argumentation such as if init_clocks() requires
board dependend code. If this is the case, it belongs into a board
specific file. If it is the same for (nearly) all at91rm9200 boards
everything can stay as it is now.
> As it is done with memsetup() or platform() in other ARM implementations?
> Or should we write cpu_init(), board_init() etc. like in the PPC code?
Well, I certainly like the idea of clearly splitting this stuff up as
it was done on PowerPC. I do NOT intend to say that the PPC code was
> > Either you are maintaining his own private version of U-Boot (in
> > which case we don't care, and you don't need to ask for help on this
> > mailing list which is dedicated to the _public_ source tree only), or
> > you are working with the public version of U-Boot, in which case your
> > board configuration obviously resides in the U-Boot CVS tree.
> U-Boot code should be written in a way to make it very easy to port it to new,
> custom hardware without making (too many) changes on the generic and common code
> (as for instance the stuff inc cpu/at91rm92000/ directory).
> In the best case just creating a new board include file with the appropriate
> definitions (like #undef CFG_USE_EXT_CRYSTAL; #define CFG_PLLA 0x12345678 etc.)
> should be enough to bring U-Boot up.
This will never work. There will always be board dependend stuff, and
you will have to select a specific board config name. I don;t expect
that there will ever be some common board specific code which will
work for many boards from different vendors. There are too many
things that can be implemented differently in hardware: RAM and Flash
size, chip types, and bus widths; network interface, RTC, EEPROM, ...
> So if we write the code in cpu/at91rm92000/ generic enough then porting U-Boot
> to a new board is (at a first step) merely writing an new yourboard.h.
I don't think this would ever work...
> That's what I meant. Do we realy need thousends of yourboard.h just containing
> different values for CFG_PLLAR? I think we need them for "standard" eval boards.
The board config files contain many more things. Simple stuff like
console port and baudrate, but also hardware dependend stuff like
memory map, chip types and bus width, etc.
> So I put my efford to provide generic code that could be used by others. That's
The intention is good, and we agree on that. But don't let it carry
you too far. Be realistic.
> Argh... You know what I meant? I am not sure if I could make myself understood.
I think I understand what you mean, but I don't expect that we can
get rid of board dependend code completely. Nor do I see the need for
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@...
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to the
purpose of sitting around all day and eating big heavy meals.
- Terry Pratchett, _Moving Pictures_