[U-Boot-Users] eth_rx implementation

Wolfgang Denk wd at denx.de
Sun Mar 6 13:49:26 CET 2005


Dear Rodel,

in message <698a2fda05030604151688be50 at mail.gmail.com> you wrote:
> 
> My implementation of eth_rx is somewhat like the ff:
>  
> - check if data is available
> - if not, return 0
> - call NetReceive(NetRxPackets[0], len)
> - return len

OK.

> 1. If network data is not available, eth_rx returns 0 and does not
> call NetReceive(), how many times does NetworkLoop retry to send the
> first data it requested?

What has sending to do with receiving? 

> 2. If data is available, eth_rx calls NetReceive, however, if it is
> not intended for the initial U-Boot request, how many times does does
> NetworkLoop retry to send the first data it requested?

What exactly do you want to know? The transmit side (sendign of data)
is completely independend from the receive side. If any data is sent,
or if it might be resent, is only dependent on the current  state  of
the protocol machine, i. e. which command is being executed.

You cannot make any statements about this from just  looking  at  the
receive code.

> 3. Do you need to enable a U-Boot configuration flag to support my
> implementation of eth_rx?

I don't even understand this question.

> I am currently having problems with my eth_send implementation, so


Arghhh. Now what exactly is it you re  asking  for?  First  you  talk
about  ethernet  receive, then you raise protocol issues, and now you
mention the transmit side?

> there are really no network requests done on the PHY layer yet,
> however, the eth_rx can receive data, I just noticed that there's not
> much error handlers on the higher layers.  The ARP requests are only
> done twice, at least in PING command.

The network code contains a  small  (you  may  even  say  a  minimal)
implementation  of some UDP based network protocols like BOOTP, DHCP,
TFTP, and NFS. For details of the protocols please see  the  relevant
RFC's.

Please be specific if you have any concerns that this  implementation
might be incomplete or buggy.

If it's just that your ethernet transmit code doesn't  work  -  well,
it's trivial to hook a debugger in the transmit routine and a network
sniffer  (like  ethereal)  on  the  wire.  Same for the receive side.
Retransmission of data does not play any role here.

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
I'm a programmer: I don't buy software, I write it.
                                                  -- Tom Christiansen




More information about the U-Boot mailing list