RE: [U-Boot-Users] U-boot automatic selection of redundant ethern et interfaces?
Dear Wolfgang,
I don't know if the "ping" code takes redundand ethernet interfaces into account, i. e. if it will toggle interfaces. I don't even know if this makes sense - "ping" is intended to test if somebody is responding, and it makes probably no sense here to distinguish between the remote ost being down or cable disconnected or interface broken.
It's a differetn issue with a network boot (dhcp, bootp or tftp command) - you expect these to work, and if they are failingit seems a good idea to try an alternative inteface if there is one.
It works as you suggested, ping doesn't use redundant interfaces but tftp certainly does, initially it times out the first time it tries a transfer (which initially threw me!) but the second time it works nicely. Exactly what I was looking for,
thank you.
Mark.
-----Messaggio originale----- Da: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]Per conto di Mark Doherty Inviato: martedì 28 ottobre 2003 14.01 A: 'Wolfgang Denk' Cc: 'u-boot-users@lists.sourceforge.net' Oggetto: RE: [U-Boot-Users] U-boot automatic selection of redundant ethern et interfaces?
Dear Wolfgang,
I don't know if the "ping" code takes redundand ethernet
interfaces
into account, i. e. if it will toggle interfaces. I don't
even know
if this makes sense - "ping" is intended to test if
somebody is
responding, and it makes probably no sense here to
distinguish
between the remote ost being down or cable disconnected or
interface
broken.
It's a differetn issue with a network boot (dhcp, bootp
or tftp
command) - you expect these to work, and if they are
failingit seems
a good idea to try an alternative inteface if there is one.
It works as you suggested, ping doesn't use redundant interfaces but tftp certainly does, initially it times out the first time it tries a transfer (which initially threw me!) but the second time it works nicely. Exactly what I was looking for,
thank you.
Mark.
I had the same problem in our propritary board based on MPC8260. I modified the fcc driver files for use the fcc like external driver with new define and work fine (also with tftp). If it's what you need, see attached file.
Enzo
Dear Enzo,
in message 002d01c39dee$f30fc4a0$4a50848a@settimo.italtel.it you wrote:
It works as you suggested, ping doesn't use redundant interfaces but tftp certainly does, initially it times out the first time it tries a transfer (which initially threw me!) but the second time it works nicely. Exactly what I was looking for,
I had the same problem in our propritary board based on MPC8260.
Ummm... exactly which problem are you talking about? What Mark Doherty described so far is IMO not a problem, but intenional behaviour.
I modified the fcc driver files for use the fcc like external driver with new define and work fine (also with tftp). If it's what you need, see attached file.
Argh... I'm sorry, but this code is useless. If you want to submit a patch, please do it as described in the README file.
Best regards,
Wolfgang Denk
Dear Enzo,
in message 002d01c39dee$f30fc4a0$4a50848a@settimo.italtel.it you wrote:
It works as you suggested, ping doesn't use redundant interfaces but tftp certainly does, initially it times out the first time it tries a transfer (which initially threw me!) but the second time it works nicely. Exactly what I was looking for,
I had the same problem in our propritary board based on MPC8260.
Ummm... exactly which problem are you talking about? What Mark Doherty described so far is IMO not a problem, but intenional behaviour.
I modified the fcc driver files for use the fcc like
external driver with
new define and work fine (also with tftp). If it's what you need, see attached file.
Argh... I'm sorry, but this code is useless. If you want to submit a patch, please do it as described in the README file.
I know that this is not a patch; the code is local to my board directory and doesn't substitute the original code of fcc driver. It's only for suggest the possible solution. The modify regard only the possibility to use more than one eth interface at the same time; looking the u-boot code this solution was already possible for external device using CONFIG_NET_MULTI. I have only modified the code for support more than one fcc (using variable instead define) and adding some function needed in my board. Do you think that someone need this version of driver ?? In this case I'll modify it for general using and I'll submit to you like a patch.
Regards,
Enzo
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de What is wanted is not the will to believe, but the will to find out, which is the exact opposite. -- Bertrand Russell, "Skeptical Essays", 1928
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Dear Enzo,
in message 003701c39e0a$adbd45f0$4a50848a@settimo.italtel.it you wrote:
I know that this is not a patch; the code is local to my board directory and doesn't substitute the original code of fcc driver. It's only for suggest the possible solution. The modify regard only the possibility to use more than one eth interface at the same time;
This code is already present in the mainstream U-Boot sources.
looking the u-boot code this solution was already possible for external device using CONFIG_NET_MULTI.
When did you check? Must have been a long time ago...
Best regards,
Wolfgang Denk
participants (3)
-
Figini Enzo -
Mark Doherty -
Wolfgang Denk