[U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family

[Wolfgang Denk <wd@denx.de>]

Dear Martha,

can you _please_ fix your mailer and make sure to keep the In-reply-to:
and References: mail headers in place and working, so threading of
messages works?  Thanks.


In message <200910200953803.SM05928@[206.180.163.89]> you wrote:
>
> > Well, the ideas was that this was the default setting that fits most
> > boards, and if it doesn't fit it will be overwritten by another array.
> > Adding #ifdef's here is a strict No-No.
>
> How do I override a default array of 30 ulong elements that is declared 
> static in common code from my board code ?  I declare my own and use it 
> exclusively so the one in common code is a waste of space.  Besides which
> it puts constraints that all the elements need a declaration.  Why if I'm not 
> using it ?

If the assumption that the default code is useful on all boards is
wrong, it has the be revised. We can implement this is a way that it
can be completel enabled/ disabled, but I will not accept any
#ifdef's right in the middle of that array init code.

> > No. You can build either one implementation of the function or the
> > other one, depending of the config settings.
>
> Are you talking about pulling one or the other in at the make ?
> SO to share the 8 functions or so like putc and getc I have one file, 
> 5121 init another and 5125 init a third -- all that to bypass an if statement ?? 

Why compile code for two incompatible architectures when you know at
compile time which one you have? You don't attempt to have one U-Boot
binary image that runs both on a MPC5121 and on a MPC5125 board, or do
you? [I would be interested to see how this could be done in a halfway
clean way.] Whether you split this in several files or not is a
different question.

> You're not making any sense to me.

I'm sorry to hear that.

> > I'm not talking about any printed messages here. I smell a basic
> > misunderstaning in your comments - there cannot be more than one
> > network interface active and in use in U-Boot.
>
> Can't I initialize both and switch between them ?  I do it now and
> want to keep this functionality.

No, you cannot do that. You must not initialize _any_ network
interface unless U-Boot issues a network related command. And when
switching to another interface, you have to disable the previouly used
one. Same before you boot Linux.

> > Umm... Why should we care about this?  See bullet # 2 at
> > http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#2_Keep_it_Fast
> > 
> > U-Boot should not care about these things, unless you run a network
> > command on the second Ethernet interface.
>
> Yes but since you can switch midstream they both need to be initialized 
> and the code needs to determine which one it's using ???

You cannot switch "midstream". You can use a  new  network  interface
with  a new network command - and there it does not make a difference
whether you ran a command on another interface  before  (except  that
you  have  to make sure to disable such other interface first). There
is no and cannot be any switching while  any  command  (say,  a  TFTP
download) is running.

Initialization must not be done before actual use, and then only  for
the network interface that is actually going to be used.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human race is faced with a cruel choice: work  or  daytime  tele-
vision.