[U-Boot-Users] Re: Ethernet loopback command

[U-Boot-Users] Re: Ethernet loopback command

[Wolfgang Denk]

Hello,

in message <D9F0B2AD4531B0449D51C1F09199D484081F14@mail.kom-saarbruecken.com> you wrote:
> 
> The patch attached provides a command called 'ethloop' which allows to
> perform loopback testing on the current eth device. To achieve this, a

Sorry, but I reject this patch. Test functions like this  one  should
be added as part of the existing POST framework (which probably needs
to  be extended for better architecture support; see the archives for
the previous discussions about this).

> new ethernet packet type (PROT_TEST, 0x0808, AFAIK this is not used
> otherwise) is introduced in net/net.c.
> The patch is against SF CVS from 20050307.

I also don't understand why specific ethernet packet  types  must  be
invented. I don't like such non-standard solutions.

> It is necessary to set the ethernet line into loopback mode either by
> programming the PHY or using a loopback plug. I've tested this on our

So you really should  add  this  as  part  of  the  POST  code  where
appropirate  provisions can be doen. At first glance your patch looks
like it was universal, which it isn't. Actually  I  don;t  see  which
additional  information  you  can  get  from this test that cannot be
gotten from existing network code like ping.

Also, the code is not completely configurable, and was obviously  not
well  tested.  You add some variables even in case the command is not
cnfigured, which wastes memory and causes compiler warnings.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Not one hundred percent efficient, of course ... but nothing ever is.
	-- Kirk, "Metamorphosis", stardate 3219.8

[U-Boot-Users] RE: Ethernet loopback command

[Thomas Schäfer]

Hi, 

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de] 
>
> Sorry, but I reject this patch. Test functions like this  one 
>  should be added as part of the existing POST framework 
> (which probably needs to  be extended for better architecture 
> support; see the archives for the previous discussions about this).
> 
I actually planned to introduce a FE loopback test in the POST framework. But the functions provided seemed to be necessary, because generation and receipt of packets is basic for loopback tests.

> > new ethernet packet type (PROT_TEST, 0x0808, AFAIK this is not used
> > otherwise) is introduced in net/net.c.
> > The patch is against SF CVS from 20050307.
> 
> I also don't understand why specific ethernet packet  types  
> must  be invented. I don't like such non-standard solutions.
> 
The PROT_IP part of the NetReceive function examines the complete IP header which is not necessary here. I introduced that packet type to achieve a proper separtion from all other packet types. Normally the generated packet would remain on the board because PHY or EMAC are switched into loopback mode, but i agree that those non-standard packets could be problematic when sent to a network.

> isn't. Actually  I  don;t  see  which additional  information 
>  you  can  get  from this test that cannot be gotten from 
> existing network code like ping.
> 
You would need a station responding to the ping, which would be difficult during POST. With improved packet generation (large packets, Mbytes of data), stressing the FE subsystem could be achieved.

> Also, the code is not completely configurable, and was 
> obviously  not well  tested.  You add some variables even in 
> case the command is not cnfigured, which wastes memory and 
> causes compiler warnings.
> 
My fault. Should be more careful next time...


Best regards,

Thomas Sch?fer

[U-Boot-Users] RE: Ethernet loopback command

[Jerry Van Baren]

Thomas Sch?fer wrote:
> Hi, 
> 
>>-----Original Message-----
>>From: wd at denx.de [mailto:wd at denx.de] 

[snip]

>>I also don't understand why specific ethernet packet  types  
>>must  be invented. I don't like such non-standard solutions.
>>
> 
> The PROT_IP part of the NetReceive function examines the complete IP
> header which is not necessary here. I introduced that packet type to
> achieve a proper separtion from all other packet types. Normally the
> generated packet would remain on the board because PHY or EMAC are
> switched into loopback mode, but i agree that those non-standard packets
> could be problematic when sent to a network.

Just a thought... I have not looked at the code, so I don't know how 
practical/reasonable this thought is...

If you sent a "ping" (ICMP echo-request) packet and had your loopback 
responder return a "ping" response (ICMP echo-reply) this will be a 
standard packet and may be useful elsewhere.

* Ping packet (echo-request) generation and parsing (echo-reply) is 
already present in u-boot.  If you can reuse this code, you are that 
much further ahead.

* If you add a handler for echo-request packets, returning echo-reply 
packets, this would potentially be useful for responding to external 
computers "ping" requests (currently not implemented because of limited 
usefulness and implementation issues).

[snip]

> Best regards,
> 
> Thomas Sch?fer

gvb

[U-Boot-Users] RE: Ethernet loopback command

[Wolfgang Denk]

In message <D9F0B2AD4531B0449D51C1F09199D484081F2A@mail.kom-saarbruecken.com> you wrote:
>
> I actually planned to introduce a FE loopback test in the POST
> framework. But the functions provided seemed to be necessary, because
> generation and receipt of packets is basic for loopback tests.

See the existing ethernet lopback code (post/ether.c)

> The PROT_IP part of the NetReceive function examines the complete IP
> header which is not necessary here. I introduced that packet type to

But it doesn't hurt either, or does it?

> You would need a station responding to the ping, which would be
> difficult during POST. With improved packet generation (large packets,
> Mbytes of data), stressing the FE subsystem could be achieved.

I disagree. Having a remote station to  answer  is  actually  a  good
idea,  as  you know at least that the packets are standard, i. e. for
example that the header fields are in correct byte  orders,  etc.  If
you're  looking  for  throughout  tests,  you can do this much better
using a remote side, too.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Roses are red
Violets are blue
Some poems rhyme

[U-Boot-Users] RE: Ethernet loopback command

[Thomas Schäfer]

 

> In message 
> <D9F0B2AD4531B0449D51C1F09199D484081F2A@mail.kom-saarbruecken.
> com> you wrote:
> >
> > I actually planned to introduce a FE loopback test in the POST 
> > framework. But the functions provided seemed to be 
> necessary, because 
> > generation and receipt of packets is basic for loopback tests.
> 
> See the existing ethernet lopback code (post/ether.c)
> 
> > The PROT_IP part of the NetReceive function examines the 
> complete IP 
> > header which is not necessary here. I introduced that packet type to
> 
> But it doesn't hurt either, or does it?
> 
The code in post/ether.c uses modified low level ethernet init/send/receive functions for 8xx CPU's to send a broadcast ethernet frame. Adopting this for other CPU's requires to modify those functions for each CPU you want to support. The approach in the patch provided tries to implement a more common solution by using the upper network layer in net/net.c. I cannot see how to implement this without either creating a complete IP header that can be handled properly by the PROT_IP part of the NetReceive function or using another protocol type.

> > You would need a station responding to the ping, which would be 
> > difficult during POST. With improved packet generation 
> (large packets, 
> > Mbytes of data), stressing the FE subsystem could be achieved.
> 
> I disagree. Having a remote station to  answer  is  actually  
> a  good idea,  as  you know at least that the packets are 
> standard, i. e. for example that the header fields are in 
> correct byte  orders,  etc.  If you're  looking  for  
> throughout  tests,  you can do this much better using a 
> remote side, too.
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
> 
Best regards,

Thomas Sch?fer