[U-Boot-Users] Re: U-Boot for AT91RM9200DK
steven.scholz at imc-berlin.de
Sun Oct 26 11:56:05 CET 2003
>>I thought of something like this in start.S:
>>/* set up PLL */
>> set PLLA to CFG_PLLAR
>> set PLLB to CFG_PLLBR
> 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?
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?
> Just for the record: the "at91rm9200dk" ist just one out of many
> boards. It is in no way better than any other board. "at91rm9200dk"
> dependend code shall be removed from the files in the cpu/at91rm9200
It's better in that everybody could buy such a board and run U-Boot on it. :o)
>>And the user just has to define CFG_USE_EXT_CRYSTAL, CFG_PLLAR etc in his board
>>specific header file. Of course without the need to submit his configuration to
>>the U-Boot CVS.
> I don't understand this last sentence.
> 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.
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.
Now if that's all I did I see no need to "bloat u-boot with unnecessary code".
(Of course the CFG_ and CONFIG_ stuff must be documented e.g. in
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.
And for boards with some special feature.
So I put my efford to provide generic code that could be used by others. That's
why I rewrote my FPGA loading code, submitted a patch although my old board
specific code was working good. And I will provide the code for our board in a
while when I think it shows others how to use this code.
Argh... You know what I meant? I am not sure if I could make myself understood.
More information about the U-Boot