[U-Boot-Users] problems using TSEC Ethernet without CONFIG_NET_MULTI
Hi all. I have a question on using TSEC Ethernet on a board with a MPC8541. I don't use CPM2 and FCC. I use only one TSEC for management. Since I only enable one TSEC, I #undef-ed the CONFIG_NET_MULTI flag. But then I couldn't use all the functions under eth.c, since its all under #if (CONFIG_COMMANDS & CFG_CMD_NET) && defined(CONFIG_NET_MULTI). What is the justification for CONFIG_NET_MULTI there? Should I just remove it, or I am supposed to have some other replacement for the Ethernet access that I miss?
Thanks a lot.
Michael,
On Wed, 2007-02-14 at 15:13 +0200, Michael wrote:
Hi all. I have a question on using TSEC Ethernet on a board with a MPC8541. I don't use CPM2 and FCC. I use only one TSEC for management. Since I only enable one TSEC, I #undef-ed the CONFIG_NET_MULTI flag. But then I couldn't use all the functions under eth.c, since its all under #if (CONFIG_COMMANDS & CFG_CMD_NET) && defined(CONFIG_NET_MULTI). What is the justification for CONFIG_NET_MULTI there? Should I just remove it, or I am supposed to have some other replacement for the Ethernet access that I miss?
Thanks a lot.
You're right - the TSEC driver won't work without enabling CONFIG_NET_MULTI. The purpose of this configuration option is to automatically cycle through the available Ethernet devices when attempting a network connection, moving on when a device's link is down. I imagine the person who wrote the tsec didn't imagine the case where someone would only want to use one device.
I intend to clean up the eth.c file some time soon because as you can see it's a big mess of #ifdefs.
Enabling CONFIG_NET_MULTI shouldn't cause you any problems. Just go ahead and do that, but only define the appropriate CONFIG_MPC85XX_TSEC? flags.
If this isn't clear, just let me know.
regards, Ben
I'm catching up with my u-boot list emails, so please forgive my late reply here:
On 2/14/07, Ben Warren bwarren@qstreams.com wrote:
The purpose of this configuration option (CONFIG_NET_MULTI) is to automatically cycle through the available Ethernet devices when attempting a network connection, moving on when a device's link is down.
This is such an arcane purpose - I wonder how many people think this is a valuable feature? In most cases a system has multiple ethernet interfaces, those interfaces are connected to different subnets, and quite often it is meaningless to try communicating with a host A on interface B. This automated interface skipping is actually a very harmful in some situations.
The ability to register multiple interfaces and pick one of them for all communications is a great one. But the automated switch from interface to interface should definitely not be the default behavior.
I wonder what is the u-boot community consensus on this issue. I guess not many people bring up boards with multiple enet interfaces...
cheers, vadim
I imagine the person who wrote the tsec didn't imagine the case where someone would only want to use one device.
I intend to clean up the eth.c file some time soon because as you can see it's a big mess of #ifdefs.
Enabling CONFIG_NET_MULTI shouldn't cause you any problems. Just go ahead and do that, but only define the appropriate CONFIG_MPC85XX_TSEC? flags.
If this isn't clear, just let me know.
regards, Ben
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message f608b67d0703090846n3fc522f2mcd4c9b770644383d@mail.gmail.com you wrote:
This is such an arcane purpose - I wonder how many people think this is a valuable feature? In most cases a system has multiple ethernet
Many people conside rit extremely important to be able to run a system with redundant netowrk interfaces.
interface B. This automated interface skipping is actually a very harmful in some situations.
Perhaps you might be so kind as to elucidate?
The ability to register multiple interfaces and pick one of them for all communications is a great one. But the automated switch from interface to interface should definitely not be the default behavior.
THis is your opinion. Me, and others, disagree.
I wonder what is the u-boot community consensus on this issue. I guess not many people bring up boards with multiple enet interfaces...
You may be wrong. There may be more customers using this feature than you expect, and the number of systems where it's being used in production is probably in the millions by now.
Best regards,
Wolfgang Denk
Wolfgang, I of course am not going to argue with you - I don't have the big picture you have. So, let me take back my statement about this being useless in general :-)
But I certainly see a class of applications where it brings no value, as I described above. While I am fixing some other issues with the 570x driver, I will suggest a patch to make this switching optional.
Cheers, vadim
On 3/9/07, Wolfgang Denk wd@denx.de wrote:
In message f608b67d0703090846n3fc522f2mcd4c9b770644383d@mail.gmail.com you wrote:
This is such an arcane purpose - I wonder how many people think this is a valuable feature? In most cases a system has multiple ethernet
Many people conside rit extremely important to be able to run a system with redundant netowrk interfaces.
interface B. This automated interface skipping is actually a very harmful in some situations.
Perhaps you might be so kind as to elucidate?
The ability to register multiple interfaces and pick one of them for all communications is a great one. But the automated switch from interface to interface should definitely not be the default behavior.
THis is your opinion. Me, and others, disagree.
I wonder what is the u-boot community consensus on this issue. I guess not many people bring up boards with multiple enet interfaces...
You may be wrong. There may be more customers using this feature than you expect, and the number of systems where it's being used in production is probably in the millions by now.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de A committee is a group that keeps the minutes and loses hours. -- Milton Berle
participants (4)
-
Ben Warren -
Michael -
vb -
Wolfgang Denk