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

[Wolfgang Denk]

Hi,

in message <3F9BA845.8050505 at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
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_