Hi,
in message 3F9BA845.8050505@imc-berlin.de 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 perfect.
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.
IMHO:
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).
Agreeed.
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 that.
Best regards,
Wolfgang Denk