[U-Boot-Users] Re: U-Boot for AT91RM9200DK

[Steven Scholz <steven.scholz@imc-berlin.de>]

Dear Wolfgang,

>>I thought of something like this in start.S:
>>
>>#ifdef CFG_USE_EXT_CRYSTAL
>>	enable_main_oscillator;
>>#endif
>>
>>/* 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
> directory.
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.

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

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 
doc/README.AT91RM9200).

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.

-- 
Steven Scholz