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.sm05...@[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: w...@denx.de The human race is faced with a cruel choice: work or daytime tele- vision. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
