Dear Guy Morand,
please restrict your line length to approx 70 characters or so.
In message A91D8217D6A8B240A79EBEE98176B19B298B1D2069@PRISM.telecontrol.local you wrote:
I'm trying to write an U-Boot command to ping the other interface on my pla tform. This is to test the hardware at production, the ping must hit the wi re. I got deeply inspired from this patch: http://lists.denx.de/pipermail/u-boot/2005-March/009317.html
I hope you also ready my comments. These still apply.
What changes is that I really want to ping the other interface with a cross cable and not using a special "home made" device ... The problem is when I send the ping, it is the same interface that answers (the one that sent th e ping), this is not what I want. I thought by changing the destination MAC address in the packet and initializing it, the other interface should answ er by itself. Actually this is not the case...
...
I checked with Wireshark, the packet is correctly build. Maybe my approach is flawed ! Or maybe do you have another way to perform that kind of test ?
You a run into a number of very basic limitations here.
First, U-Boot has, so far, no clean device model yet. In your case this means that we can enable only one Ethenret interface at a time. When you enable one interface (to send a packet), all other interfaces are shut down and disabled, so they will never be able to see the packet, even if it arrives as intended. We have been discussing improvments in this area in the past, but nothing got implemented or even designed yet.
Second, U-Boot is strictly single-tasking. Even if we had a better driver interface so we were able to "open" two network interfaces simultaneously, we have no infrastructure in place to run independend "send" and "receive" tasks.
If local loopback tests are not sufficient, you will probably find it easiest to perform such testing using an external test machine with two network interfaces.
Best regards,
Wolfgang Denk